28 May
2009
28 May
'09
9:48 p.m.
Hi Daniel,
Actually reading RFC 3261 I see that the same callid must be used:
This
Note that when requests are retried after certain
failure responses that solicit an amendment to a request (for
example, a challenge for authentication), these retried requests are
not considered new requests, and therefore do not need new Call-ID
header fields;
I tried xlog to print $dlg(ref) when receiving 407, in the
failure_route (actually it's 401, but that doesn't matter) and it
printed <null>.
I also printed the dialogs using mi-fifo after the call was and it
only showed one dialog.
I don't know how long the first dialog lasts but I am sure that it is
in the list because I added a debug message in the source printing
"dialog_deleted" when the dialog is found and it is in state deleted.
Why is it in state deleted and not actually removed? Why does the
search stop when the dialog is found but it is in state deleted? And
shouldn't there be only one dialog for both INVITEs, since, the callid
and from tag is the same?
Many thanks,
Catalina
2009/5/28, Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
On 05/27/2009 06:44 PM, catalina oancea wrote:
Yeah ok, but this is not the issue here.
Even if I use record-routing, if I don't use the fast-matching cookie,
the problem I described still remains.
as I got from the diagram in your first email, second call, coming after
407, preserves the call-id and from tag?
According to RFC, this is a completely new dialog and should use
different values.
Anyhow, after you send back the challenge, can you print with xlog
$dlg(ref) and paste it here? Is the ended dialog staying for long time
(you can use mi to list dlgs)?
Cheers,
Daniel
2009/5/27 Alex Balashov <abalashov(a)evaristesys.com>om>:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Catalina,
catalina oancea wrote:
_______________________________________________
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
From what I know the record-route header is not
compulsory, and
dialog-matching can also be done using rfc dialog-matching instead of
the did parameter in record-route (modparam("dialog",
"dlg_match_mode", 2)). This is what I am trying to use, I don't want
to use the record-route header at all.
It is true that you do not have to use the dialog fast-matching cookie
parameter in the Record-Route header.
However, you need the Record-Route header in order for the proxy to have
visibility into subsequent sequential requests within the dialog, so you
might as well use the parameter for faster matching.
In other words, if you don't add Record-Route, your proxy won't see BYEs,
re-INVITEs, etc. See RFC 3261 20.30
(http://www.ietf.org/rfc/rfc3261.txt):
20.30 Record-Route
The Record-Route header field is inserted by proxies in a request to
force future requests in the dialog to be routed through the proxy.
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775