[asterisk-dev] dialog matching

[Johansson Olle E]

23 dec 2007 kl. 01.16 skrev Raj Jain:

> Hi Steve,
>
> > So, TELL ME, please, that if totag is empty, that You Never Will  
> See more than one dialog with the same callid,
> > and mayhaps with different tag field values, or better yet, with  
> different theirtag values.
>
> I'd not get into the fundamental root of the problem (which is that  
> we currently don't have a notion of sessions, dialogs and  
> transactions as separate state machines), but to answer your  
> question -- you could have a situation where a proxy forks an INVITE  
> from Asterisk to several UASs some of which are RFC 2543 based.  
> These UASs may not insert a To tag in their responses (To/From tags  
> were optional in RFC 2543).
>
> I'm not sure I fully understand what all goes into computing your  
> hash key, but To tag should not be a part of it (simply because it  
> could be absent). I've personally dealt with this problem (in a  
> different implementation) by only hashing on the Call-ID and then  
> resolving the collision by checking something to the effect of the  
> following:
>
> (!totag[0] && !p->tag[0]) ||  (p->tag[0] && match(p->tag,totag))
>

I think it will be very hard implementing a hash, since the unique  
identifiers for a "session" keeps changing during call setup and the  
situation where the session forks. If Asterisk sends an INVITE to a  
forking stateless proxy, we might get the same invite back with the  
same call-id, the same From-tag but different request URI's and  
different branch headers in the topmost via header.

To simplify, keep the Call ID as the unique identifier for the primary  
search to make it fast. Multiple call-IDs will happen in a few cases  
in situations where you have a SIP proxy infrastructure or interface  
to a SIP service provider. Make it possible for a PVT to have a linked  
list of instances with the same Call-ID, but different to/from tags or  
branches. So we first find the proper list for the Call-ID, then start  
matching the rest.

The invitestate status tells you whether you have an established  
dialog or not, which is helpful.

Before you have an established INVITE dialog, there can be several  
things happening and matching is a bit more loose. You can get  
multiple 180 ringing from different devices and still not bother with  
creating multiple dialogs. You lock in when you get a 200 OK and  
establish the dialog. If you get multiple 200 OK, you establish  
several dialogs and kill the ones you don't want to keep.

/O