25 Aug
2011
25 Aug
'11
4: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