Is This SDP Payload Asterisk Created Valid?

Home » Asterisk Users » Is This SDP Payload Asterisk Created Valid?
Asterisk Users 4 Comments

We have an issue with a customer where when calls are sent to one of their offices as soon as the call is answered the call fails. We are performing remote bridging and switching the audio from the server which initiated the call to our switch which is on the same network. After the call is answered we switch the audio which is accepted fine but we then send the following packet and get a SIP/488 response from the far end. This packet seems to be updating the version for the o= session id which is fair enough. Its sending the c= connection data but not the m=audio line which appears to be what the remote end is complaining about.

Can anyone with a bit more knowledge about the SDP standard tell me if what asterisk is doing is correct?
Or if it must be a bug with our customers equipment?

Thanks Gareth

U 2013/09/27 11:04:55.352854 88.x.x.25:5060 -> 213.x.x.24:5060
INVITE sip:0844xxxxxx@146.x.x.10:54900 SIP/2.0. Via: SIP/2.0/UDP 88.x.x.25:5060;branch=z9hG4bK62215713. Route:

4 thoughts on - Is This SDP Payload Asterisk Created Valid?

  • Reading RFC2327 it cais the c= line ‘must’ be present in all updates while ‘m=’ media lines are optional. I am therefore inclined to believe that Asterisk is working correctly and there is a bug in the customers SIP equipment. But thats just my personal interpretation from briefly reading the standard.

  • Gareth Blades wrote:

    The SDP you posted should be fine BUT my question becomes… have you modified chan_sip at all? I don’t think it should be possible for it to not put any media lines in…

    Cheers,

  • No we havent made any changes to chan_sip. The servers were a fresh install a short while ago straight to 11.2-cert1 as we wanted a later kernel version to make use of the new timing source it provides. We then upgraded to cert2 after it was released.

    The only thing we have changed is the setting of a DYNAMIC_FEATURES
    variable which was stopping remote bridging from being performed which is probably what has highlighted this fault.

    Thanks Gareth

  • Well looking at RFC4566 section 5 :-

    Some lines in each description are REQUIRED and some are OPTIONAL,
    but all MUST appear in exactly the order given here (the fixed order
    greatly enhances error detection and allows for a simple parser).
    OPTIONAL items are marked with a “*”.

    Session description
    v= (protocol version)
    o= (originator and session identifier)
    s= (session name)
    i=* (session information)
    u=* (URI of description)
    e=* (email address)
    p=* (phone number)
    c=* (connection information — not required if included in
    all media)
    b=* (zero or more bandwidth information lines)
    One or more time descriptions (“t=” and “r=” lines; see below)
    z=* (time zone adjustments)
    k=* (encryption key)
    a=* (zero or more session attribute lines)
    Zero or more media descriptions

    Time description
    t= (time the session is active)
    r=* (zero or more repeat times)

    Media description, if present
    m= (media name and transport address)
    i=* (media title)
    c=* (connection information — optional if included at
    session level)
    b=* (zero or more bandwidth information lines)
    k=* (encryption key)
    a=* (zero or more media attribute lines)

    So if I am reading that correctly the m= line is required only if we include a media description entry. It basically sais its required if we decide to include it (yes I know that doesnt make sense). What I presume this means is that if a media description is included such as there being a ‘a=’ line then the ‘m=’ line then becomes required. So it still sounds like Asterisk is behaving correctly.