[Asterisk-Users] Problem parsing unusual SIP/SDP

[Stewart Nelson]

> 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