Hi Guys,
Have been playing around with the dialog module and spiralling and one thing I have noticed is that if you spiral and dont have detect_spirals enabled the dialog module will create 2 dialogs. This is great and 'expected' in this case. However, as it stands there is no way of distinguishing between the 2 dialogs. So for example, a BYE could come in from either 'side' of the spiral and the first dialog is matched - not necessarily the correct one. this is because the match is purely done on callid, from and to tags (if using RFC3261 matching).
My initial thought is to have some sort of direction identifiers stored in the dialog structure itself. Then using Via and contact headers we can make a pretty good assumption as to which 'end' of the spiral and therefore choose the correct dialog in the match algorithm.
some may say just enable spiral_detection. Actually, in some cases it is nice to be able to track a spiral in different dialogs, which most likely why the option to enable or disable spiral detection in the first place
What are your thoughts?
On 08/24/2011 02:32 PM, Jason Penton wrote:
Hi Guys,
Have been playing around with the dialog module and spiralling and one thing I have noticed is that if you spiral and dont have detect_spirals enabled the dialog module will create 2 dialogs. This is great and 'expected' in this case. However, as it stands there is no way of distinguishing between the 2 dialogs. So for example, a BYE could come in from either 'side' of the spiral and the first dialog is matched - not necessarily the correct one. this is because the match is purely done on callid, from and to tags (if using RFC3261 matching).
My initial thought is to have some sort of direction identifiers stored in the dialog structure itself. Then using Via and contact headers we can make a pretty good assumption as to which 'end' of the spiral and therefore choose the correct dialog in the match algorithm.
some may say just enable spiral_detection. Actually, in some cases it is nice to be able to track a spiral in different dialogs, which most likely why the option to enable or disable spiral detection in the first place
What are your thoughts?
There have been many talks regarding an improved dialog module . Check this link for references:
http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d... http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-design?s[]=dialog
This is still to be implemented AFAIK, but i hope it will show you some of the topics that were of great interest.
Marius
Hey,
On 24.08.2011 13:38, marius zbihlei wrote:
On 08/24/2011 02:32 PM, Jason Penton wrote:
Hi Guys,
Have been playing around with the dialog module and spiralling and one thing I have noticed is that if you spiral and dont have detect_spirals enabled the dialog module will create 2 dialogs. This is great and 'expected' in this case. However, as it stands there is no way of distinguishing between the 2 dialogs. So for example, a BYE could come in from either 'side' of the spiral and the first dialog is matched - not necessarily the correct one. this is because the match is purely done on callid, from and to tags (if using RFC3261 matching).
And for the record: It doesn't help if you switch to cookie-based matching (dlg_match_mode 0 or 1). Since cookies are implemented as hashed Call-IDs, two different dialogs spawn from a spiral situation still map to the same entry in the hash table.
My initial thought is to have some sort of direction identifiers stored in the dialog structure itself. Then using Via and contact headers we can make a pretty good assumption as to which 'end' of the spiral and therefore choose the correct dialog in the match algorithm.
I am not quite sure if I understand how the "ends" of a spiral and the available dialog structures in the hash table relate to each other. From a technical perspective, the result of an (undetected) spiraled call is just a second transaction on the same proxy mapping to the same call. No matter whether a request arrives from one end (caller) or the other (callee), the message will transition both transactions and thus relate to the same dialog. AFAICS, that's no different to a non-spiraled call.
If what you're interested in is simply the direction the request came from you may evaluate the "dir" variable programmatically which is passed as part of each dialog callback parameter structure.
some may say just enable spiral_detection. Actually, in some cases it is nice to be able to track a spiral in different dialogs, which most likely why the option to enable or disable spiral detection in the first place
In order to get a better feel for what you wish to accomplish, could you give an example of such a case?
Cheers,
--Timo
Hey Timo,
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann timo.reimann@1und1.de wrote:
Hey,
On 24.08.2011 13:38, marius zbihlei wrote:
On 08/24/2011 02:32 PM, Jason Penton wrote:
Hi Guys,
Have been playing around with the dialog module and spiralling and one thing I have noticed is that if you spiral and dont have detect_spirals enabled the dialog module will create 2 dialogs. This is great and 'expected' in this case. However, as it stands there is no way of distinguishing between the 2 dialogs. So for example, a BYE could come in from either 'side' of the spiral and the first dialog is matched - not necessarily the correct one. this is because the match is purely done on callid, from and to tags (if using RFC3261 matching).
And for the record: It doesn't help if you switch to cookie-based matching (dlg_match_mode 0 or 1). Since cookies are implemented as hashed Call-IDs, two different dialogs spawn from a spiral situation still map to the same entry in the hash table.
yes, sure
My initial thought is to have some sort of direction identifiers stored in the dialog structure itself. Then using Via and contact headers we can make a pretty good assumption as to which 'end' of the spiral and therefore choose the correct dialog in the match algorithm.
I am not quite sure if I understand how the "ends" of a spiral and the available dialog structures in the hash table relate to each other. From a technical perspective, the result of an (undetected) spiraled call is just a second transaction on the same proxy mapping to the same call. No matter whether a request arrives from one end (caller) or the other (callee), the message will transition both transactions and thus relate to the same dialog. AFAICS, that's no different to a non-spiraled call.
Let me give you a scenario that may help this picture. Once again, IMS related ;)
In IMS we have different proxies (called CSCFs - Call Session Control Functions). These can behave in 'terminating' or 'originating' mode. So for an example call between users on the same IMS network, it would look something like this:
UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=> PCSCF(Term) <=e=> UA1
So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)
If what you're interested in is simply the direction the request came from you may evaluate the "dir" variable programmatically which is passed as part of each dialog callback parameter structure.
Because this wont be available in the config file AND the wrong dlg will be matched already at this point
some may say just enable spiral_detection. Actually, in some cases it is nice to be able to track a spiral in different dialogs, which most likely why the option to enable or disable spiral detection in the first place
In order to get a better feel for what you wish to accomplish, could you give an example of such a case?
Cheers,
--Timo
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Am 24.08.2011 15:19, schrieb Jason Penton:
So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)
For transactions you can find out the direction by using fromtag cookie (ftag) in RR header and the is_direction() function.
I guess if you want such a feature to extend the dialog capabilities, it can be done in a similar way (record-route cookies)
regards Klaus
Thanks Klaus,
Will look into that!
On Wed, Aug 24, 2011 at 4:07 PM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Am 24.08.2011 15:19, schrieb Jason Penton:
So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)
For transactions you can find out the direction by using fromtag cookie (ftag) in RR header and the is_direction() function.
I guess if you want such a feature to extend the dialog capabilities, it can be done in a similar way (record-route cookies)
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 24.08.2011 15:19, Jason Penton wrote:
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <timo.reimann@1und1.de mailto:timo.reimann@1und1.de> wrote:
>> My initial thought is to have some sort of direction identifiers >> stored in the dialog structure itself. Then using Via and contact >> headers we can make a pretty good assumption as to which 'end' of the >> spiral and therefore choose the correct dialog in the match algorithm. I am not quite sure if I understand how the "ends" of a spiral and the available dialog structures in the hash table relate to each other. From a technical perspective, the result of an (undetected) spiraled call is just a second transaction on the same proxy mapping to the same call. No matter whether a request arrives from one end (caller) or the other (callee), the message will transition both transactions and thus relate to the same dialog. AFAICS, that's no different to a non-spiraled call.Let me give you a scenario that may help this picture. Once again, IMS related ;)
In IMS we have different proxies (called CSCFs - Call Session Control Functions). These can behave in 'terminating' or 'originating' mode. So for an example call between users on the same IMS network, it would look something like this:
UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=> PCSCF(Term) <=e=> UA1
So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)
Gotcha.
The only thing that tells dialogs on the two machines apart is varying transactions. So one approach to achieve what you seek is to include a transaction identifier in the dialog hash's computation. You already mentioned Via headers which seem like a viable option to me. In fact, using the top Via branch identifier should suffice. In addition, this shouldn't affect existing logic: Whether the top Via branch is included in the hash or not makes no difference regarding both use cases with spiral detection enabled and spiral-less ones.
If what you're interested in is simply the direction the request came from you may evaluate the "dir" variable programmatically which is passed as part of each dialog callback parameter structure.Because this wont be available in the config file AND the wrong dlg will be matched already at this point
Providing the direction information to the configuration script shouldn't be too hard.
So after the proposed modifications, you could reference distinguishable dialogs per spiraled location and use the then-provided direction information in the script.
Does that sound sound? :)
Cheers,
--Timo
yeah! 100%.
Thanks Timo. Will work on this right away.
Cheers Jason
On Wed, Aug 24, 2011 at 4:55 PM, Timo Reimann timo.reimann@1und1.de wrote:
On 24.08.2011 15:19, Jason Penton wrote:
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <timo.reimann@1und1.de mailto:timo.reimann@1und1.de> wrote:
>> My initial thought is to have some sort of direction identifiers >> stored in the dialog structure itself. Then using Via and contact >> headers we can make a pretty good assumption as to which 'end' ofthe
>> spiral and therefore choose the correct dialog in the match algorithm. I am not quite sure if I understand how the "ends" of a spiral andthe
available dialog structures in the hash table relate to each other.From
a technical perspective, the result of an (undetected) spiraled callis
just a second transaction on the same proxy mapping to the same call.No
matter whether a request arrives from one end (caller) or the other (callee), the message will transition both transactions and thusrelate
to the same dialog. AFAICS, that's no different to a non-spiraledcall.
Let me give you a scenario that may help this picture. Once again, IMS related ;)
In IMS we have different proxies (called CSCFs - Call Session Control Functions). These can behave in 'terminating' or 'originating' mode. So for an example call between users on the same IMS network, it would look something like this:
UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=> PCSCF(Term) <=e=> UA1
So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)
Gotcha.
The only thing that tells dialogs on the two machines apart is varying transactions. So one approach to achieve what you seek is to include a transaction identifier in the dialog hash's computation. You already mentioned Via headers which seem like a viable option to me. In fact, using the top Via branch identifier should suffice. In addition, this shouldn't affect existing logic: Whether the top Via branch is included in the hash or not makes no difference regarding both use cases with spiral detection enabled and spiral-less ones.
If what you're interested in is simply the direction the request came from you may evaluate the "dir" variable programmatically which is passed as part of each dialog callback parameter structure.Because this wont be available in the config file AND the wrong dlg will be matched already at this point
Providing the direction information to the configuration script shouldn't be too hard.
So after the proposed modifications, you could reference distinguishable dialogs per spiraled location and use the then-provided direction information in the script.
Does that sound sound? :)
Cheers,
--Timo
Hi Timo,
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.
Cheers Jason
On Wed, Aug 24, 2011 at 5:25 PM, Jason Penton jason.penton@gmail.comwrote:
yeah! 100%.
Thanks Timo. Will work on this right away.
Cheers Jason
On Wed, Aug 24, 2011 at 4:55 PM, Timo Reimann timo.reimann@1und1.dewrote:
On 24.08.2011 15:19, Jason Penton wrote:
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <timo.reimann@1und1.de mailto:timo.reimann@1und1.de> wrote:
>> My initial thought is to have some sort of direction identifiers >> stored in the dialog structure itself. Then using Via and contact >> headers we can make a pretty good assumption as to which 'end' ofthe
>> spiral and therefore choose the correct dialog in the match algorithm. I am not quite sure if I understand how the "ends" of a spiral andthe
available dialog structures in the hash table relate to each other.From
a technical perspective, the result of an (undetected) spiraled callis
just a second transaction on the same proxy mapping to the samecall. No
matter whether a request arrives from one end (caller) or the other (callee), the message will transition both transactions and thusrelate
to the same dialog. AFAICS, that's no different to a non-spiraledcall.
Let me give you a scenario that may help this picture. Once again, IMS related ;)
In IMS we have different proxies (called CSCFs - Call Session Control Functions). These can behave in 'terminating' or 'originating' mode. So for an example call between users on the same IMS network, it would look something like this:
UA1 <=a=> PCSCF(Orig) <=b=> SCSCF(Orig) <=c=> SCSCF(Term) <=d=> PCSCF(Term) <=e=> UA1
So for an invite from UA1 to UA2 the INVITE will appear twice at the same PCSCF (assuming there is only one PCSCF in this case). This will result in spiraling on Kamailio right now, BUT there is no way to distinguish between the 'originating' dialog and the 'terminating' dialog. why is this a problem? well it would be nice to know in the config file in which mode you are in. I am sure there will be non ims related scenarios but I can think of any ;)
Gotcha.
The only thing that tells dialogs on the two machines apart is varying transactions. So one approach to achieve what you seek is to include a transaction identifier in the dialog hash's computation. You already mentioned Via headers which seem like a viable option to me. In fact, using the top Via branch identifier should suffice. In addition, this shouldn't affect existing logic: Whether the top Via branch is included in the hash or not makes no difference regarding both use cases with spiral detection enabled and spiral-less ones.
If what you're interested in is simply the direction the requestcame
from you may evaluate the "dir" variable programmatically which is passed as part of each dialog callback parameter structure.Because this wont be available in the config file AND the wrong dlg will be matched already at this point
Providing the direction information to the configuration script shouldn't be too hard.
So after the proposed modifications, you could reference distinguishable dialogs per spiraled location and use the then-provided direction information in the script.
Does that sound sound? :)
Cheers,
--Timo
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)
regards Klaus
OK Klaus,
that makes sense to me now!! Thank you. Let me try that.
Cheers Jason
On Thu, Aug 25, 2011 at 10:31 AM, Klaus Darilion < klaus.mailinglists@pernau.at> 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)
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
Am 25.08.2011 11:16, schrieb 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.)
Indeed - I have not thought about this parameter. If it would be extended to be unique it should work - as long as the DID value in in-dialog requests is correct. Thus, DID_FALLBACK mode would not work anymore.
regards Klaus
Thanks guys, good points indeed - let me play around and see what I can come up with.
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.
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).
IMO, this would be a good feature to add to Kamailio, so hopefully it can be approved?
Cheers Jason
On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Am 25.08.2011 11:16, schrieb 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.)
Indeed - I have not thought about this parameter. If it would be extended to be unique it should work - as long as the DID value in in-dialog requests is correct. Thus, DID_FALLBACK mode would not work anymore.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 25.08.2011 12:07, Jason Penton wrote:
Thanks guys, good points indeed - let me play around and see what I can come up with.
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.
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).
IMO, this would be a good feature to add to Kamailio, so hopefully it can be approved?
The fact that we require a different dialog ID than the one given in RFC 3261 certainly indicates that we might not have the best approach at hand (and that's what my guts tell me as well).
Thinking about your example scenario again, Jason: Wouldn't it be enough for you to use a single dialog only (by means of spiral detection) and check the direction flow to tell if you're in 'originating' or 'terminating' more? As mentioned before, this should be rather easy to add to the existing code.
--Timo
On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Am 25.08.2011 11 <tel:25.08.2011%2011>:16, schrieb Timo Reimann: > On 25.08.2011 10 <tel:25.08.2011%2010>:31, Klaus Darilion wrote: >> > Am 25.08.2011 10 <tel:25.08.2011%2010>: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.) Indeed - I have not thought about this parameter. If it would be extended to be unique it should work - as long as the DID value in in-dialog requests is correct. Thus, DID_FALLBACK mode would not work anymore. regards Klaus
Hey Timo,
On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann timo.reimann@1und1.de wrote:
On 25.08.2011 12:07, Jason Penton wrote:
Thanks guys, good points indeed - let me play around and see what I can come up with.
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.
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).
IMO, this would be a good feature to add to Kamailio, so hopefully it can be approved?
The fact that we require a different dialog ID than the one given in RFC 3261 certainly indicates that we might not have the best approach at hand (and that's what my guts tell me as well).
Thinking about your example scenario again, Jason: Wouldn't it be enough for you to use a single dialog only (by means of spiral detection) and check the direction flow to tell if you're in 'originating' or 'terminating' more? As mentioned before, this should be rather easy to add to the existing code.
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.
Let me play around with the different options and revert back to you all.
Thanks alot for the discussion anyhow - I think we have a number of options at our disposal.
--Timo
On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at>
wrote:
Am 25.08.2011 11 <tel:25.08.2011%2011>:16, schrieb Timo Reimann: > On 25.08.2011 10 <tel:25.08.2011%2010>:31, Klaus Darilion wrote: >> > Am 25.08.2011 10 <tel:25.08.2011%2010>:14, schrieb JasonPenton:
>>> >> >>> >> 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 datawhich
>> > 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: Youcan
> re-use the existing one that implements DID mode and simply extendthe
> hash function to cover that extra value you choose. (Random numberor
> branch parameter, as Klaus mentioned; see my comments belowthough.)
Indeed - I have not thought about this parameter. If it would be extended to be unique it should work - as long as the DID value in in-dialog requests is correct. Thus, DID_FALLBACK mode would not work anymore. regards Klaus
On Thursday 25 August 2011, Klaus Darilion wrote:
If you want to detect a certain spiral leg in dialog module,
The routeset is already stored in the dialog, can't you compare that to the routeset in a received request to determine the correct dialog (assuming direction is already known)? Maybe only the position in the routeset is already sufficient.
On 25.08.2011 12:51, Alex Hermann wrote:
On Thursday 25 August 2011, Klaus Darilion wrote:
If you want to detect a certain spiral leg in dialog module,
The routeset is already stored in the dialog, can't you compare that to the routeset in a received request to determine the correct dialog (assuming direction is already known)? Maybe only the position in the routeset is already sufficient.
When we worked on the new dialog design, Iñaki outlined several reasons why relying on the route set for the purpose of dialog matching is tricky. See here
http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d...
for details.
--Timo
-
Alex Hermann -
Jason Penton -
Jason Penton -
Klaus Darilion -
marius zbihlei -
Timo Reimann