Hi Timo, >From some initial work and testing I can confirm that this works ONLY when using the top Via *without* branch tags. Not sure what impact this could have? This is because a BYE results in a different set of branch tags from the original set of invite branches - I am investigating why and how this works now.
Cheers Jason On Wed, Aug 24, 2011 at 5:25 PM, Jason Penton <[email protected]>wrote: > yeah! 100%. > > Thanks Timo. Will work on this right away. > > Cheers > Jason > > > On Wed, Aug 24, 2011 at 4:55 PM, Timo Reimann <[email protected]>wrote: > >> On 24.08.2011 15:19, Jason Penton wrote: >> > On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > >> My initial thought is to have some sort of direction identifiers >> > >> stored in the dialog structure itself. Then using Via and contact >> > >> headers we can make a pretty good assumption as to which 'end' of >> the >> > >> spiral and therefore choose the correct dialog in the match >> > algorithm. >> > >> > I am not quite sure if I understand how the "ends" of a spiral and >> the >> > available dialog structures in the hash table relate to each other. >> From >> > a technical perspective, the result of an (undetected) spiraled call >> is >> > just a second transaction on the same proxy mapping to the same >> call. No >> > matter whether a request arrives from one end (caller) or the other >> > (callee), the message will transition both transactions and thus >> relate >> > to the same dialog. AFAICS, that's no different to a non-spiraled >> call. >> > >> > >> > Let me give you a scenario that may help this picture. Once again, IMS >> > related ;) >> > >> > In IMS we have different proxies (called CSCFs - Call Session Control >> > Functions). These can behave in 'terminating' or 'originating' mode. So >> > for an example call between users on the same IMS network, it would look >> > something like this: >> > >> > UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=> >> > PCSCF(Term) <=e=> UA1 >> > >> > So for an invite from UA1 to UA2 the INVITE will appear twice at the >> > same PCSCF (assuming there is only one PCSCF in this case). This will >> > result in spiraling on Kamailio right now, BUT there is no way to >> > distinguish between the 'originating' dialog and the 'terminating' >> > dialog. why is this a problem? well it would be nice to know in the >> > config file in which mode you are in. I am sure there will be non ims >> > related scenarios but I can think of any ;) >> >> Gotcha. >> >> The only thing that tells dialogs on the two machines apart is varying >> transactions. So one approach to achieve what you seek is to include a >> transaction identifier in the dialog hash's computation. You already >> mentioned Via headers which seem like a viable option to me. In fact, >> using the top Via branch identifier should suffice. In addition, this >> shouldn't affect existing logic: Whether the top Via branch is included >> in the hash or not makes no difference regarding both use cases with >> spiral detection enabled and spiral-less ones. >> >> >> > If what you're interested in is simply the direction the request >> came >> > from you may evaluate the "dir" variable programmatically which is >> > passed as part of each dialog callback parameter structure. >> > >> > >> > Because this wont be available in the config file AND the wrong dlg will >> > be matched already at this point >> >> Providing the direction information to the configuration script >> shouldn't be too hard. >> >> >> So after the proposed modifications, you could reference distinguishable >> dialogs per spiraled location and use the then-provided direction >> information in the script. >> >> Does that sound sound? :) >> >> >> Cheers, >> >> --Timo >> > >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
