[sr-dev] ideas on dialog spiral distinction

Jason Penton jason.penton at gmail.com
Thu Aug 25 13:17:48 CEST 2011


Hey Timo,

On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann <timo.reimann at 1und1.de> wrote:

> On 25.08.2011 12:07, Jason Penton wrote:
> > Thanks guys, good points indeed - let me play around and see what I can
> > come up with.
> >
> > The question is: if we find a clean solution would you be ok with adding
> > it into the repo? I suppose initially we could even implement with
> > compile time flag like "SPIRAL_UNIQUE_DLG" for example. Although, I
> > don't particularly like doing this sort of thing.
> >
> > I think the question is: would everyone accept having to call
> > get_dlg(callid, ftag, ttag, branch) when according to RFC3261 a dialog
> > should be identifiable by only the 3 (cid, ftag, ttag).
> >
> > IMO, this would be a good feature to add to Kamailio, so hopefully it
> > can be approved?
>
> The fact that we require a different dialog ID than the one given in RFC
> 3261 certainly indicates that we might not have the best approach at
> hand (and that's what my guts tell me as well).
>
> Thinking about your example scenario again, Jason: Wouldn't it be enough
> for you to use a single dialog only (by means of spiral detection) and
> check the direction flow to tell if you're in 'originating' or
> 'terminating' more? As mentioned before, this should be rather easy to
> add to the existing code.
>

this is an option, yes and one we did consider. However, one thing we liked
about the 2 different dialogs was it being easier to manage state against
the individual 'legs' - for example there is a PCC (policy charging control)
session attached to each leg in the diameter_rx module we have written. But,
we could possibly use the dlg_var/rivet infrastructure to attach this
information with different keys.

Let me play around with the different options and revert back to you all.

Thanks alot for the discussion anyhow - I think we have a number of options
at our disposal.

>
>
> --Timo
>
>
>
> > On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion
> > <klaus.mailinglists at pernau.at <mailto:klaus.mailinglists at pernau.at>>
> wrote:
> >
> >
> >
> >     Am 25.08.2011 11 <tel:25.08.2011%2011>:16, schrieb Timo Reimann:
> >     > On 25.08.2011 10 <tel:25.08.2011%2010>:31, Klaus Darilion wrote:
> >     >> > Am 25.08.2011 10 <tel:25.08.2011%2010>:14, schrieb Jason
> Penton:
> >     >>> >>
> >     >>> >> 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.
> >     >> >
> >     >> > Sure. the branch tag is a transaction identifier and must be
> >     unique in
> >     >> > space and time. Thus, BYE must have another tag. That's why I
> >     said you
> >     >> > have to put some data into RR cookies - this is the only data
> which
> >     >> > stays the same during the dialog (except tags and call-id).
> >     >> >
> >     >> > If you only want to know if an in-dialog request is from
> >     orig->term or
> >     >> > from term->orig, then the is_direction function is already
> >     sufficient.
> >     >> >
> >     >> > If you want to detect a certain spiral leg in dialog module,
> >     IMO you
> >     >> > have to add another matching parameter (besides tags and
> >     call-id) to
> >     >> > dialog module which will be set as RR-cookie and retrieved from
> >     Route
> >     >> > header for in-dialog requests. Every time the initial requests
> >     spirals
> >     >> > through the proxy, you have to add such a cookie which of
> >     course must be
> >     >> > different to the previous inserted cookie (therefore ftag is not
> >     >> > sufficient anymore) - either generate a random identifier or
> >     reuse some
> >     >> > data from the message (e.g. you could copy branch-tag to RR
> >     header as it
> >     >> > should be unique)
> >     > Let me emphasize that you don't need to add a new RR cookie: You
> can
> >     > re-use the existing one that implements DID mode and simply extend
> the
> >     > hash function to cover that extra value you choose. (Random number
> or
> >     > branch parameter, as Klaus mentioned; see my comments below
> though.)
> >
> >     Indeed - I have not thought about this parameter. If it would be
> >     extended to be unique it should work - as long as the DID value in
> >     in-dialog requests is correct. Thus, DID_FALLBACK mode would not work
> >     anymore.
> >
> >     regards
> >     Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110825/45a033e8/attachment.htm>


More information about the sr-dev mailing list