Summary:	ASTERISK-07264: [branch] Reinvite does not manage RFC 2833 -> wrong payload
Reporter:	Sylvain RIBEYRON (sribeyron)	Labels:
Date Opened:	2006-06-30 10:25:23	Date Closed:	2011-06-07 14:08:15
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisksip.dump
Description:	Connecting two softphones using Asterisk with reinvite option enabled may loose dtmfs if payload code is not 101 for audio/telephone-event for the calling phone. When doing the reinvite, payload mapping is not actualized between the two terminals. Then, terminals may send dtmfs using two different payloads. ****** ADDITIONAL INFORMATION ****** Here is a sample sequence: Phone 1: sends invite to Asterisk with: a=rtpmap:96 telephone-event/8000/1 <- OK ... Asterisk: sends INVITE to Phone 2 with: a=rtpmap:101 telephone-event/8000 <- OK ... Then Asterisk reinvite: Asterisk: sends invite to Phone 1 with: a=rtpmap:96 telephone-event/8000 <- OK Asterisk: sends invite to Phone 2 with: a=rtpmap:101 telephone-event/8000 <- OK Then, when rfc 2833 packets are sent from Phone 1 to Phone 2, their payload is 96, while Phone 2 waits for payload 101. Workaround: either forbid reinvite, or use 101 as default payload for telephone-event in both phones. Attached file contains complete traces of sip messages.
Comments:	By: Andrey S Pankov (casper) 2006-07-02 17:46:38 Never seen Asterisk to negotiate RFC 2833 payload... it should be 101 and other payload types are not supported AFAIK. By: Anthony LaMantia (alamantia) 2006-07-02 19:23:25 could we just not accept a codec change when a diffrent rtpmap sdp payload is sent and keep the old connection running via the stored sip_pvt structure in memory when process_sdp() is called? /* Note: should really look at the 'freq' and '#chans' params too */ ast_rtp_set_rtpmap_type(p->rtp, codec, "audio", mimeSubtype); if (p->vrtp) ast_rtp_set_rtpmap_type(p->vrtp, codec, "video", mimeSubtype); } I am not entirelly sure on this tho.. and may be mistaken, input would be welcomed :) or this may break some of the functionality of the reason for a reinvite .... By: Sylvain RIBEYRON (sribeyron) 2006-07-03 01:58:44 I'm really not a SIP expert, but I think that choosing 101 as the only possible payload type for RFC 2833 is arbitrary. Rejecting other payload codes would not be a nice solution, because some softphones don't use 101 as default dtmf payload. A good solution, I think, would be: - to reuse the same payload map from caller to callee, - not to re-invite if (for any reason) payload codes are not the same. By: Olle Johansson (oej) 2006-07-03 09:45:50 We should offer the correct setting in the re-invite, this is most certainly a bug. Asterisk itself always set 101 to DTMF/RFC2833 but should keep others in mind when re-inviting. By: Serge Vecher (serge-v) 2006-09-01 13:51:36 anybody able to handle a patch here? By: jmls (jmls) 2006-11-01 10:18:30.000-0600 oej, you seemed to think that this was a bug. Is that still the case ? By: Olle Johansson (oej) 2006-11-12 14:18:31.000-0600 This is definitely a bug that needs a fix. By: Olle Johansson (oej) 2006-11-12 14:33:30.000-0600 Wonder if we do support this for normal codecs. If phone A wants to receive ulaw as codec 102, will Asterisk send codec 102 for ulaw on the re-invite to the other phone? By: Olle Johansson (oej) 2006-11-21 03:17:22.000-0600 please test the "earlyrtpfix" branch where I fixed this - hopefully. We saw the same problem with video call setups. By: Olle Johansson (oej) 2006-11-22 08:02:28.000-0600 My branch now fixes the setup of the call - the invite, but not handling the 200 OK coming back. Trying to fix that. By: Olle Johansson (oej) 2006-11-30 01:27:59.000-0600 Have you tested my branch? Any feedback? By: Henning Holtschneider (hehol) 2006-11-30 12:58:43.000-0600 I do not have a setup available at the moment to reproduce the case but I will try ASAP! By: Olle Johansson (oej) 2007-01-23 03:00:38.000-0600 ASAP was a while ago... :-) Any updates? By: Olle Johansson (oej) 2007-02-01 15:38:03.000-0600 Will re-open when reporter wakes up again.