Summary:	ASTERISK-23279: [patch]Asterisk doesn't support the dynamic payload change in rtp mapping in the 200 OK response
Reporter:	NITESH BANSAL (nbansal)	Labels:
Date Opened:	2014-02-12 03:21:40.000-0600	Date Closed:	2014-02-21 12:28:03.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:	11.4.0	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-22789 chan_sip SDP incorrect negotiation for RTP payload types causes DTMF recognization failure and appears to violate RFC is related to ASTERISK-17410 Video dynamic RTP payload type negotiation incorrect when directmedia enabled
Environment:	Debian wheezy amd64	Attachments:	( 0) dynamic_payload_change.patch ( 1) sip.conf ( 2) uac_asterisk.xml ( 3) uas_asterisk.xml
Description:	Scenario: Asterisk sends the INVITE proposing alaw and telephone-event, it proposes rtpmap:101 for telephone-event. Peer responds with 2xx, it answers with alaw and telephone-event also, but it proposes a different rtpmap number(rtpmap:103) for telephone-event. Expected Behaviour: Asterisk should honour the rtpmapping in the response and send DTMF packets using 103 as payload type for DTMF. Actual Behaviour: Asterisk sends DTMF packets using payload type 101. Regards, Nitesh
Comments:	By: NITESH BANSAL (nbansal) 2014-02-12 03:28:56.075-0600 Attached SIPP scripts can be used to reproduce this issue. The only thing missing is extensions.conf, but you can write a very basic extensions.conf to route the call between these two peers. I have also written an automated test case for this scenario, but i am using some external tools for DTMF validation. I have a C code which dumps the RTP packets on a IP/Port in text format and then i have a simple perl script which can parse the RTP dump and scan for DTMFs. If you think that these external tools can be integrated in asterisk testsuite, i would be happy to provide the source code. Regards, Nitesh By: NITESH BANSAL (nbansal) 2014-02-12 03:41:14.079-0600 Hello, Here is the fix for this issue. Explanation: Asterisk uses the function ast_rtp_codecs_payload_code to find the payload code for a specific format. For RTPEvent packets, asterisk_format is NULL and rtp_code is 1, ast_rtp_codecs_payload_code calls the function  ""ao2_find(codecs->payloads, &code, OBJ_NOLOCK | OBJ_KEY)"" to find the payload code, this is incorrect, because by default ao2_find will do the search based on payload code instead of rtp_code. To fix this, i have added a new function "rtp_payload_type_find_nonast_format", which search the codecs->payloads based on the rtp_code. I request you guys to review this patch.   By: Matt Jordan (mjordan) 2014-02-13 15:24:46.503-0600 Off the cuff, I don't see anything wrong with the patch. My only concern would be turning a (usually) O(1) search to an O(n) search, which is what the change from {{ao2_find}} to {{ao2_callback}} would do. Without resorting to another container, however, there may not be much else that can be done here. It might be a good idea to go ahead and push the patch up to review board to see if anyone else has any thoughts on it, or if there might be another way to solve it. By: Niklas Larsson (pnlarsson) 2014-02-14 02:03:17.148-0600 Tested on 11.6.0 and it solves my trouble when the other side sends a=rtpmap:99 telephone-event/8000 -> with this patch asterisk responds with a=rtpmap:99 telephone-event/8000 and DTMF is working.