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

[David Vossel]

Howdy!

I want to improve the way Asterisk handles forked SIP requests, and I need some feedback from you SIP experts on the changes I'm making.

The following discussion is in regards to this patch that I currently have on reviewboard.  https://reviewboard.asterisk.org/r/776/
 
--- What I want to fix.

If Asterisk is the recipient of multiple legs of a forked SIP Request, it has no way of differentiating those Requests from one another.  This is because the call-id and from-tag can be identical for both requests which leaves only the requests' Via header branch parameter to differentiate the transactions.  At the moment Asterisk does not store or compare branch parameters to match transactions.

--- Forking Examples Asterisk can not handle.

1. A SIP proxy forks a request to separate Request URIs that both end up pointing to the same Asterisk box.  An example of this is forking an INVITE to both a phone and a voice mail extension.  The correct action here is Asterisk should process both of these requests as separate transactions.  Asterisk currently can not differentiate the two Requests.

2. Asterisk is the recipient of two legs of a forked request with the same request URI.  This is rare compared  to the first example, but it does happen.  The correct action is to accept the first request and respond to the second with a 482 (Loop Detected).  At the moment the second request just looks like a retransmit of the first to Asterisk even though they are separate transactions.

--- My proposed fix.

One of the limitations we have with chan_sip is that it was not designed with a transaction layer.  This makes it very difficult to handle certain situations like forked requests.  Implementing a complete transaction layer into the current design is not easy, but it isn't that difficult to store and compare the data associated with a dialog's initial transaction.  After the first transaction of a dialog is complete both sides have exchanged tags which makes uniquely identifying any additional dialog transactions trivial.

With my patch if we receive a request not containing a to-tag, we attempt to match that Request not only by call-id and fromtag, but also by the Request URI and branch parameter of the top Via header.  By doing this we can successfully identify and process the example scenarios discussed earlier.

--- 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.

Another issue this will not resolve is when a Request coming from Asterisk is forked by a stateless proxy.  In this instance Asterisk will receive multiple responses for the single Request that are differentiated by the Via header.  This is something I am not proposing we do anything about at this time.

--- Feedback

I know this does not address all the issues associated with forked requests, but I'm hoping it at least makes it better for the majority of the more common scenarios.  What do you think?

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