[Home]

Summary:ASTERISK-01021: [patch] Debugging output when parsing SDP codecs
Reporter:Olle Johansson (oej)Labels:
Date Opened:2004-02-10 14:06:04.000-0600Date Closed:2004-09-25 02:48:28
Priority:MinorRegression?No
Status:Closed/CompleteComponents:
Versions:Frequency of
Occurrence
Related
Issues:
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.


"Normally be"

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.