[asterisk-dev] Improving how Asterisk handles forked SIP requests.

Olle E. Johansson oej at edvina.net
Mon Jul 19 09:52:14 CDT 2010


19 jul 2010 kl. 16.42 skrev David Vossel:

> 
> 
> 
> 
> ----- Original Message -----
>> From: "Olle E. Johansson" <oej at edvina.net>
>> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
>> Sent: Monday, July 19, 2010 2:49:02 AM
>> Subject: Re: [asterisk-dev] Improving how Asterisk handles forked SIP requests.
>> 19 jul 2010 kl. 07.22 skrev David Vossel:
>> 
>>> --- Forking issues this will not fix.
>>> 
>>> One issue this does not resolve is forked requests with different
>>> request URIs that require Authorization. When Authorization is
>>> required the totag won't be provided until the second transaction of
>>> the dialog. With my current patch it is impossible guarantee a
>>> correct dialog match for the second transaction of these dialogs. I
>>> do not yet have a simple solution for this.
>> 
>> You are receiving these requests and set different to-tags, since you
>> separate them on the inbound. Or am I missing something? If the device
>> doesn't send you the to-tag on the second request, you can still match
>> on the callid/from-tag, branch tag and the nonce since they return the
>> nonce to you.
>> 
>> /O
>> --
> 
> 
> Ah yes, the nonce.  That will allow me to match correctly here. Thanks!
> 
> For Authorization we provide a totag in the 401 Unauthorized response, but the Request after that apparently doesn't have to use that totag.  It's not until the 200ok is provided after the second Request containing the Authorization header that that to-tag sticks.  I'm betting this is because the first transaction is really a separate dialog from the second, but Asterisk isn't designed to work that way.
> 
Well, the nonce is sent to a device and should be valid for a limited time. We should store it in the device and not in the pvt to be really correct, since it's really a new dialog coming back to us with authorization in all types of requests, including REGISTER and INVITE.

/O




More information about the asterisk-dev mailing list