25 Aug
2011
25 Aug
'11
7:17 a.m.
Hey Timo,
On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
On 25.08.2011 12:07, Jason Penton wrote:
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.
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.
--Timo
which
can
On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion
<klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@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 > >
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 > 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