[Serusers] PSTN rerouting bug handling CANCEL message

Raymond Chen rchen at cityabove.net
Fri May 7 11:58:11 CEST 2004


Here is the configuration 

route {

        if (!mf_process_maxfwd_header("10")) {
                log("LOG: Too many hops\n");
                sl_send_reply("483", "Alas Too Many Hops");
                break;
        };

        if (msg:len >= max_len) {
                sl_send_reply("513", "Message too large");
                break;
        };

        # if route forces us to forward to some explicit destination, do so
        #
        # loose_route returns true in case that a request included
        # route header fields instructing SER where to relay a request;
        # if that is the case, stop script processing and just forward
there;
        # one could alternatively ignore the return value and treat the
        # request as if it was an outbound one; that would not work however
        # with broken UAs which strip RR parameters from Route. (What
happens
        # is that with two RR /tcp2udp, spirals, etc./ and stripped
parameters,
        # SER a) rewrites r-uri with RR1 b) matches uri==myself against RR1
        # c) applies mistakenly user-lookup to RR1 in r-uri
        
        if (loose_route()) {
                setflag(1);
                t_relay();
                break;
        };
        
        if (!does_uri_exist()) {
                # Try numeric destinations through the gateway
                if (uri =~ "^[a-zA-Z]+:[0-9]+@") {
                        route(3);
                } else {
                        sl_send_reply("604", "Does Not Exist Anywhere");
                };
                break;
        };

}

route[3] {

        # discard non-PSTN methods
        if (!(method == "INVITE" || method == "ACK" || method == "CANCEL" ||
method == "OPTIONS" || method == "BYE")) {
                sl_send_reply("500", "only VoIP methods accepted for GW");
                break;
        };

        # continue with requests to PSTN gateway ...

        # no authentication needed if the destination is on our free-pstn
        # list or if the caller is the digest-less gateway
        #
        # apply ACLs only to INVITEs -- we don't need to protect other
        # requests, as they don't imply charges; also it could cause
troubles
        # when a call comes in via PSTN and goes to a party that can't
        # authenticate (voicemail, other domain) -- BYEs would fail then
        if (method == "INVITE" || method=="ACK" || method=="CANCEL" ||
method=="BYE") {

                        # does the authenticated user have a permission for
local
                        # calls (destinations beginning with a single zero)?
                        # (i.e., is he in the "local" group?)
                        if (uri=~"sip:0[1-9][0-9]+ at .*") {
                                if (!is_user_in("from", "all") &&
!is_user_in("from","ld")) {
                                        rewriteuser("unregistereduser");
                                        forward(211.147.234.158,5090);
                                        break;
                                };

                                record_route();
                                setflag(1);
                                route(5);

                        # the same for long-distance (destinations begin
with two zeros")
                        } else if (uri=~"sip:00[1-9][0-9]+ at .*") {
                                if (!is_user_in("from", "all") &&
!is_user_in("from","int")) {
                                        rewriteuser("unregistereduser");
                                        forward(123.123.123.122,5090);
#announcement server
                                        break;
                                };

                                record_route();
                                setflag(1);
                                route(10);

                        # everything else (e.g., interplanetary calls) is
denied
                        } else {
                                rewriteuser("wrongnumber");
                                forward(123.123.123.122,5090);
                                break;
                        };

        }; # authorized PSTN
        break;
}

route[5] {
        rewritehostport("123.123.123.125:5060");
        append_branch(); # Command needed for reroute to work
        consume_credentials();
        append_hf("P-Hint: GATEWAY\r\n");
        t_on_failure("6");
        t_relay();
}


failure_route[6] {
        rewritehostport("123.123.123.124:5060");
        append_branch();
        t_on_failure("7");
        t_relay();
}

failure_route[7] {
        rewritehostport("123.123.123.123:5060");
        append_branch();
        t_on_failure("8");
        t_relay();
}

failure_route[8] {
        rewriteuser("networkbusy");
        rewritehostport("123.123.123.122:5090");
        append_branch();
        t_relay();
}

Configuration works for 0.8.12 but not for 0.8.13 when CANCEL message is
received, calls not termination properly.



-----Original Message-----
From: serdev-bounces at iptel.org [mailto:serdev-bounces at lists.iptel.org] On Behalf
Of Jan Janak
Sent: Thursday, May 06, 2004 8:58 PM
To: Raymond Chen
Cc: serdev at lists.iptel.org; serusers at lists.iptel.org
Subject: [Serdev] Re: [Serusers] PSTN rerouting bug handling CANCEL message

