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?
Cheers
Jason
On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
Am 25.08.2011 11:16, schrieb Timo Reimann:
On 25.08.2011 10:31, Klaus Darilion wrote:
> > Am 25.08.2011 10: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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev