[sr-dev] ideas on dialog spiral distinction

[Jason Penton]

yeah! 100%.

Thanks Timo. Will work on this right away.

Cheers
Jason

On Wed, Aug 24, 2011 at 4:55 PM, Timo Reimann <timo.reimann at 1und1.de> wrote:

> On 24.08.2011 15:19, Jason Penton wrote:
> > On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <timo.reimann at 1und1.de
> > <mailto:timo.reimann at 1und1.de>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110824/df63b27e/attachment.htm>