|Summary:||ASTERISK-01021: [patch] Debugging output when parsing SDP codecs|
|Reporter:||Olle Johansson (oej)||Labels:|
|Date Opened:||2004-02-10 14:06:04.000-0600||Date Closed:||2004-09-25 02:48:28|
|Environment:||Attachments:||( 0) rtp.diff|
|Description:||Asterisk output the wrong codec name when using 'sip debug' and parsing codecs. This patch fixes that.|
****** ADDITIONAL INFORMATION ******
Applies to rtp.c, rtp.h and chan_sip.c
Yes, the new function in rtp.c could be a # macro, but well... Now it's a function.
|Comments:||By: Olle Johansson (oej) 2004-02-11 14:21:36.000-0600|
Got information that the patch is basically wrong, the first line of SDP doesn't use the IANA RTP codes. COming back with another approach, later...
By: Olle Johansson (oej) 2004-02-11 15:02:40.000-0600
From the SDP RFC (RFC2327):
m=<media> <port>/<number of ports> <transport> <fmt list>
m=audio 5004 RTP/AVP 0 8 4 18 2 15
The fourth and subsequent sub-fields are media formats. For audiovand video, these will normally be a media payload type as defined in the RTP Audio/Video Profile.
IANA claims that payload types 96--127 is dynamic (ref [RFC3551]), so it should be safe to use the static table for payloads under 96.
From the RFC again:
Instead, the payload type number should be used to specify the
format for static payload types and the payload type number along
with additional encoding information should be used for dynamically
allocated payload types.
So the patch is right for payloads below 96. Wrong for payloads over 95. Right?
By: Brian West (bkw918) 2004-04-18 01:51:39
Can you post an update?
By: Mark Spencer (markster) 2004-05-01 16:53:19
Actually the patch produces non-meaningful information since you're basing it off the static payload types and not the dynamic ones. It's probably more meaningful just to print the number. Further, having a high or low number could cause your code to crash since it doesn't do any bounds checking. I've just changed it to print the number and calling this closed.