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