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