Olle,<br><br>I think we're in agreement on what goes into computing the hash key (Call-Id only) and how the collision is resolved. <br><br>> Before you have an established INVITE dialog, there can be several<br>> things happening and matching is a bit more loose. You can get
<br>> multiple 180 ringing from different devices and still not bother with<br>> creating multiple dialogs. You lock in when you get a 200 OK and<br>> establish the dialog. If you get multiple 200 OK, you establish
<br>> several dialogs and kill the ones you don't want to keep.<br><br>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.
<br><br>Raj<br><br><br><div class="gmail_quote">On Dec 23, 2007 2:19 AM, Johansson Olle E <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>23 dec 2007 kl. 01.16 skrev Raj Jain:<br><div class="Ih2E3d"><br>> Hi Steve,<br>><br>> > So, TELL ME, please, that if totag is empty, that You Never Will<br>> See more than one dialog with the same callid,
<br>> > and mayhaps with different tag field values, or better yet, with<br>> different theirtag values.<br>><br>> I'd not get into the fundamental root of the problem (which is that<br>> we currently don't have a notion of sessions, dialogs and
<br>> transactions as separate state machines), but to answer your<br>> question -- you could have a situation where a proxy forks an INVITE<br>> from Asterisk to several UASs some of which are RFC 2543 based.<br>
> These UASs may not insert a To tag in their responses (To/From tags<br>> were optional in RFC 2543).<br>><br>> I'm not sure I fully understand what all goes into computing your<br>> hash key, but To tag should not be a part of it (simply because it
<br>> could be absent). I've personally dealt with this problem (in a<br>> different implementation) by only hashing on the Call-ID and then<br>> resolving the collision by checking something to the effect of the
<br>> following:<br>><br>> (!totag[0] && !p->tag[0]) || (p->tag[0] && match(p->tag,totag))<br>><br><br></div>I think it will be very hard implementing a hash, since the unique<br>identifiers for a "session" keeps changing during call setup and the
<br>situation where the session forks. If Asterisk sends an INVITE to a<br>forking stateless proxy, we might get the same invite back with the<br>same call-id, the same From-tag but different request URI's and<br>different branch headers in the topmost via header.
<br><br>To simplify, keep the Call ID as the unique identifier for the primary<br>search to make it fast. Multiple call-IDs will happen in a few cases<br>in situations where you have a SIP proxy infrastructure or interface
<br>to a SIP service provider. Make it possible for a PVT to have a linked<br>list of instances with the same Call-ID, but different to/from tags or<br>branches. So we first find the proper list for the Call-ID, then start
<br>matching the rest.<br><br>The invitestate status tells you whether you have an established<br>dialog or not, which is helpful.<br><br>Before you have an established INVITE dialog, there can be several<br>things happening and matching is a bit more loose. You can get
<br>multiple 180 ringing from different devices and still not bother with<br>creating multiple dialogs. You lock in when you get a 200 OK and<br>establish the dialog. If you get multiple 200 OK, you establish<br>several dialogs and kill the ones you don't want to keep.
<br><font color="#888888"><br>/O<br></font><div><div></div><div class="Wj3C7c"><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">
http://www.api-digital.com--</a><br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev
</a><br></div></div></blockquote></div><br>