RV: [Serusers] Via RPORT for CANCEL message.
Ricardo Martinez
rmartinez at redvoiss.net
Thu Aug 17 16:50:24 CEST 2006
Hello Greger and thanks for your answer
I tested sending the CANCEL to route(3), and it seems to be working ok now. But now i'm facing another problem. The OK message for the BYE seems not to be routed back to the NAT'd port, instead is routed to the default port. Please check the file attached (BYE_debug.TXT).
As i pointed in my first post, the calling endpoint is NAT'd. Following the BYE sequence seems to be right, it hits the loose_route section and then the route(1), but since the BYE does not contain the rport parameter in the VIA header the OK is routed back to the port advertised in the VIA header. (5061) and not to the received port.
Maybe i'm doing something wrong?.
I tested a new solution, but i don't know if is correct or is according to the ONSIP document.
I added a client_nat_test("3") in the Call Tear Down Section-
..........
# -----------------------------------------------------------------
# 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") {
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;
};
.......
Hope that someone could help me here.
Thanks
Regards,
Ricardo Martinez.-
-----Mensaje original-----
De: Greger V. Teigre [mailto:greger at teigre.com]
Enviado el: jueves, 17 de agosto de 2006 4:05
Para: Ricardo Martinez
CC: serusers at iptel.org
Asunto: Re: [Serusers] Via RPORT for CANCEL message.
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 using
version: 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_WAIT
ADAPTIVE_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.-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060817/1238c16f/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: BYE_debug.TXT
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060817/1238c16f/attachment.asc>
More information about the sr-users
mailing list