[pjsip] process_m_answer in sdp_neg.c

[Ruud Klaver]

On 23 Jul 2008, at 15:27, Benny Prijono wrote:

> On Wed, Jul 23, 2008 at 12:51 PM, Ruud Klaver <ruud at ag-projects.com>  
> wrote:
> Hi,
>
> I'm trying to use the SDP negotiation part of pjmedia to process SDP
> related to MSRP (RFC 4975), but ran into some issues when it tried to
> complete the negotiation procedure. The process_m_answer function
> assumes that the formats in the m= line are integers and starts
> looking for rtpmap attributes, while for MSRP the formats aren't
> actually used and are set to a single "*".
>
>
> Actually it's not that bad, we have this in sdp_neg.c:618:
>
>         /* Find matching answer */
>         pt = pj_strtoul(fmt);
>
>         if (pt < 96) {
>           for (j=0; j<answer->desc.fmt_count; ++j) {
>                if (pj_strcmp(fmt, &answer->desc.fmt[j])==0)
>                  break;
>         }
>
> The idea is if pt is not a payload type number, pj_strtoul() should  
> return 0 and the "if (pt<96)" checking above will be executed and it  
> shouldn't need to check for rtpmap.
>
> But alas, there seems to be a bug in pj_strtoul(). Instead of  
> stopping when it finds a non-digit character, it continues to treat  
> the input as digit, causing it to return garbage value. I've just  
> fixed this in the latest SVN.
>

Great, you dug deeper than me. :)

Indeed it was some assertion in that branch that failed on me. Thanks  
for fixing it.


> Maybe there should be a check to see if the protocol field (called
> transport in pjsip) starts with RTP, as RFC 4566 states:
>
>
> I believe "proto" is shorthand  for "transport protocol", so calling  
> it transport is not too far off . :)
>
>       If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
>       sub-fields contain RTP payload type numbers.
>
> But also:
>
>       If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
>       reference a media type describing the format under the "audio",
>       "video", "text", "application", or "message" top-level media
>       types.
>
>       ...
>
>       For media using other transport protocols, the <fmt> field is
>       protocol specific.
>
> But then the question is, how would pjmedia declare the negotiation to
> have succeeded?
>
>
> Currently, if both media type and transport protocol match, and  
> there is matching format. That's probably good enough for MSRP.
>
> Cheers
>  Benny

That works for me. Anything beyond that should be handled by the  
application.

Ruud Klaver
AG Projects