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 < [email protected]> 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 > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
