Summary:ASTERISK-07528: Wrong parsing of SDP if multiple c= lines present
Reporter:psm (psm)Labels:
Date Opened:2006-08-13 07:47:22Date Closed:2006-08-19 23:51:28
Versions:Frequency of
Description:When SDP in incoming INVITE contains multiple c= lines (one at session level and another at media level), the c= line at media level takes precedence and should be used (RFC2327). However Asterisk uses the first c= line it finds in SDP and ignores the second one which causes one-way audio.

Here is an example of such SDP:

o=CiscoSystemsSIP-GW-UserAgent 4407 8950 IN IP4
s=SIP Call
c=IN IP4
t=0 0
m=audio 18014 RTP/AVP 18 8 0
c=IN IP4
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000

Asterisk should send RTP packets to, but it incorrectly sends them to

Comments:By: Sergey Basmanov (sb) 2006-08-14 03:55:52

from chan_sip.c:
       /* Check for Media-description-level-address for audio */
       if (pedanticsipchecking) {
               c = get_sdp_iterate(&destiterator, req, "c");
               if (!ast_strlen_zero(c)) {
                       if (sscanf(c, "IN IP4 %256s", host) != 1) {
                               ast_log(LOG_WARNING, "Invalid secondary host in c= line, '%s'\n", c);
                       } else {
                               /* XXX This could block for a long time, and block the main thread! XXX */
                               hp = ast_gethostbyname(host, &ahp);
                               if (!hp) {
                                       ast_log(LOG_WARNING, "Unable to lookup host in secondary c= line, '%s'

So, You can try option 'pedantic=yes' in sip.conf

By: psm (psm) 2006-08-14 06:15:31

I think proper c= line parsing according to RFC should be on by default.

By: Serge Vecher (serge-v) 2006-08-14 09:59:22

psm: does enabling pedantic=yes work, though? Because if it does, the solution could be enabling that code block by default ...

Also, a reference to a specific paragraph in RFC that says multiple c= lines _must_ be processed in the way that you describe would help.


By: psm (psm) 2006-08-14 10:39:07

Yes, I think removing "if (pedanticsipchecking)" and enabling the codeblock by default will do.

Here's the quote from RFC2327, page 11:

  Connection Data

  c=<network type> <address type> <connection address>

  The "c=" field contains connection data.

  A session announcement must contain one "c=" field in each media
  description (see below) or a "c=" field at the session-level.  It may
  contain a session-level "c=" field and one additional "c=" field per
  media description, in which case the per-media values override the
  session-level settings for the relevant media.

By: Joshua C. Colp (jcolp) 2006-08-16 11:26:11

There's a few things we should do per spec by default (like multiline header parsing in SIP) but we don't because for most cases they aren't needed so it's just a performance hit. I'm a little iffy on whether I consider this something we should do by default personally as one option and boom, it works. Any thoughts from others?

By: Serge Vecher (serge-v) 2006-08-16 11:38:42

I recall oej talking about removing the 'pedantic' option all together in one of the bugs. Will add reference when I find it. The change would need to happen in trunk, IMHO, not 1.2.x

By: psm (psm) 2006-08-17 07:59:58

Well, presenting wrong IP address to the RTP session is a major bug causing non-functional calls (one-way audio).

Moreover it seems that this bug was already fixed in trunk since I don't see "if (pedanticsipchecking)" around this code block - so it just needs to be fixed in 1.2.x

By: Olle Johansson (oej) 2006-08-18 02:21:33

Well, I need a clear answer: Did it work when you turned on pedantic in sip.conf?

By: psm (psm) 2006-08-18 03:56:48

Sure it worked, but I don't consider this to be the solution. Every Cisco VoIP gateway with recent IOS is sending two c= lines and depending on overall SIP setup they might differ like in the example above - so there's serious interop issue.

By: Joshua C. Colp (jcolp) 2006-08-19 23:51:27

Turned on by default now in 1.2.