asterisk users - Mar 2005 - Problem parsing unusual SIP/SDP

Hi,

I'm testing Asterisk with a new provider.  On calls to US
toll-free numbers, there is no audio (calls to normal numbers
are ok).

In response to a valid INVITE from Asterisk, something like
this is received:

SIP/2.0 183 Session Progress
v:SIP/2.0/UDP [my public IP]:5060;branch=z9hG4bK62d91cea
CSeq:103 INVITE
i:7a1791cf52d6f3dc2d12b208051d0a21@[provider].com
f:"Test User" <sip:[my phone
number]@[provider].com>;tag=as341d210b
t:<sip:18003253535@[provider].com>;tag=b6e96dae-1dd1-11b2-a01e-b03162323164+b6e9
6dae
m:sip:18003253535@192.168.201.25:5075
c:application/sdp
l:170

v=0
o=- 3459442714 3459442714 IN IP4 192.168.201.25
s=SIP Call
c=IN IP4 192.168.201.11
t=0 0
m=audio 52322 RTP/AVP 0
c=IN IP4 [provider public IP]
a=rtpmap:0 PCMU/8000

The "200 OK" arrives with similar SDP.  Note that there are two
connection addresses in the SDP, one private (the provider's --
I'm not using NAT) and one public.  The problem is that
Asterisk attempts to send media to the private address; of course,
that doesn't work.

If I use the provider-supplied ATA, or a Cisco ATA, it works fine.
The SDP is similar, but the ATAs know to send media to the
correct public IP.

At first, I thought that the incoming SDP was improper, but RFC 2327
says:

   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.

So, it appears that Asterisk is not interpreting the SDP correctly.

I'm running Asterisk@Home (Asterisk 1.0).  Is it possible that this bug
has already been fixed in a later version (I can't find anything that
seems relevant at bugs.digium.com)?

If so, is there an easy way to upgrade Asterisk@Home from the CVS?

If not, could someone please suggest where to start looking at the code?

Thanks,

Stewart

have you tried to set the

externip=xxx.xxx.xxx.xxx
localnet=xxx.xxx.xxx.0/255.255.255.0

settings in your sip.conf? it corrected similar problems for me.

michael

Stewart Nelson wrote:
> I'm running Asterisk@Home (Asterisk 1.0).  Is it possible that this bug
> has already been fixed in a later version (I can't find anything that
> seems relevant at bugs.digium.com)?
This issue (multiple c= lines) has already been fixed in CVS HEAD (if 
'pedantic' SIP parsing is enabled), but the fix was not backported to 
the stable branch.

You are welcome to enter a bug in the Mantis bugtracker to request that 
the same fix be put into the stable branch, but there may be some 
opposition since that would potentially change existing behavior there.

>> I'm running Asterisk@Home (Asterisk 1.0).  Is it possible that this
bug
>> has already been fixed in a later version (I can't find anything
that
>> seems relevant at bugs.digium.com)?
> This issue (multiple c= lines) has already been fixed in CVS HEAD (if 
> 'pedantic' SIP parsing is enabled), but the fix was not backported
to
> the stable branch.
Kevin, many thanks for the advice.  The good news is that I got it to
work!  However, there is quite a bit of bad news:

First, there seems to be something about Asterisk@Home that is
incompatible with CVS.  After I did the checkout, there were errors
at install time, resulting from an out-of-date sounds.txt file.
Deleting the file and rerunning CVS resulted in the same wrong version.
I manually retrieved the latest sounds.txt, and the install ran ok,
but there were other old files, including the chan_sip.c that I needed.
So, I deleted the zaptel, libpri and asterisk directories, and ran CVS
from scratch.  Asterisk now built ok, and ran with no obvious problems.

However, when I set pedantic=yes, I can't call out at all via the
provider, though I can still call from one SIP extension to another.
It appears that the 183 Progress is not being "seen" by Asterisk,
because the "SIP/provider-xxxx is making progress passing it ..."
message does not appear, and the provider keeps retransmitting the 183.
Unfortunately, nothing in the log looks like an error report, and I
don't know how to debug this further.

So, I left out the pedantic=yes, and in chan_sip.c where it says
 /* Check for Media-description-level-address for audio */
I patched:
 if (pedanticsipchecking) {
to:
 if (1) {
and it now works fine with this provider.
> You are welcome to enter a bug in the Mantis bugtracker to request that 
> the same fix be put into the stable branch, but there may be some 
> opposition since that would potentially change existing behavior there.
I doubt that this fix would "break" any SDP from another device,
because
RFC 2327 clearly states that a media-level c= should override a
session-level c=, and e.g. the ATA 186 follows that rule.
However, the code calls ast_gethostbyname to get the IP, with comment:
/* XXX This could block for a long time, and block the main thread! XXX */
so maybe it's not a good idea to have it on by default (in typical cases,
though, the IP would be numeric and there would be no blocking).

And, the fix would do me no good, unless the problem with pedantic=yes
also gets found and fixed somehow.

How should I proceed?  IMO, this provider offers an excellent combination
of price, reliability, quality, and support, and I believe that many in
Asterisk community would want to use them.  AFAICT, their SIP/SDP does
not actually violate any RFCs.

[I have not identified them, because they are not a BYOD company,
although their TOS does not prohibit alternative interface devices.
I want to get their permission first, but would like to approach them
with "Your system works great with Asterisk ..."]

Thanks,

Stewart

> The next step would to be turn pedantic=yes back on, then generate a
> failing call with 'sip debug', 'set verbose 255' and
'set debug 255' in
> place. Capture all the output (there will be a lot) and then post a bug
> in Mantis describing the situation and attaching the output file.
Kevin, thanks again for the help.  I now understand why it's not working,
but don't know enough to suggest a fix, or even to say what routine
has the bug.

The problem relates to the additional checking done by find_call
when pedantic=yes.

In response to the original INVITE, the provider sends a challenge with a tag:

SIP/2.0 401 UnAuthorized
[other headers]
f:"Test User" <sip:[my phone
number]@[provider].com>;tag=as5822c02a
t:<sip:[dest number]@[provider].com>;tag=1628255942721615
WWW-Authenticate: Digest ...
[other headers]

Asterisk saves the tag in the theirtag member of the sip_pvt structure
and issues a new INVITE with suitable credentials.

The provider initiates the call and returns progress:

SIP/2.0 183 Session Progress
[other headers]
f:"Test User" <sip:[my phone
number]@[provider].com>;tag=as5822c02a
t:<sip:[dest
number]@[provider].com>;tag=e5559e9a-1dd1-11b2-b48e-b03162323164+e5559e9a

Well, provider is now sending a different tag, so Asterisk does not
find a match, assumes that this response is for a call it does not know
about, and discards it.

Although this is ugly SIP, one can understand why it would happen, and
IMHO it is legal.  RFC 3261 says:

   When the originating UAC receives the 401 (Unauthorized), it SHOULD,
   if it is able, re-originate the request with the proper credentials.

I believe that "re-originate" means that we are starting a new
"dialog"
and the old tag should be discarded.

However, I don't know where or when this should be done.  In fact,
I don't understand why the tag checking happens on outgoing calls at
all.  A comment in chan_sip.c says:

/* In principle Call-ID's uniquely identify a call, however some vendors
   (i.e. Pingtel) send multiple calls with the same Call-ID and different
   tags in order to simplify billing.  The RFC does state that we have to
   compare tags in addition to the call-id, but this generate substantially
   more overhead which is totally unnecessary for the vast majority of sane
   SIP implementations, and thus Asterisk does not enable this behavior
   by default. Short version: You'll need this option to support
conferencing
   on the pingtel */

That makes sense, but since Asterisk always generates a unique Call-ID for
each call, I would think that tag checking on outgoing calls would be
unnecessary. However, the routine carefully chooses the From or To field
according to the call direction, so there is probably a good reason to
check all calls.  Indeed, the change that I would request might break
operation with some other provider or device.

Is it worth posting such a vague bug report?  Unfortunately, I know
absolutely nothing about the internals of Asterisk.

Thanks,

Stewart

>> Is it worth posting such a vague bug report?  Unfortunately, I know
>> absolutely nothing about the internals of Asterisk.
> Yes, please do, but make sure you include a full 'sip debug/set verbose
> 255/set debug 255' as an attachment in the bug. Also include the 
> relevant portions of your sip.conf file (with secrets removed, of course).
I submitted a bug report, and was amazed that within two hours, Mark had
found the bug, fixed it, and posted updated source code.  The code works great.
There are now no problems on incoming or outgoing calls.

I never get such good support for commercial software, even on high-end
packages that charge an arm and a leg for maintenance.

Many thanks to Mark, Kevin, and the Asterisk team.

--Stewart

Stewart Nelson wrote:
> I never get such good support for commercial software, even on high-end
> packages that charge an arm and a leg for maintenance.
> 
> Many thanks to Mark, Kevin, and the Asterisk team.
Thanks for the kind words, we appreciate it!