Thanks guys, good points indeed - let me play around and see what I can come up with.<br><br>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.<br>
<br>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).<br><br>IMO, this would be a good feature to add to Kamailio, so hopefully it can be approved?<br>
<br>Cheers<br>Jason<br><br><div class="gmail_quote">On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Am <a href="tel:25.08.2011%2011" value="+12508201111">25.08.2011 11</a>:16, schrieb Timo Reimann:<br>
<div><div></div><div class="h5">> On <a href="tel:25.08.2011%2010" value="+12508201110">25.08.2011 10</a>:31, Klaus Darilion wrote:<br>
>> > Am <a href="tel:25.08.2011%2010" value="+12508201110">25.08.2011 10</a>:14, schrieb Jason Penton:<br>
>>> >><br>
>>> >> From some initial work and testing I can confirm that this works ONLY<br>
>>> >> when using the top Via *without* branch tags. Not sure what impact this<br>
>>> >> could have?<br>
>>> >> This is because a BYE results in a different set of branch tags from the<br>
>>> >> original set of invite branches - I am investigating why and how this<br>
>>> >> works now.<br>
>> ><br>
>> > Sure. the branch tag is a transaction identifier and must be unique in<br>
>> > space and time. Thus, BYE must have another tag. That's why I 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 orig->term or<br>
>> > from term->orig, then the is_direction function is already sufficient.<br>
>> ><br>
>> > If you want to detect a certain spiral leg in dialog module, IMO you<br>
>> > have to add another matching parameter (besides tags and call-id) to<br>
>> > dialog module which will be set as RR-cookie and retrieved from Route<br>
>> > header for in-dialog requests. Every time the initial requests spirals<br>
>> > through the proxy, you have to add such a cookie which of course must be<br>
>> > different to the previous inserted cookie (therefore ftag is not<br>
>> > sufficient anymore) - either generate a random identifier or reuse some<br>
>> > data from the message (e.g. you could copy branch-tag to RR 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>
</div></div>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>
<div><div></div><div class="h5"><br>
regards<br>
Klaus<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br>