[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