Summary:	ASTERISK-04772: Dynamic codecs (eg. 97 - ilbc) are not handled correctly when asterisk steps out of the media path (canreinvite=yes)
Reporter:	marvy (marvy)	Labels:
Date Opened:	2005-08-03 21:04:20	Date Closed:	2011-06-07 14:10:40
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I have a situation where I have an eyeBeam softphone calling an asterisk server which then passes the call off to another asterisk server. eyebeam ---> asterisk1 ----> asterisk2. The 3 devices are geographically separated and all on public IP space. For this reason, I would like the RTP stream to travel from the eyebeam client directly to the asterisk2 server. If you are using a codec with a static number, all is fine and happy in the world - the call is setup and the rtp "native bridged" between eyebeam and asterisk2. However, eyeBeam uses codec number 98 for iLBC and asterisk prefers 97 for iLBC. When asterisk *excepts* an ilbc connectiong from an external client, it does the rtpmap thing correctly (see bug 2293) and asterisk submits to the codec number choice of the client calling in. When asterisk makes a call out using ilbc, it says it would like to use codec 97 and the other end submits to asterisks request. Now in the situation above, in the canreinvite=no mode, this is what happens.          ilbc 98 ->             ilbc 97 -> eyebeam <----------> asterisk1 <----------> asterisk2        <- ilbc 98             <- ilbc 97 No problems here. Next if we switch on canreinvite=yes then i *think* you get something like this:         ilbc 98 ->           (expecting 97) eyebeam <---------------------------------> asterisk2        (expecting 98)           <- ilbc 97 In any case, it doesn't work. ****** ADDITIONAL INFORMATION ****** Other testing: This bug does not appear to be in eyeBeam as I have substituded an asterisk server inplace of the eyeBeam with: [97] = {1, AST_FORMAT_ILBC} changed to [98] = {1, AST_FORMAT_ILBC} in rtp.c to emulate eyeBeams defaults. Same problem occurs. If you make the above change to the asterisk1 server in the middle of the chain then it negotiates codec number 98 with asterisk server 2 and then everything works perfectly with all parties using 98 as their ilbc codec number.
Comments:	By: marvy (marvy) 2005-08-10 20:00:39 Another interesting "feature" is that when asterisk does the re-invite to pass off the RTP stream, it seems to filter the list of codec's available to each side. For example: Host1--------------Asterisk--------------Host2 .......................|.gsm.............gsm ulaw..............ulaw.|.................ulaw .......................|.................alaw In this example when asterisk talks to host1 it will only accept the ulaw codec. When asterisk talks to host2 it will only talk the gsm codec however host2 is capable of talking gsm, ulaw and alaw. Now when the call is established, asterisk correctly sits in the middle and transcodes ulaw <-> gsm for the two hosts. However, if you have canreinvite=yes enabled, the reinvite should IMHO allow host1 and host2 to talk ulaw together. When seems to happen is that asterisk does some filtering of the avialable codecs of each party according to it's configuration file. So in this example, it would now allow a native bridge even though one is possible. Perhaps this is by design but the person working on this issue should keep it in mind when re-working this code. By: Mark Spencer (markster) 2005-08-11 01:38:42 The primary complaint of this bug report is an unfortunate side effect of the rather shortsided concept of dynamic payload in SDP.  Since you cannot reassign a number that has been used, there is no way to guarantee that two separately negotiated connections will be able to be pointed to one another without handling RTP in the middle. By: Olle Johansson (oej) 2005-08-11 03:23:24 Need a SIP debug on this. By: Michael Jerris (mikej) 2005-08-18 07:23:17 We cannot continue to troubleshoot this without the requested information.  Suspending this bug due to lack of resoponse, please re-open when you have the requested information.