[sr-dev] ideas on dialog spiral distinction

[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.)

Looking over parts of the dialog module code, however, I come to think
this feature isn't as easily implementable as it looked in the first
place: For instance, the script function get_dlg(callid, ftag, ttag)
relies on the assumption that you can lookup any dialog using the given
three parameters which wouldn't be the case anymore after applying the
suggested changes. One way to solve this is to use the brand parameter
(as opposed to a random value) and adapt the signature to dlg_get() such
that it requires the branch parameter to be provided as well.

Furthermore, you'd need to modify parts of dlg_handlers.c and dlg_hash.c
to accommodate for the fact that a dialog is now defined by an
additional field. Overall, this makes the approach look non-trivial to
me but I cannot see a different one at the moment.


Cheers,

--Timo