On 3 August 2010 16:00, Nitin Kapoor <[email protected]> wrote: > Hello All, > > Thanks for the reply. > > Here is another problem i observed into the "m" line, but not sure whether > this is the issue or not. > > I noticed the wild space after "101" into the m line. > > m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56 > 118 *101 * > > Could anyone please let me know whether this correct or not to have the wild > space.
Consulting the RFC4566 BNF (http://tools.ietf.org/html/rfc4566#section-9) reveals: media-field = %x6d "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF fmt = token token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E token = 1*(token-char) So, the extra space shouldn't strictly be there. However, I can't imagine the SBC parser being as strict as to respond with 488 just because of an extra space in the payload/format list. That SBC wouldn't become very popular... As Dale Worley suggested, the whole payload/format list seems a bit suspicious and broken. I guess the SBC just can't cope with missing a=rtpmap for payload numbers actually being listed. Also, payload type/number 2 is reserved according to IANA's list (http://www.iana.org/assignments/rtp-parameters), due to conflicting previous usage. If it's intentional you would at least need an a=rtpmap description to tell what codec is actually meant. Something is rotten! -- Tom _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
