24 Aug
2011
24 Aug
'11
1:32 p.m.
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?
24 Aug
24 Aug
1:38 p.m.
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-…
<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
--
Zbihlei Marius
Head of
Linux Development Services Romania
1&1 Internet Development srl Tel KA: 754-9512
Str Mircea Eliade 18 Tel RO: +40-31-223-9512
Sect 1, Bucuresti mailto: marius.zbihlei(a)1and1.ro
71295, Romania
2:45 p.m.
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
3:19 p.m.
Hey Timo,
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
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 ;)
Hey,
On 24.08.2011 13:38, marius zbihlei wrote:
yes, sure
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.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4:07 p.m.
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
4:35 p.m.
Thanks Klaus,
Will look into that!
On Wed, Aug 24, 2011 at 4:07 PM, Klaus Darilion <
klaus.mailinglists(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4:55 p.m.
On 24.08.2011 15:19, Jason Penton wrote:
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann
<timo.reimann(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
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.
> 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
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
5:25 p.m.
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(a)1und1.de> wrote:
On 24.08.2011 15:19, Jason Penton wrote:
the
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann
<timo.reimann(a)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 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
25 Aug
25 Aug
10:14 a.m.
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(a)gmail.com>wrote;wrote:
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(a)1und1.de>wrote;wrote:
On 24.08.2011 15:19, Jason Penton wrote:
the
On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann
<timo.reimann(a)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 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
10:31 a.m.
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
10:38 a.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
11:16 a.m.
On 25.08.2011 10:31, Klaus Darilion wrote:
Am 25.08.2011 10:14, schrieb Jason Penton:
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
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)
11:29 a.m.
Am 25.08.2011 11:16, schrieb Timo Reimann:
On 25.08.2011 10:31, Klaus Darilion wrote:
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
> 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.)
12:07 p.m.
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(a)pernau.at> wrote:
Am 25.08.2011 11:16, schrieb Timo Reimann:
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(a)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.)
1:10 p.m.
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(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> wrote:
Am 25.08.2011 11 <tel:25.08.2011%2011>:16, schrieb Timo Reimann:
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 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.)
1:17 p.m.
Hey Timo,
On Thu, Aug 25, 2011 at 1:10 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
On 25.08.2011 12:07, Jason Penton wrote:
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.
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
which
can
On Thu, Aug 25, 2011 at 11:29 AM, Klaus Darilion
<klaus.mailinglists(a)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 > >
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 > 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
12:51 p.m.
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.
--
Greetings,
Alex Hermann
1:01 p.m.
On 25.08.2011 12:51, Alex Hermann wrote:
On Thursday 25 August 2011, Klaus Darilion wrote:
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-…
for details.
--Timo
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.
4634
days inactive
4635
days old
17 comments
6 participants
participants (6)
-
Alex Hermann -
Jason Penton -
Jason Penton -
Klaus Darilion -
marius zbihlei -
Timo Reimann