[sr-dev] ideas on dialog spiral distinction

Jason Penton jason.penton at gmail.com
Wed Aug 24 15:19:04 CEST 2011


Hey Timo,

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

> Hey,
>
>
> On 24.08.2011 13:38, marius zbihlei wrote:
> > On 08/24/2011 02:32 PM, Jason Penton wrote:
> >> Hi Guys,
> >>
> >> Have been playing around with the dialog module and spiralling and one
> >> thing I have noticed is that if you spiral and dont have
> >> detect_spirals enabled the dialog module will create 2 dialogs. This
> >> is great and 'expected' in this case. However, as it stands there is
> >> no way of distinguishing between the 2 dialogs. So for example, a BYE
> >> could come in from either 'side' of the spiral and the first dialog is
> >> matched - not necessarily the correct one. this is because the match
> >> is purely done on callid, from and to tags (if using RFC3261 matching).
>
> And for the record: It doesn't help if you switch to cookie-based
> matching (dlg_match_mode 0 or 1). Since cookies are implemented as
> hashed Call-IDs, two different dialogs spawn from a spiral situation
> still map to the same entry in the hash table.
>
>
yes, sure


>
> >> 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 ;)



> 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

>
>
> >> some may say just enable spiral_detection. Actually, in some cases it
> >> is nice to be able to track a spiral in different dialogs, which most
> >> likely why the option to enable or disable spiral detection in the
> >> first place
>
> In order to get a better feel for what you wish to accomplish, could you
> give an example of such a case?
>
>
> Cheers,
>
> --Timo
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110824/58f4eca9/attachment.htm>


More information about the sr-dev mailing list