[asterisk-dev] Improving how Asterisk handles forked SIP requests.
Klaus Darilion
klaus.mailinglists at pernau.at
Tue Jul 20 02:55:22 CDT 2010
Am 19.07.2010 16:42, schrieb 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.
>
Yes, the to-tag which Asterisk is sending in 401/407 is just ephemeral.
No need to store it (except in the transaction layer to re-send the
response in case of incoming retransmissions).
regards
klaus
More information about the asterisk-dev
mailing list