[Serusers] HELP: SER-0.9 Record Route Problem Between SER andAsterisk

Java Rockx javarockx at gmail.com
Fri Feb 25 05:59:01 CET 2005


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 at 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 messages
> are 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 at o-matrix.org> wrote:
> > It looks like a ser related problem. A ser config would help to
> > troubleshoot.
> >
> > Richard
> >
> > > -----Original Message-----
> > > From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
> > > Behalf Of Java Rockx
> > > Sent: Wednesday, February 23, 2005 6:44 PM
> > > To: serusers at 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 at 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 at 68.86.100.30:5060>.
> > > From: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 INVITE.
> > > Max-Forwards: 4.
> > > Contact: sip:3211231234 at 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 at 68.86.100.30:5060>.
> > > From: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 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 at 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 at 68.86.100.30:5060>.
> > > From: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 INVITE.
> > > Max-Forwards: 3.
> > > Contact: sip:3211231234 at 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 at 66.236.245.98;tag=27DECB5C-17BD.
> > > To: 4075551212 <sip:4075551212 at 68.86.100.30:5060>;tag=as588114d9.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 INVITE.
> > > User-Agent: Asterisk PBX.
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
> > > Contact: <sip:699 at 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 at 66.236.245.98;tag=27DECB5C-17BD.
> > > To: 4075551212 <sip:4075551212 at 68.86.100.30:5060>;tag=as588114d9.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 INVITE.
> > > User-Agent: Asterisk PBX.
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
> > > Contact: <sip:699 at 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 at 66.236.245.98;tag=27DECB5C-17BD.
> > > To: 4075551212 <sip:4075551212 at 68.86.100.30:5060>;tag=as588114d9.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 INVITE.
> > > User-Agent: Asterisk PBX.
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
> > > Contact: <sip:699 at 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 at 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 at 68.86.100.30:5060>;tag=as588114d9.
> > > From: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 ACK.
> > > Max-Forwards: 4.
> > > Contact: sip:3211231234 at 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 at 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 at 68.86.100.30:5060>;tag=as588114d9.
> > > From: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 1 ACK.
> > > Max-Forwards: 3.
> > > Contact: sip:3211231234 at 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 at 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 at 68.86.100.30:5060>.
> > > From: 4075551212 <sip:4075551212 at 68.86.100.30:5060>;tag=as588114d9.
> > > To: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Contact: <sip:699 at 10.255.255.2>.
> > > Call-ID: 9028535-3318204258-749010 at 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 at 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 at 68.86.100.30:5060>;tag=as588114d9.
> > > To: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Contact: <sip:699 at 10.255.255.2>.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 102 BYE.
> > > User-Agent: Asterisk PBX.
> > > Content-Length: 0.
> > > Route: <sip:3211231234 at 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 at 68.86.100.30:5060>;tag=as588114d9.
> > > To: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 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 at 68.86.100.30:5060>;tag=as588114d9.
> > > To: sip:3211231234 at 66.236.245.98;tag=27DECB5C-17BD.
> > > Call-ID: 9028535-3318204258-749010 at 68.86.100.30.
> > > CSeq: 102 BYE.
> > > Content-Length: 0.
> > > .
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > serusers at lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
>




More information about the sr-users mailing list