yeah! 100%.<br><br>Thanks Timo. Will work on this right away.<br><br>Cheers<br>Jason<br><br><div class="gmail_quote">On Wed, Aug 24, 2011 at 4:55 PM, Timo Reimann <span dir="ltr"><<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On <a href="tel:24.08.2011%2015" value="+12408201115">24.08.2011 15</a>:19, Jason Penton wrote:<br>
> On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>>> wrote:<br>
><br>
> >> My initial thought is to have some sort of direction identifiers<br>
> >> stored in the dialog structure itself. Then using Via and contact<br>
> >> headers we can make a pretty good assumption as to which 'end' of the<br>
> >> spiral and therefore choose the correct dialog in the match<br>
> algorithm.<br>
><br>
> I am not quite sure if I understand how the "ends" of a spiral and the<br>
> available dialog structures in the hash table relate to each other. From<br>
> a technical perspective, the result of an (undetected) spiraled call is<br>
> just a second transaction on the same proxy mapping to the same call. No<br>
> matter whether a request arrives from one end (caller) or the other<br>
> (callee), the message will transition both transactions and thus relate<br>
> to the same dialog. AFAICS, that's no different to a non-spiraled call.<br>
><br>
><br>
> Let me give you a scenario that may help this picture. Once again, IMS<br>
> related ;)<br>
><br>
> In IMS we have different proxies (called CSCFs - Call Session Control<br>
> Functions). These can behave in 'terminating' or 'originating' mode. So<br>
> for an example call between users on the same IMS network, it would look<br>
> something like this:<br>
><br>
> UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=><br>
> PCSCF(Term) <=e=> UA1<br>
><br>
> So for an invite from UA1 to UA2 the INVITE will appear twice at the<br>
> same PCSCF (assuming there is only one PCSCF in this case). This will<br>
> result in spiraling on Kamailio right now, BUT there is no way to<br>
> distinguish between the 'originating' dialog and the 'terminating'<br>
> dialog. why is this a problem? well it would be nice to know in the<br>
> config file in which mode you are in. I am sure there will be non ims<br>
> related scenarios but I can think of any ;)<br>
<br>
</div></div>Gotcha.<br>
<br>
The only thing that tells dialogs on the two machines apart is varying<br>
transactions. So one approach to achieve what you seek is to include a<br>
transaction identifier in the dialog hash's computation. You already<br>
mentioned Via headers which seem like a viable option to me. In fact,<br>
using the top Via branch identifier should suffice. In addition, this<br>
shouldn't affect existing logic: Whether the top Via branch is included<br>
in the hash or not makes no difference regarding both use cases with<br>
spiral detection enabled and spiral-less ones.<br>
<div class="im"><br>
<br>
> If what you're interested in is simply the direction the request came<br>
> from you may evaluate the "dir" variable programmatically which is<br>
> passed as part of each dialog callback parameter structure.<br>
><br>
><br>
> Because this wont be available in the config file AND the wrong dlg will<br>
> be matched already at this point<br>
<br>
</div>Providing the direction information to the configuration script<br>
shouldn't be too hard.<br>
<br>
<br>
So after the proposed modifications, you could reference distinguishable<br>
dialogs per spiraled location and use the then-provided direction<br>
information in the script.<br>
<br>
Does that sound sound? :)<br>
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
--Timo<br>
</font></blockquote></div><br>