#
-----------------------------------------------------------------
#
Call Tear Down Section
#
-----------------------------------------------------------------
if
(method=="BYE" || method=="CANCEL")
{
if (client_nat_test("3"))
{
force_rport();
xlog("L_INFO", "[%rm] - From:%fu ; To:%ru ; Call-ID:%ci ; Desde:%is\n - FORCE
RPORT
ON");
};
end_media_session();
setflag(1);
};
#
-----------------------------------------------------------------
#
Loose Route Section
#
-----------------------------------------------------------------
if
(loose_route()) {
if (has_totag() && (method=="INVITE" || method=="ACK")) {
if (client_nat_test("3")||search("^Route:.*;nat=yes")){
setflag(6);
use_media_proxy();
};
};
route(1);
break;
};
Having a quick look, you may have found a bug in the ONsip.org scripts. A CANCEL is not loose routed (a dialog has not yet been set up) and must be handled the same way as an INVITE, i.e. the only way to find the route for CANCEL is to route the CANCEL the same way you routed the INVITE. However, it seems that you have somehow has done that, as your domain has changed to @gw. in the CANCEL doing downstream (i.e. forwarded by your SER).
So, CANCEL should be sent to route(3), the INVITE handler and not route(1). I'm quite sure this was correct in a previous version, we even had some discussions around how to handle it and how to describe it, but it seems that something has happened along the way.
g-)
Ricardo Martinez wrote:Hello.
My main configuration is based on the ser.cfg from the issue 5 plus some modifications included by me. Beside that i'm usingversion: ser 0.9.3 (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, FAST_LOCK-ADAPTIVE_WAITADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
@(#) $Id: main.c,v 1.197 2004/12/03 19:09:31 andrei Exp $
main.c compiled on 11:03:37 Dec 22 2005 with gcc 3.2
I have a question regarding to sending a CANCEL message for an INVITE from a NAT'd endpoint. As far as i know the force_rport() command adds the received IP port to the top most via header in the SIP message, this enables subsequent SIP message to return to the proper port later on in a SIP transaction. My problem is that for a CANCEL message coming from a NAT'd endpoint this command seems not to be working. This is the scenario.
NAT'd endpoint : 200.100.100.248
SER : 200.100.100.246
SER-2 : 200.100.100.36
GW : 200.100.100.69
The NAT'd endpoint send an INVITE to the proxy, but then in the middle of the transaction decide to CANCEL the request.
As you can see in the "cancel_debug.txt" file included on this mail, the CANCEL message does not contain the "rport" in the Via header, so it seems to be routed back to the default sip port (5060). Is there a way to force the rport in a CANCEL? for a enpoint unable to put the rport by itself?
I want to do this according to the onsip document, in a compatible way..
Anyway i made a little test including a force_rport(); in the CANCEL handler
..........
# -----------------------------------------------------------------
# Record Route Section
# -----------------------------------------------------------------
if (method=="INVITE" && client_nat_test("3")) {
# INSERT YOUR IP ADDRESS HERE
record_route_preset("200.100.100.246:5060;nat=yes");
} else if (method!="REGISTER") {
record_route();
};# -----------------------------------------------------------------
# Call Tear Down Section
# -----------------------------------------------------------------
if (method=="BYE" || method=="CANCEL") {
end_media_session();
setflag(1);
};# -----------------------------------------------------------------
# Loose Route Section
# -----------------------------------------------------------------
if (loose_route()) {if (has_totag() && (method=="INVITE" || method=="ACK")) {
if (client_nat_test("3")||search("^Route:.*;nat=yes")){
setflag(6);
use_media_proxy();
};
};route(1);
break;
};# -----------------------------------------------------------------
# Call Type Processing Section
# -----------------------------------------------------------------
if (!is_uri_host_local()) {
if (is_from_local() || allow_trusted()) {
route(4);
route(1);
} else {
sl_send_reply("403", "Forbidden");
};
break;
};if (method=="CANCEL") {
force_rport();
route(1);
break;
} else if (method=="INVITE") {
route(3);
break;
} else if (method=="REGISTER") {
route(2);
break;
} else if (method=="ACK") {
route(1);
break;
};lookup("aliases");
if (uri!=myself) {
route(4);
route(1);
break;
};if (!lookup("location")) {
sl_send_reply("404", "User Not Found");
break;
};route(1);
this solve my problem but it seems not to be so accurate.
I hope that someone can help me
Thanks!
Ricardo Martinez.-