Summary:	ASTERISK-01149: MGCP transfer procedures not compliant
Reporter:	florian (florian)	Labels:
Date Opened:	2004-03-04 03:33:05.000-0600	Date Closed:	2011-06-07 14:10:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) swissvoice.dmp
Description:	I own a SwissVoice IP10 MGCP phone which can transfer calls with hookflash, just like Cisco ATA186. Problem is: the second call (announcement) gets jittery sound. The SwissVoice people were helpfull in analysing the issue. Seems actually, both the phone and asterisk would need some work to solve the issue (either would be fine, both would be best). ****** ADDITIONAL INFORMATION ****** SwissVoice: "After analysing your trace, what i saw is that the phone still receive some RTP packets on port 30000, on the first connection, even when this connection is in inactive state. When a new connection is established for the second communication, before transfer, then the phone also receive rtp packet on port 30002. Then it occus a kind of mixing between what is received on port 30000 and port 30002. What is not clean on the phone side is that it shouldn't take care of RTP packets on port 30000, but on the call agent side, is not clean also to still send these RTP packets to port 30002. We will check what we can do on our side regarding that, but i think it also need a correction on call agent side."
Comments:	By: florian (florian) 2004-03-04 03:37:14.000-0600 Attached is an ethereal dump of a conversation between asterisk and the swissvoice in a transfer scenario. By: twisted (twisted) 2004-04-28 19:21:04 Is anything happening here?  If not, we need to close this out. By: twisted (twisted) 2004-05-02 22:54:25 Gonna let this go a couple more days.. By: florian (florian) 2004-05-03 02:50:55 Activity or no, this _is_ a valid bug as far as I'm concerned. I know SwissVoice has added this to their 'to-fix' list, but there is no planning regarding time. Nevertheless, this should also be fixed in Asterisk. By: twisted (twisted) 2004-05-03 05:45:47 Have you tried current cvs?  There were a lot of mgcp fixes since the origional post that you didn't reply to until now. We really need to know how well/if they made any difference.. Also, would it be possible to get you to test the newest cvs -head for changes to bug 881?  The author of that bug noted that he does not have the equipment handy to test the changes.   Thank you By: florian (florian) 2004-05-04 22:03:23 Tonight I tried current CVS (development) and unfortunately it has not changed. Can someone else comment on what is needed to fix this on the asterisk side ? Florian By: Brian West (bkw918) 2004-05-05 01:18:25 Send digium an MGCP phone we can't have these long delays in fixes vs trying.  We need to get a pair of these IP10's over to them and get this chan_mgcp drama FIXED for good. Anyone? By: Mark Spencer (markster) 2004-05-07 10:07:09 According to Yves Girod at Swissvoice, they are sending me two IP phones for testing.  Glad to see them take an interest in Asterisk. By: twisted (twisted) 2004-06-16 23:50:50 markster, I know you've been really really busy, but what's the status of this? By: Mark Spencer (markster) 2004-06-23 23:52:57 It seems to be working fine for me.  Is this still a problem for you, florian? By: Mark Spencer (markster) 2004-06-23 23:53:19 Note, though, again, that it does *not* support 3-way calling! By: Mark Spencer (markster) 2004-06-26 15:46:03 It's either been fixed or the customer has lost interest By: florian (florian) 2004-08-12 13:50:10 Sorry it took so *damn* long, I didnt have the phones in my testlab and have been insanely busy (as we all are). Report back: Now running CVS-HEAD-08/12/04-09:00:00-BRI-stuffed, and it the described effect is still in place. Mark, can you tell me what firmware version you have on the IP10 ? Mine is: IP10 M v1.0.0 (Build3). Your note about threewaycalling is very clear. However the effect I'm describing is _not_ in a threewayscenario, it is happening when the IP10 is talking to the new party before actually transferring (so the initial remote party is hearing musiconhold at this stage). By: Mark Spencer (markster) 2004-08-13 14:06:52 It is not a bug that we send to both rtp ports.  I will be doing some work on some changes to MGCP to support devices incapable of supporting > 1 stream, but I have no eta.