Hey Timo,<br><br><div class="gmail_quote">On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann <span dir="ltr"><<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On <a href="tel:25.08.2011%2012" value="+12508201112">25.08.2011 12</a>:07, Jason Penton wrote:<br>
> Thanks guys, good points indeed - let me play around and see what I can<br>
> come up with.<br>
><br>
> The question is: if we find a clean solution would you be ok with adding<br>
> it into the repo? I suppose initially we could even implement with<br>
> compile time flag like "SPIRAL_UNIQUE_DLG" for example. Although, I<br>
> don't particularly like doing this sort of thing.<br>
><br>
> I think the question is: would everyone accept having to call<br>
> get_dlg(callid, ftag, ttag, branch) when according to RFC3261 a dialog<br>
> should be identifiable by only the 3 (cid, ftag, ttag).<br>
><br>
> IMO, this would be a good feature to add to Kamailio, so hopefully it<br>
> can be approved?<br>
<br>
</div>The fact that we require a different dialog ID than the one given in RFC<br>
3261 certainly indicates that we might not have the best approach at<br>
hand (and that's what my guts tell me as well).<br>
<br>
Thinking about your example scenario again, Jason: Wouldn't it be enough<br>
for you to use a single dialog only (by means of spiral detection) and<br>
check the direction flow to tell if you're in 'originating' or<br>
'terminating' more? As mentioned before, this should be rather easy to<br>
add to the existing code.<br></blockquote><div><br>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.<br>
<br>Let me play around with the different options and revert back to you all. <br><br>Thanks alot for the discussion anyhow - I think we have a number of options at our disposal. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
--Timo<br>
<div class="im"><br>
<br>
<br>
> On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion<br>
</div>> <<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a> <mailto:<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>>> wrote:<br>
><br>
><br>
><br>
> Am <a href="tel:25.08.2011%2011" value="+12508201111">25.08.2011 11</a> <tel:25.08.2011%2011>:16, schrieb Timo Reimann:<br>
> > On <a href="tel:25.08.2011%2010" value="+12508201110">25.08.2011 10</a> <tel:25.08.2011%2010>:31, Klaus Darilion wrote:<br>
> >> > Am <a href="tel:25.08.2011%2010" value="+12508201110">25.08.2011 10</a> <tel:25.08.2011%2010>:14, schrieb Jason Penton:<br>
<div><div></div><div class="h5">> >>> >><br>
> >>> >> From some initial work and testing I can confirm that this<br>
> works ONLY<br>
> >>> >> when using the top Via *without* branch tags. Not sure what<br>
> impact this<br>
> >>> >> could have?<br>
> >>> >> This is because a BYE results in a different set of branch<br>
> tags from the<br>
> >>> >> original set of invite branches - I am investigating why and<br>
> how this<br>
> >>> >> works now.<br>
> >> ><br>
> >> > Sure. the branch tag is a transaction identifier and must be<br>
> unique in<br>
> >> > space and time. Thus, BYE must have another tag. That's why I<br>
> said you<br>
> >> > have to put some data into RR cookies - this is the only data which<br>
> >> > stays the same during the dialog (except tags and call-id).<br>
> >> ><br>
> >> > If you only want to know if an in-dialog request is from<br>
> orig->term or<br>
> >> > from term->orig, then the is_direction function is already<br>
> sufficient.<br>
> >> ><br>
> >> > If you want to detect a certain spiral leg in dialog module,<br>
> IMO you<br>
> >> > have to add another matching parameter (besides tags and<br>
> call-id) to<br>
> >> > dialog module which will be set as RR-cookie and retrieved from<br>
> Route<br>
> >> > header for in-dialog requests. Every time the initial requests<br>
> spirals<br>
> >> > through the proxy, you have to add such a cookie which of<br>
> course must be<br>
> >> > different to the previous inserted cookie (therefore ftag is not<br>
> >> > sufficient anymore) - either generate a random identifier or<br>
> reuse some<br>
> >> > data from the message (e.g. you could copy branch-tag to RR<br>
> header as it<br>
> >> > should be unique)<br>
> > Let me emphasize that you don't need to add a new RR cookie: You can<br>
> > re-use the existing one that implements DID mode and simply extend the<br>
> > hash function to cover that extra value you choose. (Random number or<br>
> > branch parameter, as Klaus mentioned; see my comments below though.)<br>
><br>
> Indeed - I have not thought about this parameter. If it would be<br>
> extended to be unique it should work - as long as the DID value in<br>
> in-dialog requests is correct. Thus, DID_FALLBACK mode would not work<br>
> anymore.<br>
><br>
> regards<br>
> Klaus<br>
</div></div></blockquote></div><br>