Summary:	ASTERISK-01701: Re-invite codec negotiation bug
Reporter:	juanjo (juanjo)	Labels:
Date Opened:	2004-05-26 17:28:52	Date Closed:	2011-06-07 14:05:03
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) reinvite.txt ( 1) reinvite2.txt ( 2) reinvite3.txt
Description:	When asterisk uses re-INVITE to release him from the audio path it isn't very clever about codecs. Asterisk sends the re-INVITE based on each endpoint codec negotiation but it seems that it doesn't take into account that probably the codec accepted for each endpoint isn't the same. Please see attached ethereal capture and look at frame 320-321 to see the problem. I'm using last CVS head.
Comments:	By: Mark Spencer (markster) 2004-05-26 21:12:18 This probably lays somewhere between bug and feature.  Anyway I've updated the code, and made a first pass at supporting this better.  Please cvs update and try again.  Note that Asterisk will *never* invite with a codec it doesn't support and that the codec numbers better be identical on both sides. By: juanjo (juanjo) 2004-05-27 02:55:22 Mmmm. Things are worst one of the endpoints is refusing the re-INVITE with 481. Attached goes the ethereal trace. By: juanjo (juanjo) 2004-05-27 03:23:32 This is the SIP debug info from my AS5300 it seems the tag is different at the re-INVITE: May 27 07:17:57.982: Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL                old_from: <sip:095292423@192.168.65.10>;tag=77A80B8-156D                old_to:   <sip:1511@192.168.65.100>;tag=as6849d86e                new_from: <sip:095292423@192.168.65.10>;tag=77A80B8-156D                new_to:   <sip:1511@192.168.65.100>;tag=77A80B8-156D By: Mark Spencer (markster) 2004-05-27 12:00:16 CVS update when you get a moment.  Should be fixed in latest CVS head.  Actually has to do with the fix for a different bug. By: juanjo (juanjo) 2004-05-28 16:14:23 Ok,    Last CVS solved the 481 message but still no audio, since one ends uses GSM and the other ALAW. I think asterisk should use the first 200 OK and INVITE to get a common codec between the endpoint. I attached reinvite3.txt to show what happens now. From the new traces one could get the common codec from the first INVITE received and the 200 OK received from the INVITE sent by Asterisk. It's tricky. Tanks By: Mark Spencer (markster) 2004-05-29 22:26:01 can you please supply the asterisk sip debug rather than the Cisco SIP debug? By: Mark Spencer (markster) 2004-05-29 22:27:58 Asterisk will use the data provided in the original invites on each side to decide on a common codec *but* it also has to be a codec which asterisk would have been permitted to negotiate in the first place. By: Mark Spencer (markster) 2004-05-30 01:27:13 When I call from my cisco to my pingtel through asterisk, the pingtel replies only with a subset of the codecs that asterisk requests.  I think this is fairly standard behavior so you'll never get it to reinvite with a codec that asterisk didn't use in its invitation on one side. By: juanjo (juanjo) 2004-05-31 14:38:50 Mark,    The SIP debug from the Cisco was related to the 481 error, reinvite3.txt is the ethereal trace of the last CVS against the AS5300 & 7960. BTW I know that Asterisk uses only codecs supported I don&ASTERISK-177;t want to uses G729 I just want to avoid enabling GSM on the AS5300 and ALAW on 7960.    AFAIR the SIP stack from Pingtel phones isn&ASTERISK-177;t a model to follow ;) in my case the 200 OK from Cisco just contains one audio codec. My Asterisk uses GSM as the first choice which is fine for the AS5300 but not for my 7960. Please note that the problem arises when the AS5300 initiates the call (call from PSTN). Thanks By: Mark Spencer (markster) 2004-05-31 15:21:51 Again, please attach the *sip debug* not the etheral debug, not the cisco debug, but the *sip debug* from asterisk so I can determine what, if any, bug remains with the codec determination for reinvites.  Bonus points if you have full verbose and debug enabled too, so I can get bits of Asterisk's internal logic (see /etc/asterisk/logger.conf to turn on debug to the console). You can change the "preference" that Asterisk lists codecs by the order they are specified in the *general* section of sip.conf. By: Mark Spencer (markster) 2004-06-01 19:42:53 Since this is labeled a "MAJOR" bug, I really need more responsive answers to pursue this bug report further if you still have an interest in it.  Please provide the sip debug (and turn on debugging to console in the logger.conf as well as maximum verbose) so that I can track it down.  Thanks! By: Mark Spencer (markster) 2004-06-06 12:45:02 Bug placer appears to have lost interest.