Hey Timo,
On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann timo.reimann@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@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 JasonPenton:
>>> >> >>> >> 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 datawhich
>> > 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: Youcan
> re-use the existing one that implements DID mode and simply extendthe
> hash function to cover that extra value you choose. (Random numberor
> branch parameter, as Klaus mentioned; see my comments belowthough.)
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