[Home]

Summary:ASTERISK-06393: dynamic payload type
Reporter:tom (tom)Labels:
Date Opened:2006-02-22 00:29:28.000-0600Date Closed:2006-05-11 10:02:53
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:suppose phoneA call phoneB via Asterisk1.2.0

phoneA->Asterisk invite:
m=video 7080 RTP/AVP 96
a=rtmpmap:96 H263-1998/9000

then Asterisk->phoneB invite:
m=video 67080 RTP/AVP 103
a=rtmpmap:103 H263-1998/9000

PhoneB->Asterisk 200OK:
m=video 7080 RTP/AVP 103
a=rtmpmap:103 H263-1998/9000

But Asterisk->PhoneA 200OK:
m=video 7080 RTP/AVP 103
a=rtmpmap:103 H263-1998/9000
Thus, both Asterisk and PhoneA have to be prepared to receive H263+ media at either payloadtype 96 or 103. But Actually Asterisk can't recongize payload type 103. Therefore, here it should answer with "a=rtmpmap:96 H263-1998/9000". The payload type should be the same as the payloadtype in the invite SDP from PhoneA to Asterisk.



Comments:By: tom (tom) 2006-02-22 01:05:08.000-0600

Do u config dtmfmode=rfc2833?
By: tom (tom) 2006-02-22 01:08:18.000-0600

sorry, I post a wrong note above. The above note should be destined to [Experimental Features 0004825.
By: Vasil Yosifov (vasil yosifov) 2006-02-22 10:24:05.000-0600

Hello Guys,

The problem seems to be general parsing of rtpmap attribute. According RFC 2327, p.22 "The general form of an rtpmap attribute is:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]". As you seen, there is no white space between 'rtpmap:' and '<payload type>', but the current implementation expects whitespace. For reference, see sip_chan.c, function process_sdp():
if (sscanf(a, "rtpmap: %u %[^/]/", &codec, mimeSubtype) != 2) continue;
This leads to improper handling of rtpmap attribute. The fix seems to be trivial, just remove whitespace:
'if (sscanf(a, "rtpmap:%u %[^/]/", &codec, mimeSubtype) != 2) continue;'
Currently, I cannot check it, but I guess it will work.
By: tom (tom) 2006-02-22 20:00:08.000-0600

Thanks. As I tested, the sscanf() function is smart enough to detect the payloadtype with or without the whitespace. I was working on Linux platform.
By: Vasil Yosifov (vasil yosifov) 2006-02-23 02:07:03.000-0600

Yes, you're right.

Sorry, it was just a guess. I have the same problem when I have description of speex with payload 97 :
m=audio 8000 RTP/AVP 97 100 0 8 3
a=rtmpmap:97 speex/8000
By: Olle Johansson (oej) 2006-03-10 06:21:30.000-0600

Does the problem still exist in the latest 1.2 release version?
By: Olle Johansson (oej) 2006-03-14 01:33:26.000-0600

Please test with the latest 1.2, there has been some changes and I need to know if the problem still exists in your setup. Thanks.
By: tom (tom) 2006-03-14 02:43:43.000-0600

Asterisk can receive H263+ media at either payloadtype 96 or 103. But the phone can only recongnize pt 103 since the answer map H263+ to 103. We can argue that it is the phone's problem. But RFC recommend that the answer SHOULD not change the pt. I think the most appropriate fix is to keep the same pt in the answer.
By: Olle Johansson (oej) 2006-03-14 04:22:56.000-0600

I am not trying to argue, I am asking if the problem exists in the latest version of Asterisk. Please test.
By: tom (tom) 2006-03-14 19:03:12.000-0600

The result is: A* changes the pt in its final answer (200OK), while it can recognize media data with pt 96 or 103 as H263+. The behavior is deemed to be correct but it isn't the best. It still casuses some interoperability problem with the phone since the phone isn't so smart.
RFC3264 says "that same payload type number SHOULD be used for that codec in the answer".
By: tom (tom) 2006-03-14 19:07:42.000-0600

The above test was done with latest A*. Older version A* can't recongize payload type 103.
By: Serge Vecher (serge-v) 2006-05-03 12:08:57

Tom: as per bug guidelines, you need to attach a sip trace indicating the problem.
set debug 4
set verbose 4
sip debug

Attach the full trace here as an attachment...
By: Serge Vecher (serge-v) 2006-05-11 10:02:53

Tom: if this issue still exists in latest 1.2 branch (rev > 26000), please reopen the bug with debugging information I have requested.

Thank you.