Summary:	ASTERISK-22789: chan_sip SDP incorrect negotiation for RTP payload types causes DTMF recognization failure and appears to violate RFC
Reporter:	Pawel Kuzak (pkuzak)	Labels:
Date Opened:	2013-10-29 06:24:56	Date Closed:	2014-02-28 13:37:11.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General Channels/chan_sip/Interoperability
Versions:	11.5.1 11.6.0 11.7.0	Frequency of Occurrence	Constant
Related Issues:	is the original version of this clone: ASTERISK-00654 SDP is badly negotiated for telephone events is related to ASTERISK-23279 [patch]Asterisk doesn't support the dynamic payload change in rtp mapping in the 200 OK response is related to ASTERISK-17410 Video dynamic RTP payload type negotiation incorrect when directmedia enabled
Environment:		Attachments:	( 0) A10_sdp.txt ( 1) A11_sdp_1_log.txt ( 2) A11_sdp_1.txt ( 3) A11_sdp_2_log.txt ( 4) A11_sdp_2.txt ( 5) sip.conf
Description:	After upgrading from Asterisk 10 to Asterisk 11 DTMF recognition does not work as expected. I've attached some SDP examples from test calls. # A10_sdp.txt (Callee is Asterisk 10.12.1) Caller sends INVITE with telephone-event 99, Callee answers with telephone-event 99, Caller sends RTP event with 99, DTMF recognition works, everything is fine # A11_sdp_1.txt (Callee is Asterisk 11.5.1) Caller sends INVITE with telephone-event 99, Callee answers with telephone-event 101, Caller sends RTP event with 118 (!), DTMF recognition does not work (here the caller is obviously misbehaving as well) # A11_sdp_2.txt (Callee is Asterisk 11.5.1) Caller sends INVITE with telephone-event 106, Callee answers with telephone-event 101, Caller sends RTP event with 101, DTMF recognition does not work (note that the payload type 101 in the 200 OK is also assigned for G726-32(!)) Could you please take a look at it?
Comments:	By: Pawel Kuzak (pkuzak) 2013-10-29 06:49:06.461-0500 Attached SDP examples of test calls. By: David Woolley (davidw) 2013-10-29 07:27:52.343-0500 Whilst the third case is clearly a regression, there is nothing wrong in Asterisk in the second case. Incidentally, the linked report incorrectly states that the reply should be a subset of the request.  That is not true for codecs, and the only SDP case for which I am aware of its being true is media direction.  RFC 3261 says nothing abut SDP negotiation. By: Jakob Hirsch (jhirsch) 2013-10-29 08:34:22.798-0500 As already noted in (the somewhat ancient) ASTERISK-654, RFC 3264 forbids in "8.3.2 Changing the Set of Media Formats" the change of the payload type number. Even though it may be a little unclear, Mark Spencer acknowledged this reading. An asymmetric payload type number caused malfunction then, and now the same happens with other devices. Even if this would not be Asterisk's fault, this is clearly an interoperability issue. (N.B. We experience this issue with two different SIP peers, which both use Cisco MGX/MGW equipment. It works only with a third one, and probably only because he already uses pt 101 in his INVITE.) By: David Woolley (davidw) 2013-10-29 08:42:27.304-0500 Section 8 of that RFC appears to apply to re-invites, not the original invite. By: Jakob Hirsch (jhirsch) 2013-10-29 09:59:18.822-0500 Maybe, but RFC 3264 Section 6.1 still says "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer." Even though this "only" a SHOULD, this causes the explained interop issue and should therefore be fixed. By: David Woolley (davidw) 2013-10-29 16:36:31.738-0500 Case 3 shows an absolute violation of the RFC, because the same payload type is used by the same end for two different purposes. By: Rusty Newton (rnewton) 2013-10-29 17:26:08.265-0500 @Jakob, @Pawel  This looks like a definite issue, I've set it to the open state. Can you also attach: * an Asterisk full log showing VERBOSE and DEBUG messages at level 5 for each of your scenarios * sip.conf configuration for the friends/peers involved By: Pawel Kuzak (pkuzak) 2013-10-30 05:35:04.520-0500 Attached 3 additional files: - A11_sdp_1.txt - A11-sdp_2.txt - sip.conf By: Pawel Kuzak (pkuzak) 2013-10-30 05:35:20.503-0500 I have attached the requested files. A11_sdp_1_log.txt corresponds to A11_sdp_1.txt. A11_sdp_2_log.txt corresponds to A11_sdp_2.txt. The sip.conf file is equal in both test calls. If you need something more, please let me know. By: Matt Jordan (mjordan) 2013-10-30 08:23:07.105-0500 Just to echo what David Wooley said, the bug here is only the second off nominal scenario. The first is not a bug: Asterisk is a B2BUA and can choose to offer whatever format mapping it wants for DTMF to the UAS. It does not have to reflect the format mapping choices of the inbound call leg. It *should*, however, respond with the same mappings as it was offered; the second scenario is a bug. By: Pawel Kuzak (pkuzak) 2013-11-08 10:46:04.368-0600 Cause I am still assigned to this issue I wanted to ask what is the current status and what is going to happen next. Matt, you admitted that the 2nd scenario is a bug, so I assume this will be fixed in a future release. How about this *should*? I admit that this is not a bug in the 1st scenario, but are you going to change this behaviour anyway? I mean, if you have to touch the code anyway because of the bug. By: Matt Jordan (mjordan) 2013-11-10 19:43:18.878-0600 No, I would not advocate doing anything in the first off nominal scenario (your #2). Just because you're making a code change does not mean it is a good idea to go off in the same area and change more code. In fact, that's almost always a terrible idea, particularly when that part of code is {{chan_sip}}. By: J. DARIO ALVAREZ (aldanet) 2013-11-12 14:40:32.444-0600 Me too!! Every thing was running OK till upgrade to 11.5.1. DTMF is not recognized when calls are received from a third party trough my provider. It works fine when call is received from my provider. Previous version answered INVITE with the same payload type  proposed by the peer (97), but now it answers with payload 101, but then it doesn't recognizes 101 as DTMF. It is still waiting for the proposed payload type (in my case 97) I got back to 1.8.11 while this is fixed.. By: David Woolley (davidw) 2013-11-13 06:40:29.106-0600 I believe Dario's issue is further documented at http://forums.digium.com/viewtopic.php?f=1&t=88354 I think he is claiming that, in a #2 case, Asterisk is not honouring its offer to accept telephony events as codec type 101, although I couldn't get him to provide a trace showing that it was receiving events with that codec type. By: J. DARIO ALVAREZ (aldanet) 2013-11-13 13:17:18.525-0600 David: Trace is provided in the forums case: <------------> This is rtp TYPE 101 not detecting DTMF: [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063767, ts 109280, len 000160) [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:17490 (type 101, seq 023155, ts 2225409544, len 000004) [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063768, ts 109440, len 000160) [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:17490 (type 101, seq 023156, ts 2225409544, len 000004) [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063769, ts 109600, len 000160) [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:17490 (type 101, seq 023157, ts 2225409544, len 000004) [Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063770, ts 109760, len 000160) ---------------------------------------------------------------------------------------------------------------- Packets with payload type 101 were received but Asterisk didn't accepted them as DTMF because it was waiting for type 97 (the original proposal).   I think that correct solution is to accept 97(the value proposed by the peer) on incoming calls and 101 in outgoing calls, as previous version 1.8.11 did. By: J. DARIO ALVAREZ (aldanet) 2013-11-24 15:40:08.763-0600 This issue and ASTERISK-17410 are the same: Incorrect negotation of dynamic payload types in Asterisk 10 and 11. This issue is worth to be closed and change focus to ASTERISK-17410 By: Rusty Newton (rnewton) 2013-12-12 17:20:27.443-0600 Linking with ASTERISK-17410 as they are probably duplicate or related. By: J. DARIO ALVAREZ (aldanet) 2014-01-31 19:50:33.054-0600 Hi: I'd like to know if this issue has been fixed, in that way that upgrade to a newer version is possible, otherwise must stay at 1.8.11... By: Matt Jordan (mjordan) 2014-02-13 15:28:52.340-0600 Just as an FYI, Nitesh has attached a patch that may fix this issue on ASTERISK-23279. If people could go test with that patch and let us know if that fixes this issue, that would be appreciated. (And no, this issue has not been fixed yet, as the status is still Open.) By: Pawel Kuzak (pkuzak) 2014-02-17 05:40:55.509-0600 First test calls were successful, patch seems to work. By: Pawel Kuzak (pkuzak) 2014-03-04 03:25:55.407-0600 You marked this issue as fixed, but it is the patch was not implemented in yesterdays 11.8.0 release, is it? I didn't see it in the change log, is there a reason for this? By: Matt Jordan (mjordan) 2014-03-04 06:23:38.796-0600 Yes, it was on purpose. This issue is fixed in the Asterisk 11 branch, but this issue was fixed after the 11.8.0-rc1 release candidate was made and is thus not fixed in 11.8.0. It was never in any of the release candidates. You can see what issues are fixed in what versions by looking at the 'Target Release/Version' fields, as well as by looking at the release summaries for any of the release candidates or versions. This issue will be included in the next released version of Asterisk 11, which will be Asterisk 11.9.0. By: Pawel Kuzak (pkuzak) 2014-03-04 06:32:37.257-0600 Okay, thank you a lot for the explanation.