27 May
2009
27 May
'09
5:30 p.m.
Hello,
I was excited to find that I can now use dlg_manage instead of
record_route so that I no longer need the record_route parameter but I
now found a strange situation that maybe somebody can explain.
I am sending an INVITE to kamailio, and kamailio sends it to a
provider. It's like this:
asterisk-----INVITE cseq 1-------> kamailio -----INVITE cseq
1-----------> provider
asterisk<-----407 auth required---- kamailio <-----407 auth
required------- provider
asterisk-----ACK----------------------> kamailio
-----ACK------------------------> provider
When 407 reaches kamailio, kamailio changes dialog state to state 5.
But the dialog is not deleted.
Then the INVITE arrives again, authenticated, and a new dialog is
created, but having the same callid and from-tag:
asterisk-----INVITE cseq 2-------> kamailio -----INVITE cseq
2----------> provider
asterisk<---- 200OK ----------------- kamailio
<-----200OK--------------------- provider
asterisk-----ACK----------------------> kamailio
-----ACK------------------------> provider
When this ACK arrives to kamailio, dlg_manage is called and kamailio
searches for the dialog in the dialog list. It finds one but with
state 5 (I printed a debug in the source), probably finds the first
one, and thus it can no longer identify the ACK as being part of the
second dialog. For this reason, the dialog created during the second
invite remains with state 3.
This causes sometimes the BYE not to be accepted correctly either, and
some dialogs remain stuck in the database until they expire.
Does anybody know why, when a dialog match is searched, when a match
that is in state 5 in found, the search is interrupted? I was thinking
of changing this so that the search can continue and the second INVITE
dialog can be found, but I'm not sure that's safe.
Thanks a lot,
Catalina Oancea
27 May
27 May
5:38 p.m.
Catalina,
Unless I am missing something, dlg_manage() does not allow you to avoid
setting Record-Route; how else will the endpoints know to send
sequential messages through the proxy once the dialog is established?
The purpose of dlg_manage() is to provide an alternative to setting a
flag for the purpose of indicating to Kamailio that the dialog the
current INVITE seeks to establish should be statefully tracked and
exposed to additional user-defined dialog module functionality
(profiles, statistics, etc.) and other module functionality relying on
internal API callbacks from the dialog module.
modparam("dialog", "dlg_flag", 4)
route {
...
# Process initial INVITE.
if(is_method("INVITE")) {
...
setflag(4); # Track this dialog.
}
}
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
28 May
28 May
11:24 a.m.
Hello,
On 05/27/2009 05:38 PM, Alex Balashov wrote:
Catalina,
Unless I am missing something, dlg_manage() does not allow you to avoid
setting Record-Route;
you can use dlg_manage() without record-routing. It can match
based on
call-id/from tag/to tag.
how else will the endpoints know to send
sequential messages through the proxy once the dialog is established?
Could be static routing, depending from case to case. For example, in
some of my deployments I have:
[users] ==== [inbound proxy] ===== [main proxy] ===== [outbound proxy]
===== [users]
inbound and outbound add RR, the rest is static, if not coming from main
proxy, send request there. if coming from inbound, send to outbound and
viceversa.
Cheers,
Daniel
The purpose of dlg_manage() is to provide an
alternative to setting a
flag for the purpose of indicating to Kamailio that the dialog the
current INVITE seeks to establish should be statefully tracked and
exposed to additional user-defined dialog module functionality
(profiles, statistics, etc.) and other module functionality relying on
internal API callbacks from the dialog module.
modparam("dialog", "dlg_flag", 4)
route {
...
# Process initial INVITE.
if(is_method("INVITE")) {
...
setflag(4); # Track this dialog.
}
}
--
Daniel-Constantin Mierla
http://www.asipto.com/
5:03 p.m.
Hello Catalina,
The same issue that you are describing here should show up if you are
looping a a call through the same proxy. In order to circumvent this
issue, you will need to force dialog matching based on did. Did
matching should work fine. This is one of the limitations of the
dialog module.
I'm using dlg_match_mode 2 without any issues, but without
authentications and looping on my proxy.
Regards,
Ovidiu Sas
On Wed, May 27, 2009 at 10:30 AM, catalina oancea
<catalina.oancea(a)gmail.com> wrote:
Hello,
I was excited to find that I can now use dlg_manage instead of
record_route so that I no longer need the record_route parameter but I
now found a strange situation that maybe somebody can explain.
I am sending an INVITE to kamailio, and kamailio sends it to a
provider. It's like this:
asterisk-----INVITE cseq 1-------> kamailio -----INVITE cseq
1-----------> provider
asterisk<-----407 auth required---- kamailio <-----407 auth
required------- provider
asterisk-----ACK----------------------> kamailio
-----ACK------------------------> provider
When 407 reaches kamailio, kamailio changes dialog state to state 5.
But the dialog is not deleted.
Then the INVITE arrives again, authenticated, and a new dialog is
created, but having the same callid and from-tag:
asterisk-----INVITE cseq 2-------> kamailio -----INVITE cseq
2----------> provider
asterisk<---- 200OK ----------------- kamailio
<-----200OK--------------------- provider
asterisk-----ACK----------------------> kamailio
-----ACK------------------------> provider
When this ACK arrives to kamailio, dlg_manage is called and kamailio
searches for the dialog in the dialog list. It finds one but with
state 5 (I printed a debug in the source), probably finds the first
one, and thus it can no longer identify the ACK as being part of the
second dialog. For this reason, the dialog created during the second
invite remains with state 3.
This causes sometimes the BYE not to be accepted correctly either, and
some dialogs remain stuck in the database until they expire.
Does anybody know why, when a dialog match is searched, when a match
that is in state 5 in found, the search is interrupted? I was thinking
of changing this so that the search can continue and the second INVITE
dialog can be found, but I'm not sure that's safe.
Thanks a lot,
Catalina Oancea
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
5663
days inactive
5664
days old
3 comments
4 participants
participants (4)
-
Alex Balashov -
catalina oancea -
Daniel-Constantin Mierla -
Ovidiu Sas