[sr-dev] ideas on dialog spiral distinction

[Timo Reimann]

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