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