Could you send us the configuration file, there is probably some problem
in it.
  
  Jan.

On 04-05 04:21, Raymond Chen wrote:
> Dear all,
> 
> I am testing SER CVS head for PSTN rerouting if the
> first route has failed like example onr.cfg.  the
> problem is the caller cancels the call before the call
> is pick up but SER didn?t properly terminate it,
> instead it sends to the second route and the third. 
> It ends up the callee rings multiple times.   It
> didn?t happen in the stable release 0.8.12, but we
> would like to usualize the new mysql module connection
> pool in 0.8.13 cvs head.  Any one has a solution? 
> 
> U 202.123.123.123:5060 -> 211.123.123.124:5060
>   SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> 202.123.123.124;branch=z9hG4bK1908.c8b2c55.0,SIP/2.0/UDP
>  202.123.123.125:5060..
>   From:
> <sip:34293057 at 202.123.123.125>;tag=C2B5948-13C9..To:
> <sip:0085298637212 at 202.123.123.124>..Date: Tue, 04 May
> 2004 10:48:14
>    GMT..Call-ID:
> 971874CF-C0F011D3-8AFA976C-D4B6780B at 202.123.123.125..Timestamp:
> 946888968..Server: Cisco VoIP Gateway/ IOS 12.x/
>    SIP enabled..CSeq: 101 INVITE..Content-Type:
> application/sdp..Session: Media..Content-Length:
> 140....v=0..o=CiscoSystemsSIP-GW
>   -UserAgent 5444 359 IN IP4 202.123.123.123..s=SIP
> Call..c=IN IP4 202.123.123.123..t=0 0..m=audio 20150
> RTP/AVP 18..            
> #
> U 202.123.123.124:5060 -> 202.123.123.125:5060
>   SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 
> 202.123.123.125:5060..From:
> <sip:34293057 at 202.123.123.125>;tag=C2B5948-13C9..To
>   : <sip:0085298637212 at 202.123.123.124>..Date: Tue, 04
> May 2004 10:48:14 GMT..Call-ID:
> 971874CF-C0F011D3-8AFA976C-D4B6780B at 211.14
>   7.234.150..Timestamp: 946888968..Server: Cisco VoIP
> Gateway/ IOS 12.x/ SIP enabled..CSeq: 101
> INVITE..Content-Type: application
>   /sdp..Session: Media..Content-Length:
> 140....v=0..o=CiscoSystemsSIP-GW-UserAgent 5444 359 IN
> IP4 202.123.123.123..s=SIP Call..c
>   =IN IP4 202.123.123.123..t=0 0..m=audio 20150
> RTP/AVP 18..                                          
>                           
> #
> U 202.123.123.125:59047 -> 202.123.123.124:5060
>   CANCEL sip:0085298637212 at 202.123.123.124:5060
> SIP/2.0..Via: SIP/2.0/UDP  202.123.123.125:5060..From:
> <sip:34293057 at 211.147.234.
>   150>;tag=C2B5948-13C9..To:
> <sip:0085298637212 at 202.123.123.124>..Date: Mon, 03 Jan
> 2000 08:42:48 GMT..Call-ID: 971874CF-C0F011D3
>   -8AFA976C-D4B6780B at 202.123.123.125..CSeq: 101
> CANCEL..Max-Forwards: 6..Timestamp:
> 946888970..Content-Length: 0....             
> #
> U 202.123.123.124:5060 -> 202.123.123.123:5060
>   CANCEL sip:600085298637212 at 202.123.123.123:5060
> SIP/2.0..Record-Route:
> <sip:202.123.123.124;ftag=C2B5948-13C9;lr=on>..Via:
> SIP/
>   2.0/UDP
> 202.123.123.124;branch=z9hG4bK1908.c8b2c55.0..Via:
> SIP/2.0/UDP  202.123.123.125:5060..From:
> <sip:34293057 at 211.147.234.1
>   50>;tag=C2B5948-13C9..To:
> <sip:0085298637212 at 202.123.123.124>..Date: Mon, 03 Jan
> 2000 08:42:48 GMT..Call-ID: 971874CF-C0F011D3-
>   8AFA976C-D4B6780B at 202.123.123.125..CSeq: 101
> CANCEL..Max-Forwards: 5..Timestamp:
> 946888970..Content-Length: 0..P-Hint: GATEWAY.
>   ...                                                 
>                                                       
>                    
> #
> U 202.123.123.124:5060 -> 202.123.123.125:5060
>   SIP/2.0 200 cancelling..Via: SIP/2.0/UDP 
> 202.123.123.125:5060..From:
> <sip:34293057 at 202.123.123.125>;tag=C2B5948-13C9..To:
> <sip
>  
>
:0085298637212 at 202.123.123.124>;tag=8ade010e448416c7b1e15c5e4aff46dd-62a5..C
all-ID:
> 971874CF-C0F011D3-8AFA976C-D4B6780B at 211.147
>   .234.150..CSeq: 101 CANCEL..Server: Sip EXpress
> router (0.8.13-dev-29 (i386/linux))..Content-Length:
> 0..Warning: 392 211.147.23
>   4.146:5060 "Noisy feedback tells:  pid=2909
> req_src_ip=202.123.123.125 req_src_port=59047
> in_uri=sip:0085298637212 at 211.147.234.
>   146:5060
> out_uri=sip:600085298637212 at 202.123.123.123:5060
> via_cnt==1"....                                       
>               
> #
> U 202.123.123.123:5060 -> 202.123.123.124:5060
>   SIP/2.0 200 OK..Via: SIP/2.0/UDP
> 202.123.123.124;branch=z9hG4bK1908.c8b2c55.0,SIP/2.0/UDP
>  202.123.123.125:5060..From: <sip:342
>   93057 at 202.123.123.125>;tag=C2B5948-13C9..To:
> <sip:0085298637212 at 202.123.123.124>..Date: Tue, 04 May
> 2004 10:48:16 GMT..Call-ID:
>   
> 971874CF-C0F011D3-8AFA976C-D4B6780B at 202.123.123.125..Timestamp:
> 946888970..Content-Length: 0..CSeq: 101 CANCEL....    
>        
> 
> 
> 
> #
> U 202.123.123.124:5060 -> 211.123.123.128:5060
>   INVITE sip:901201185298637212 at 63.192.114.66:5060
> SIP/2.0..Record-Route:
> <sip:202.123.123.124;ftag=C2B5948-13C9;lr=on>..Via:
> SIP
>   /2.0/UDP
> 202.123.123.124;branch=z9hG4bK1908.c8b2c55.2..Via:
> SIP/2.0/UDP  202.123.123.125:5060..From:
> <sip:34293057 at 211.147.234.
>   150>;tag=C2B5948-13C9..To:
> <sip:0085298637212 at 202.123.123.124>..Date: Mon, 03 Jan
> 2000 08:42:48 GMT..Call-ID: 971874CF-C0F011D3
>   -8AFA976C-D4B6780B at 202.123.123.125..Supported:
> timer,100rel..Min-SE:  1800..Cisco-Guid:
> 2484681635-3236958675-2331481964-356872
>   8075..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow:
> INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET,
> REFER, SUBSCRIBE, NOTIFY, 
>   INFO..CSeq: 101 INVITE..Max-Forwards:
> 5..Remote-Party-ID:
> <sip:34293057 at 202.123.123.125>;party=calling;screen=yes;privacy=off..
>   Timestamp: 946888968..Contact:
> <sip:34293057 at 202.123.123.125:5060>..Expires:
> 180..Allow-Events: telephone-event..Content-Type: 
>   application/sdp..Content-Length: 328..P-Hint:
> GATEWAY....v=0..o=CiscoSystemsSIP-GW-UserAgent 5757
> 2194 IN IP4 202.123.123.125..
>   s=SIP Call..c=IN IP4 202.123.123.125..t=0 0..m=audio
> 17774 RTP/AVP 18 4 0 8 19..c=IN IP4
> 202.123.123.125..a=rtpmap:18 G729/8000
>   ..a=fmtp:18 annexb=yes..a=rtpmap:4
> G723/8000..a=fmtp:4 annexa=no..a=rtpmap:0
> PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:19 CN/80
>   00..  
> 
> Thanks
> 
> Raymond
> 
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs  
> http://hotjobs.sweepstakes.yahoo.com/careermakeover 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers

_______________________________________________
Serdev mailing list
serdev at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev





More information about the sr-users mailing list