RE: [Serusers] PSTN rerouting bug handling CANCEL message - sr-users

7 May 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]+@.*") {
                                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]+@.*") {
                                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@iptel.org [mailto:serdev-bounces@lists.iptel.org] On Behalf
Of Jan Janak
Sent: Thursday, May 06, 2004 8:58 PM
To: Raymond Chen
Cc: serdev@lists.iptel.org; serusers@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@202.123.123.125;tag=C2B5948-13C9..To:
sip:0085298637212@202.123.123.124..Date: Tue, 04 May
2004 10:48:14
   GMT..Call-ID:
971874CF-C0F011D3-8AFA976C-D4B6780B@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@202.123.123.125;tag=C2B5948-13C9..To
  : sip:0085298637212@202.123.123.124..Date: Tue, 04
May 2004 10:48:14 GMT..Call-ID:
971874CF-C0F011D3-8AFA976C-D4B6780B@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@202.123.123.124:5060
SIP/2.0..Via: SIP/2.0/UDP  202.123.123.125:5060..From:
<sip:34293057@211.147.234.
  150>;tag=C2B5948-13C9..To:
sip:0085298637212@202.123.123.124..Date: Mon, 03 Jan
2000 08:42:48 GMT..Call-ID: 971874CF-C0F011D3
  -8AFA976C-D4B6780B@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@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@211.147.234.1
  50>;tag=C2B5948-13C9..To:
sip:0085298637212@202.123.123.124..Date: Mon, 03 Jan
2000 08:42:48 GMT..Call-ID: 971874CF-C0F011D3-
  8AFA976C-D4B6780B@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@202.123.123.125;tag=C2B5948-13C9..To:
<sip
:0085298637212@202.123.123.124>;tag=8ade010e448416c7b1e15c5e4aff46dd-62a5..C
all-ID:
...
971874CF-C0F011D3-8AFA976C-D4B6780B@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@211.147.234.
  146:5060
out_uri=sip:600085298637212@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@202.123.123.125>;tag=C2B5948-13C9..To:
sip:0085298637212@202.123.123.124..Date: Tue, 04 May
2004 10:48:16 GMT..Call-ID:
971874CF-C0F011D3-8AFA976C-D4B6780B@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@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@211.147.234.
  150>;tag=C2B5948-13C9..To:
sip:0085298637212@202.123.123.124..Date: Mon, 03 Jan
2000 08:42:48 GMT..Call-ID: 971874CF-C0F011D3
  -8AFA976C-D4B6780B@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@202.123.123.125;party=calling;screen=yes;privacy=off..
  Timestamp: 946888968..Contact:
sip:34293057@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@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serdev mailing list
serdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev