Hey Timo, On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann <[email protected]> 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 > > <[email protected] <mailto:[email protected]>> > 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 >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
