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

[Klaus Darilion]

Am 19.07.2010 16:50, schrieb Olle E. Johansson:
>
> 19 jul 2010 kl. 16.46 skrev David Vossel:
>
>>
>>
>>
>> ----- Original Message -----
>>> From: "Klaus Darilion"<klaus.mailinglists at pernau.at>
>>> To: asterisk-dev at lists.digium.com
>>> Sent: Monday, July 19, 2010 8:01:52 AM
>>> Subject: Re: [asterisk-dev] Improving how Asterisk handles forked SIP requests.
>>> Am 19.07.2010 07:22, schrieb 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.
>>>
>>> The first transaction (without credentials) is not related to the
>>> second
>>> transaction (with credentials) - at least within the SIP transaction
>>> layer. The first transaction does not create a dialog.
>>>
>>> regards
>>> Klaus
>>>
>>> PS: A pure SIP transaction layer would be great!
>>>
>>
>> Now this makes sense.  Thanks Klaus.  A transaction layer would be awesome.  It really feels like anything I am attempting to do here is a hack, but outside of re-writing chan_sip I'm not sure what other option we have.
>
> Well, what Klaus says is formally correct, but in practise not followed by most implementations, they treat both transactions as a dialog. As I said, you can cheat a bit by checking a lot of data and making sure you have a valid nonce that you recognize.
>

I just checked the RFC but could not find a detailed description how the 
2nd request should be constructed. I only found:

    If a UA receives a Proxy-Authenticate header field value in a 401/407
    response to a request with a particular Call-ID, it should
    incorporate credentials for that realm in all subsequent requests
    that contain the same Call-ID.  These credentials MUST NOT be cached
    across dialogs; however, if a UA is configured with the realm of its
    local outbound proxy, when one exists, then the UA MAY cache

So, it seems that a nonce is correlated with a call-id. So, in case of 
incoming forked call, why not sending back the same nonce on both branches?

regards
klaus