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

-----Original Message----- From: Java Rockx [mailto:javarockx@gmail.com] Sent: Thursday, February 24, 2005 2:11 AM To: Richard Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] HELP: SER-0.9 Record Route Problem Between SER andAsterisk Here is my ser.cfg which I've removed all the non-BYE related route

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

not # enable accounting for

messages # because these are re-INVITEs and

already captured # the original INVITE during the

}; # 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

# our transparent RTP proxy needs to test the caller

# callee for NATed IP addresses otherwise we could

# 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

# loose_route section above, so this is just a safety

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

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 &lt;richard(a)o-matrix.org&gt; wrote: On cable. 10.255.255.1;branch=z9hG4bKb929.21080974.0;received=10.255.255.1;rport=103 10.255.255.1;branch=z9hG4bKb929.21080974.0;received=10.255.255.1;rport=103 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(a)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(a)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(a)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(a)68.86.100.30. > > CSeq: 102 BYE. > > Content-Length: 0. > > . > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > >