Greg,
I really do need to buy you a pint because that was the problem. I'll test further tomorrow, but Asterisk really seemed to be unhappy with that ;lr> attribute in the record-route headers.
I've asked our 3rd party pstn gateway provider to modify their Sonus box (if they can) to write the lr tag correctly. But for now I have no choice but to kludge my ser.cfg and search() for it in every message. :-(
Regards, Paul
On Thu, 24 Feb 2005 07:10:53 -0500, Java Rockx javarockx@gmail.com wrote:
Here is my ser.cfg which I've removed all the non-BYE related route blocks.
Many Thanks! Paul
listen=24.11.12.24 listen=10.255.255.1 mhomed=1
# loadmodule stuff goes here # modparam stuff goes here
route {
# ------------------------------------------------------------------------ # Sanity Check Section # ------------------------------------------------------------------------ # ------------------------------------------------------------------------ # Record Route Section # ------------------------------------------------------------------------ if (method!="REGISTER") { record_route(); }; if (loose_route()) { if (method=="BYE") { setflag(1); # enable accounting for BYE messages. We do not # enable accounting for Record-Routed INVITE messages # because these are re-INVITEs and we already captured # the original INVITE during the call setup }; # I'm using mediaproxy - so tear down the RTP stuff if (method=="BYE" || method=="CANCEL")) { end_media_session(); }; if (method=="INVITE") { # re-INVITE messages must be handled differently because # our transparent RTP proxy needs to test the caller and # callee for NATed IP addresses otherwise we could lose # audio on one or both directions route(8); } else { route(1); }; break; }; # Only handle message destined for out served domains. Other messagesare just relayed if (!uri==myself) { route(1); break; };
# ------------------------------------------------------------------------ # Message Handler Logic # ------------------------------------------------------------------------ if (method=="BYE") { # NOTE: all BYE messages should be record-routed so they should never # hit this code block since they should be handled in the # loose_route section above, so this is just a safety net end_media_session(); route(1); } else if (method=="CANCEL") { # I'm not sure if any CANCELs messages would ever hit this block # but it's here for good measure :-) end_media_session(); route(1); } else if (method=="INVITE") { setflag(1); # enable accounting for *original* INVITE messages route(6); } else if (method=="NOTIFY") { route(2); } else if (method=="OPTIONS") { route(3); } else if (method=="REFER") { route(6); } else if (method=="REGISTER") { route(4); } else if (method=="SUBSCRIBE") { route(5); } else { # all other messages come here for default handling route(1); };}
route[1] { # ------------------------------------------------------------------------ # default message handler # ------------------------------------------------------------------------
# A note on when we need to call lookup("location") # # This was posted to serusers on 02/23/2005 by Daniel-Constantin Mierla # # lookup("location") has to be used for any request that has the domain # part of R-URI pointing to your SIP server, should be delivered to an # end-user and does not have to follow any Route header -- it does not # matter the type of method. Could be said that only REGISTERs are just # for servers, the others are either mixed (e.g, OPTIONS) or only for # end-users. if (!search(^"Route:") && !search(^"Record-Route:")) { lookup("location"); }; if (!t_relay()) { sl_reply_error(); };}
route[2] { # ------------------------------------------------------------------------ # NOTIFY Message Handler # ------------------------------------------------------------------------ }
route[3] { # ------------------------------------------------------------------------ # OPTIONS Message Handler # ------------------------------------------------------------------------ }
route[4] { # ------------------------------------------------------------------------ # REGISTER Message Handler # ------------------------------------------------------------------------ }
route[5] { # ------------------------------------------------------------------------ # SUBSCRIBE Message Handler # ------------------------------------------------------------------------ }
route[6] { # ------------------------------------------------------------------------ # INVITE Message Handler # ------------------------------------------------------------------------ }
route[7] {
# voicemail route rewritehostport("10.255.255.2:5060"); append_branch(); if (!isflagset(15)) { use_media_proxy(); }; t_on_reply("1"); if (!t_relay()) { end_media_session(); sl_reply_error(); };}
route[8] {
# ------------------------------------------------------------------------ # re-INVITE Message Handler # # This route is a stripped down version of route[6]. Here we only # lookup('location') in order to get the NAT flag from the location # table because we need to know wheather or not to enable RTP proxying}
onreply_route[1] {
}
failure_route[1] {
}
On Wed, 23 Feb 2005 22:08:12 -1000, Richard richard@o-matrix.org wrote:
It looks like a ser related problem. A ser config would help to troubleshoot.
Richard
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, February 23, 2005 6:44 PM To: serusers@lists.iptel.org Subject: [Serusers] HELP: SER-0.9 Record Route Problem Between SER andAsterisk
Hi All.
I'm using ser-0.9
Can anyone take a quick look at this short SIP conversation and tell me if they think the problem is with my ser.cfg or a bug in Asterisk 1.0.2.
We use a 3rd party for PSTN gateway functionality. This 3rd party uses a Sonus box behind a SIP proxy. Our SER proxy talks directly to their SIP proxy as needed to complete PSTN calls.
The problem is that when a PSTN caller dials a SIP phone and gets sent to voice mail (Asterisk) because of a no answer or busy condition, Asterisk hangs up after the caller leaves a message. When Asterisk hangs up, the BYE from Asterisk is sent to SER, however, SER incorrectly forwards the BYE directly to their Sonus gateway, rather than the their SIP proxy. This causes our PSTN gateway provider to have "open" billing records in their system.
If you look at the BYE message from Asterisk to SER you can see that route headers are missing (I think). The final BYE should have been sent to 68.86.100.20, but it was sent to 68.86.100.30 instead.
I am record_route()ing all messages except for REGISTER and I have the mhomed=1 parameter set.
Can anyone help me put the blame on either my ser.cfg or Asterisk?
Regards, Paul
IP LEGEND
68.86.100.30 - 3rd Party Sonus PSTN Gateway 68.86.100.20 - 3rd Party SIP Proxy 24.11.12.24 - Sip Express Router (eth0) 10.255.255.1 - Sip Express Router (eth1) 10.255.255.2 - Asterisk PBX
NOTE: I have Asterisk connected to the SER server with a crossover cable.
U 2005/02/23 22:24:18.848582 68.86.100.20:5060 -> 24.11.12.24:5060 INVITE sip:4075551212@24.11.12.24:5060 SIP/2.0. Via: SIP/2.0/UDP 68.86.100.20:5060;branch=z9hG4bKed82c1ba766-c3014f40. Via: SIP/2.0/UDP
68.86.100.30:5060;branch=7a874abcac87c7752a3d3c5c7ba10dc0.
To: 4075551212 sip:4075551212@68.86.100.30:5060. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 INVITE. Max-Forwards: 4. Contact: sip:3211231234@68.86.100.30:5060. Record-Route: sip:68.86.100.20:5060;lr. Content-Type: application/sdp. Content-Length: 312. . v=0. o=NexTone-MSW 1234 187 IN IP4 66.236.245.98. s=sip call. c=IN IP4 66.236.245.98. t=0 0. m=audio 16814 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=fmtp:4 annexa=yes. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16.
# U 2005/02/23 22:24:18.860022 24.11.12.24:5060 -> 68.86.100.20:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 68.86.100.20:5060;branch=z9hG4bKed82c1ba766-c3014f40. Via: SIP/2.0/UDP
68.86.100.30:5060;branch=7a874abcac87c7752a3d3c5c7ba10dc0.
To: 4075551212 sip:4075551212@68.86.100.30:5060. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 INVITE. Content-Length: 0. .
# U 2005/02/23 22:24:18.860259 10.255.255.1:1033 -> 10.255.255.2:5060 INVITE sip:699@10.255.255.2:5060 SIP/2.0. Record-Route: sip:10.255.255.1;r2=on;ftag=27DECB5C-17BD;lr=on. Record-Route: sip:24.11.12.24;r2=on;ftag=27DECB5C-17BD;lr=on. Via: SIP/2.0/UDP 10.255.255.1;branch=z9hG4bKb929.21080974.0. Via: SIP/2.0/UDP 68.86.100.20:5060;branch=z9hG4bKed82c1ba766-c3014f40. Via: SIP/2.0/UDP
68.86.100.30:5060;branch=7a874abcac87c7752a3d3c5c7ba10dc0.
To: 4075551212 sip:4075551212@68.86.100.30:5060. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 INVITE. Max-Forwards: 3. Contact: sip:3211231234@68.86.100.30:5060. Record-Route: sip:68.86.100.20:5060;lr. Content-Type: application/sdp. Content-Length: 312. . v=0. o=NexTone-MSW 1234 187 IN IP4 66.236.245.98. s=sip call. c=IN IP4 24.11.12.24. t=0 0. m=audio 36574 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=fmtp:4 annexa=yes. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16.
# U 2005/02/23 22:24:18.871131 10.255.255.2:5060 -> 10.255.255.1:1033 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 10.255.255.1;branch=z9hG4bKb929.21080974.0;received=10.255.255.1;rport=103 3. Via: SIP/2.0/UDP 68.86.100.20:5060;branch=z9hG4bKed82c1ba766-c3014f40. Via: SIP/2.0/UDP
68.86.100.30:5060;branch=7a874abcac87c7752a3d3c5c7ba10dc0.
From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. To: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: sip:699@10.255.255.2. Content-Length: 0. .
# U 2005/02/23 22:24:18.879160 10.255.255.2:5060 -> 10.255.255.1:1033 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.255.255.1;branch=z9hG4bKb929.21080974.0;received=10.255.255.1;rport=103 3. Via: SIP/2.0/UDP 68.86.100.20:5060;branch=z9hG4bKed82c1ba766-c3014f40. Via: SIP/2.0/UDP
68.86.100.30:5060;branch=7a874abcac87c7752a3d3c5c7ba10dc0.
Record-Route: sip:10.255.255.1;r2=on;ftag=27DECB5C-17BD;lr=on. Record-Route: sip:24.11.12.24;r2=on;ftag=27DECB5C-17BD;lr=on. Record-Route: sip:68.86.100.20:5060;lr. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. To: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: sip:699@10.255.255.2. Content-Type: application/sdp. Content-Length: 362. . v=0. o=root 550 550 IN IP4 10.255.255.2. s=session. c=IN IP4 10.255.255.2. t=0 0. m=audio 17900 RTP/AVP 97 18 3 4 2 0 8 101. a=rtpmap:97 iLBC/8000. a=rtpmap:18 G729/8000. a=rtpmap:3 GSM/8000. a=rtpmap:4 G723/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -.
# U 2005/02/23 22:24:18.883882 24.11.12.24:5060 -> 68.86.100.20:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 68.86.100.20:5060;branch=z9hG4bKed82c1ba766-c3014f40. Via: SIP/2.0/UDP
68.86.100.30:5060;branch=7a874abcac87c7752a3d3c5c7ba10dc0.
Record-Route: sip:10.255.255.1;r2=on;ftag=27DECB5C-17BD;lr=on. Record-Route: sip:24.11.12.24;r2=on;ftag=27DECB5C-17BD;lr=on. Record-Route: sip:68.86.100.20:5060;lr. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. To: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: sip:699@10.255.255.2. Content-Type: application/sdp. Content-Length: 363. . v=0. o=root 550 550 IN IP4 10.255.255.2. s=session. c=IN IP4 24.11.12.24. t=0 0. m=audio 36574 RTP/AVP 97 18 3 4 2 0 8 101. a=rtpmap:97 iLBC/8000. a=rtpmap:18 G729/8000. a=rtpmap:3 GSM/8000. a=rtpmap:4 G723/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -.
# U 2005/02/23 22:24:19.097436 68.86.100.20:5060 -> 24.11.12.24:5060 ACK sip:699@10.255.255.2 SIP/2.0. Via: SIP/2.0/UDP
68.86.100.20:5060;branch=ef5ce1f8a400adab242436d0564cb045.
Via: SIP/2.0/UDP
68.86.100.30:5060;branch=ef5ce1f8a400adab242436d0564cb045.
To: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 ACK. Max-Forwards: 4. Contact: sip:3211231234@68.86.100.30:5060. Record-Route: sip:68.86.100.20:5060;lr. Route: sip:24.11.12.24;r2=on;ftag=27DECB5C-17BD;lr=on. Route: sip:10.255.255.1;r2=on;ftag=27DECB5C-17BD;lr=on. Content-Length: 0. .
# U 2005/02/23 22:24:19.098087 10.255.255.1:1033 -> 10.255.255.2:5060 ACK sip:699@10.255.255.2 SIP/2.0. Record-Route: sip:10.255.255.1;r2=on;ftag=27DECB5C-17BD;lr=on. Record-Route: sip:24.11.12.24;r2=on;ftag=27DECB5C-17BD;lr=on. Via: SIP/2.0/UDP 10.255.255.1;branch=0. Via: SIP/2.0/UDP
68.86.100.20:5060;branch=ef5ce1f8a400adab242436d0564cb045.
Via: SIP/2.0/UDP
68.86.100.30:5060;branch=ef5ce1f8a400adab242436d0564cb045.
To: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. From: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 1 ACK. Max-Forwards: 3. Contact: sip:3211231234@68.86.100.30:5060. Record-Route: sip:68.86.100.20:5060;lr. Content-Length: 0. .
### U 2005/02/23 22:24:25.104860 10.255.255.2:5060 -> 10.255.255.1:1033 BYE sip:3211231234@68.86.100.30:5060 SIP/2.0. Via: SIP/2.0/UDP 10.255.255.2:5060;branch=z9hG4bK2da77693;rport. Route: sip:24.11.12.24;r2=on;ftag=27DECB5C- 17BD;lr=on,sip:68.86.100.20:5060;lr,sip:3211231234@68.86.100.30:5060. From: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. To: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Contact: sip:699@10.255.255.2. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 102 BYE. User-Agent: Asterisk PBX. Content-Length: 0. .
# U 2005/02/23 22:24:25.108961 24.11.12.24:5060 -> 68.86.100.30:5060 BYE sip:3211231234@68.86.100.30:5060 SIP/2.0. Max-Forwards: 10. Record-Route: sip:24.11.12.24;r2=on;ftag=as588114d9;lr=on. Record-Route: sip:10.255.255.1;r2=on;ftag=as588114d9;lr=on. Via: SIP/2.0/UDP 24.11.12.24;branch=z9hG4bK231b.07949ea5.0. Via: SIP/2.0/UDP 10.255.255.2:5060;branch=z9hG4bK2da77693;rport=5060. From: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. To: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Contact: sip:699@10.255.255.2. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 102 BYE. User-Agent: Asterisk PBX. Content-Length: 0. Route: sip:3211231234@68.86.100.30:5060. .
# U 2005/02/23 22:24:25.175832 68.86.100.30:5060 -> 24.11.12.24:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 24.11.12.24;branch=z9hG4bK231b.07949ea5.0. Via: SIP/2.0/UDP 10.255.255.2:5060;branch=z9hG4bK2da77693;rport=5060. From: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. To: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 102 BYE. Content-Length: 0. .
# U 2005/02/23 22:24:25.176182 10.255.255.1:1033 -> 10.255.255.2:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.255.255.2:5060;branch=z9hG4bK2da77693;rport=5060. From: 4075551212 sip:4075551212@68.86.100.30:5060;tag=as588114d9. To: sip:3211231234@66.236.245.98;tag=27DECB5C-17BD. Call-ID: 9028535-3318204258-749010@68.86.100.30. CSeq: 102 BYE. Content-Length: 0. .
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers