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
