[asterisk-dev] dialog matching

[Raj Jain]

Olle,

I think we're in agreement on what goes into computing the hash key (Call-Id
only) and how the collision is resolved.

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

You will need to create multiple EARLY dialogs as you get multiple 1XXs with
different To tags. You need that state information for supporting UPDATE and
PRACK during early dialogs.

Raj


On Dec 23, 2007 2:19 AM, Johansson Olle E <oej at edvina.net> wrote:

>
> 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
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20071223/10b4821c/attachment.htm