[OpenSIPS-Users] Issue with call routing due to maddr

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Dec 14 10:52:40 CET 2009


Hi Jai,

Is it because of the maddr - according to RFC3261, a maddr param, if 
present, has to be user over the domain part of the RURI.

Probably the best will be to remove the maddr param (when doing 
drouting) to avoid interfering with the routing.

Regards,
Bogdan

Jai Rangi wrote:
> I am having issue with call routing in certain situation. I am using 
> drouting module and permission module for authentications.
>
> Here is the trace
>
> * # Call comes from 192.168.1.11 to 192.168.1.11*
>
> U 192.168.1.11:5060 <http://192.168.1.11:5060> -> 192.168.1.13:5060 
> <http://192.168.1.13:5060>
>
> INVITE 
> sip:19498858961 at 192.168.1.13:5060;user=phone;transport=UDP;maddr=192.168.1.11 
> SIP/2.0.
>
> Record-Route: 
> <sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on>.
>
> Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.
>
> v: SIP/2.0/UDP 
> 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.
>
> Record-Route: <sip:65.243.172.245:5060;lr>.
>
> v: SIP/2.0/UDP 
> 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.
>
> record-route: <sip:63.110.102.239;lr>.
>
> Remote-Party-ID: <sip:+19496794816 at 63.110.102.239 
> <mailto:sip%3A%2B19496794816 at 63.110.102.239>>;screen=yes;party=calling;privacy=off.
>
> f: 
> <sip:+19496794816 at 199.173.94.144:5060;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e.
>
> t: <sip:+19498858961 at 63.110.102.239:5060;user=phone>.
>
> i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.
>
> CSeq: 1 INVITE.
>
> Max-Forwards: 16.
>
> k: 100rel, replaces.
>
> allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
>
> v: SIP/2.0/UDP 
> SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.
>
> m: <sip:199.173.94.144:5060;transport=UDP>.
>
> c: application/SDP.
>
> l: 233.
>
> .
>
> v=0.
>
> o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.
>
> s=-.
>
> p=+1 6135555555.
>
> c=IN IP4 199.173.77.34.
>
> t=0 0.
>
> m=audio 55632 RTP/AVP 18 0 8 101.
>
> a=rtpmap:101 telephone-event/8000.
>
> a=fmtp:101 0-15.
>
> a=ptime:20.
>
> a=fmtp:18 annexb=no.
>
>  
>
> #
>
> U 192.168.1.13:5060 <http://192.168.1.13:5060> -> 192.168.1.11:5060 
> <http://192.168.1.11:5060>
>
> SIP/2.0 100 Giving a try.
>
> Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.
>
> v: SIP/2.0/UDP 
> 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.
>
> v: SIP/2.0/UDP 
> 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.
>
> f: 
> <sip:+19496794816 at 199.173.94.144:5060;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e.
>
> t: <sip:+19498858961 at 63.110.102.239:5060;user=phone>.
>
> i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.
>
> CSeq: 1 INVITE.
>
> v: SIP/2.0/UDP 
> SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.
>
> Server: OpenSIPS (1.6.0-notls (x86_64/linux)).
>
> Content-Length: 0.
>
> .
> *
>  According to drouting rules, call should be going to 192.168.1.3, but 
> somehow opensips is updating the maddress to the origination IP 
> (192.168.1.11 in this case) and is sending calls to *the IP in maddr. 
> in place to destination IP.
>
> # Sending invite to originating IP.
>
> *U 192.168.1.13:5060 <http://192.168.1.13:5060> -> 192.168.1.11:5060 
> <http://192.168.1.11:5060>
> *
> *INVITE sip:19498858961 at 192.168.1.3 
> <mailto:sip%3A19498858961 at 192.168.1.3>;user=phone;transport=UDP;maddr=192.168.1.11 
> SIP/2.0.*
>
> Record-Route: 
> <sip:192.168.1.13;lr=on;ftag=dc7-13c4-5db56e-28caa21e-5db56e>.
>
> Record-Route: 
> <sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on>.
>
> Via: SIP/2.0/UDP 192.168.1.13;branch=z9hG4bK2c7a.cb3da61.0.
>
> Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.
>
> v: SIP/2.0/UDP 
> 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.
>
> Record-Route: <sip:65.243.172.245:5060;lr>.
>
> v: SIP/2.0/UDP 
> 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.
>
> record-route: <sip:63.110.102.239;lr>.
>
> Remote-Party-ID: <sip:+19496794816 at 63.110.102.239 
> <mailto:sip%3A%2B19496794816 at 63.110.102.239>>;screen=yes;party=calling;privacy=off.
>
> f: 
> <sip:+19496794816 at 199.173.94.144:5060;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e.
>
> t: <sip:+19498858961 at 63.110.102.239:5060;user=phone>.
>
> i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.
>
> CSeq: 1 INVITE.
>
> Max-Forwards: 15.
>
> k: 100rel, replaces.
>
> allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
>
> v: SIP/2.0/UDP 
> SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.
>
> m: <sip:199.173.94.144:5060;transport=UDP>.
>
> c: application/SDP.
>
> l: 233.
>
> .
>
> v=0.
>
> o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.
>
> s=-.
>
> p=+1 6135555555.
>
> c=IN IP4 199.173.77.34.
>
> t=0 0.
>
> m=audio 55632 RTP/AVP 18 0 8 101.
>
> a=rtpmap:101 telephone-event/8000.
>
> a=fmtp:101 0-15.
>
> a=p
>
> #
>
> My Routing logic is quite simple.
>
> if (is_uri_host_local()) {
>                    # -- outbound to inbound
>                         route(12);
>                 }
>
>
> route[4] {
>         #Routing to Public Network
>            
>         if (!do_routing("10","1")) {
>                 xlog("-- do_routing failed  \n");
>                 sl_send_reply("503", "Unable to load gateways");
>                 exit ;
>         } else {
>         t_on_failure("1");  #<--- This will be where you load the 
> nextgateway
>         route(1);
>         exit;
>        };
> } # End Route 4
>
> route[12] {
>         # From an External Domain -> inbound
>
>         lookup("aliases");
>         if (!lookup("location")) {
>                 route(4);
>                 exit ;
>         }
>         route(1);
> }
> route[1] {
>      
>         if (!t_relay()) {
>                       sl_reply_error();
>         };
>         exit;
> }
>
> I am confused why opensip is seding call to maddr IP in place of IP in 
> destination URI. Any help of link will be appreciated.
>
> Best,
> -Jai
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro




More information about the Users mailing list