Summary:	ASTERISK-00654: SDP is badly negotiated for telephone events
Reporter:	glepine (glepine)	Labels:
Date Opened:	2003-12-11 13:41:41.000-0600	Date Closed:	2004-09-25 02:53:46
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:	is a clone of ASTERISK-22789 chan_sip SDP incorrect negotiation for RTP payload types causes DTMF recognization failure and appears to violate RFC
Environment:		Attachments:	( 0) telephone_events_negotiation.asterisk.log
Description:	SIP device (1) calling Asterisk (2): (1) includes payload 96 for telephone events from 0-15 in invite message (2) acks with payload 101 from 0-16.  It should respond with a subset.  If it does not support payload 96, fine, but do not respond with payload 101 and worse adding an fmtp in the list from the invite
Comments:	By: Brian West (bkw918) 2003-12-14 11:37:04.000-0600 what devices are you using and what do you think this breaks?  I need more info. By: glepine (glepine) 2003-12-15 08:17:06.000-0600 1. The negotiation is not standard.  Asterisk shall respond with a subset of capabilities, chosen from the call initiator capability set (c.f. RFC 3261 and al.).  In the present scenario, returned payload is wrong and fmtp set is wrong also. 2. A device calling Asterisk must send out-of-band DTMF to Asterisk in order to be able to navigate through the IVR menus. 3. The break is that a device not supporting payload 101 for telephone events will never be able to work with Asterisk. 4. Two solutions are possible: a. If a device calling Asterisk cannot get out of the welcoming message (i.e. not being able to navigate through menus sending OOB DTMF with payload 101) Asterisk should drop the call b. I patched rtpPayloadType from rtp.c so that AST_RTP_DTMF be 96 instead of 101 and now my device can work with Asterisk. By: Brian West (bkw918) 2003-12-15 10:50:18.000-0600 What crack pipe device are you using? By: glepine (glepine) 2003-12-15 12:13:50.000-0600 I am using a Mediatrix 1104 (www.mediatrix.com) implementing RFC 2833 describing RTP payload for DTMF digits and RFC 3264 for SDP offer/answer model. In the case where a device calls the Mediatrix 1104, the latter will comply to the payload type specified in the SDP supplied by the former's INVITE message.   When the Mediatrix 1104 intiates the call, it describes that payload 96 (one of the dynamic payload types of the RTP protocol) will be used for telephone event 0-15.  What Asterisk should at least do is either: a) comply to the dynamic payload type supplied by the caller or b) drop the call since it will not handle telephone events other than those with payload 101 and therefore a device not using dynamic payload type 101 for telephone events will not be able to get out of the welcoming message. By: Brian West (bkw918) 2003-12-15 12:41:49.000-0600 Can you attach a sip debug without your patch. thanks By: glepine (glepine) 2003-12-15 15:42:41.000-0600 here you go.  I can eventually send you an Ethereal trace if you wish. By: Brian West (bkw918) 2003-12-15 16:00:03.000-0600 I think this will be plenty for Mark to take a crack at it. Thanks, bkw By: Mark Spencer (markster) 2003-12-15 17:57:30.000-0600 Our selection of number and the remote devices are entirely independent.  It doesn't matter if we answer on 101 or not, it still has to accept what we send and we hsould still handle it properly on our number. By: glepine (glepine) 2003-12-17 07:56:14.000-0600 On the Mediatrix 1104 side, it accepts what you send with payload type 101... By: Brian West (bkw918) 2004-01-07 00:12:54.000-0600 glepine is this still an issue.  I wonder if the Meditrix stuff has a bug but who knows we need to look at this closer. By: glepine (glepine) 2004-01-07 07:07:53.000-0600 yes, this is still an important issue.  And in fact, it revolves around the fact that the caller (the 1104) puts in 96 as the payload type for telephone events and Asterisk returns payload type 101 and sticks with it, making navigation through the IVR menus impossible. By: Brian West (bkw918) 2004-01-10 17:13:40.000-0600 kram needs to ssh in and look at this.  Find him or myself on irc.freenode.net and we can get a better picture of whats going on? By: Mark Spencer (markster) 2004-02-08 23:59:15.000-0600 Can you provide any bit of evidence to support that if you invite us with 96 as telephony event that we must also use 96 for receiving?  I need you to reference an RFC and a section. By: Brian West (bkw918) 2004-02-10 12:29:18.000-0600 Closing this pending a response. By: glepine (glepine) 2004-03-19 08:00:38.000-0600 Sorry for the delay but I've been cut in rush lately... Section 8.3.2 of RFC 3264 confirms that the payload type number MUST NOT change once set in a session (usually set in an SDP offer, and in our case it is). By: Olle Johansson (oej) 2004-03-19 15:48:47.000-0600 Most SIP UA:s have a configuration setting for RTP payload for DTMF. Maybe we can add this to rtp.conf as a quick fix? A solution is to negiotiate correctly, but the fix would make it possible to solve this situation. By: Mark Spencer (markster) 2004-03-22 16:56:41.000-0600 First pass at fixing this is in CVS head.  We use the caller's values when given them. By: Mark Spencer (markster) 2004-03-22 16:57:55.000-0600 Although, you realize, this is another protocol error of the IETF, since it means that if user A calls me with ulaw as 101 and caller b calls me with ulaw as 102, i can never reinvite them to talk to one another.  Yay IETF, good planning as usual. By: Mark Spencer (markster) 2004-03-24 16:52:39.000-0600 Fxied in CVS as far as I know, no response from original bug poster.