No subject
Fri Jun 3 15:33:31 CEST 2011
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 at gmail.com>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 at 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 at 1und1.de
>> > <mailto:timo.reimann at 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
>>
>
>
--0016e64cca08fd45c504ab5003f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Timo,<br><br>From some initial work and testing I can confirm that this =
works ONLY when using the top Via *without* branch tags. Not sure what impa=
ct this could have?<br>This is because a BYE results in a different set of =
branch tags from the original set of invite branches - I am investigating w=
hy and how this works now.<br>
<br>Cheers<br>Jason<br><br><div class=3D"gmail_quote">On Wed, Aug 24, 2011 =
at 5:25 PM, Jason Penton <span dir=3D"ltr"><<a href=3D"mailto:jason.pent=
on at gmail.com">jason.penton at gmail.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;">
yeah! 100%.<br><br>Thanks Timo. Will work on this right away.<br><br>Cheers=
<br><font color=3D"#888888">Jason</font><div><div></div><div class=3D"h5"><=
br><br><div class=3D"gmail_quote">On Wed, Aug 24, 2011 at 4:55 PM, Timo Rei=
mann <span dir=3D"ltr"><<a href=3D"mailto:timo.reimann at 1und1.de" target=
=3D"_blank">timo.reimann at 1und1.de</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On <a href=3D"tel:24.08.2011%2015" valu=
e=3D"+12408201115" target=3D"_blank">24.08.2011 15</a>:19, Jason Penton wro=
te:<br>
> On Wed, Aug 24, 2011 at 2:45 PM, Timo Reimann <<a href=3D"mailto:ti=
mo.reimann at 1und1.de" target=3D"_blank">timo.reimann at 1und1.de</a><br>
</div><div><div></div><div>> <mailto:<a href=3D"mailto:timo.reimann at 1=
und1.de" target=3D"_blank">timo.reimann at 1und1.de</a>>> wrote:<br>
><br>
> =A0 =A0 >> My initial thought is to have some sort of direction =
identifiers<br>
> =A0 =A0 >> stored in the dialog structure itself. Then using Via=
and contact<br>
> =A0 =A0 >> headers we can make a pretty good assumption as to wh=
ich 'end' of the<br>
> =A0 =A0 >> spiral and therefore choose the correct dialog in the=
match<br>
> =A0 =A0 algorithm.<br>
><br>
> =A0 =A0 I am not quite sure if I understand how the "ends" o=
f a spiral and the<br>
> =A0 =A0 available dialog structures in the hash table relate to each o=
ther. From<br>
> =A0 =A0 a technical perspective, the result of an (undetected) spirale=
d call is<br>
> =A0 =A0 just a second transaction on the same proxy mapping to the sam=
e call. No<br>
> =A0 =A0 matter whether a request arrives from one end (caller) or the =
other<br>
> =A0 =A0 (callee), the message will transition both transactions and th=
us relate<br>
> =A0 =A0 to the same dialog. AFAICS, that's no different to a non-s=
piraled call.<br>
><br>
><br>
> Let me give you a scenario that may help this picture. Once again, IMS=
<br>
> related ;)<br>
><br>
> In IMS we have different proxies (called CSCFs - Call Session Control<=
br>
> Functions). These can behave in 'terminating' or 'originat=
ing' mode. So<br>
> for an example call between users on the same IMS network, it would lo=
ok<br>
> something like this:<br>
><br>
> UA1 =A0<=3Da=3D> PCSCF(Orig) =A0<=3Db=3D> SCSCF(Orig) <=
=3Dc=3D> SCSCF(Term) <=3Dd=3D><br>
> PCSCF(Term) <=3De=3D> UA1<br>
><br>
> So for an invite from UA1 to UA2 the INVITE will appear twice at the<b=
r>
> same PCSCF (assuming there is only one PCSCF in this case). This will<=
br>
> result in spiraling on Kamailio right now, BUT there is no way to<br>
> distinguish between the 'originating' dialog and the 'term=
inating'<br>
> dialog. why is this a problem? well it would be nice to know in the<br=
>
> config file in which mode you are in. I am sure there will be non ims<=
br>
> related scenarios but I can think of any ;)<br>
<br>
</div></div>Gotcha.<br>
<br>
The only thing that tells dialogs on the two machines apart is varying<br>
transactions. So one approach to achieve what you seek is to include a<br>
transaction identifier in the dialog hash's computation. You already<br=
>
mentioned Via headers which seem like a viable option to me. In fact,<br>
using the top Via branch identifier should suffice. In addition, this<br>
shouldn't affect existing logic: Whether the top Via branch is included=
<br>
in the hash or not makes no difference regarding both use cases with<br>
spiral detection enabled and spiral-less ones.<br>
<div><br>
<br>
> =A0 =A0 If what you're interested in is simply the direction the r=
equest came<br>
> =A0 =A0 from you may evaluate the "dir" variable programmati=
cally which is<br>
> =A0 =A0 passed as part of each dialog callback parameter structure.<br=
>
><br>
><br>
> Because this wont be available in the config file AND the wrong dlg wi=
ll<br>
> be matched already at this point<br>
<br>
</div>Providing the direction information to the configuration script<br>
shouldn't be too hard.<br>
<br>
<br>
So after the proposed modifications, you could reference distinguishable<br=
>
dialogs per spiraled location and use the then-provided direction<br>
information in the script.<br>
<br>
Does that sound sound? :)<br>
<br>
<br>
Cheers,<br>
<font color=3D"#888888"><br>
--Timo<br>
</font></blockquote></div><br>
</div></div></blockquote></div><br>
--0016e64cca08fd45c504ab5003f2--
More information about the sr-dev
mailing list