New subject: [Serusers] Via RPORT for CANCEL message.

17 Aug 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@teigre.com]
Enviado el: jueves, 17 de agosto de 2006 4:05
Para: Ricardo Martinez
CC: serusers(a)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.- 

RV: [Serusers] Via RPORT for CANCEL message.