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

[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 9:52:14 AM
> Subject: Re: [asterisk-dev] Improving how Asterisk handles forked SIP requests.
> 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
> 


Rather than attempt to match a dialog by nonce, I updated the patch to guarantee an incoming request containing Authentication will only match to a sip_pvt that's last request matches the incoming request's Request URI.  This seems like a good solution to me as a request with Authentication is supposed to be exactly the same as the initial request except with the addition of an Authentication field.  Is there anything I am over looking here?  I updated the patch on reviewboard to reflect this change.

David Vossel
Digium, Inc. | Software Developer, Open Source Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
The_Boy_Wonder in #asterisk-dev