I found another discussion on this, http://www.openser.org/pipermail/users/2007-July/012258.html
Again specially in this case it does not make sense at all to send call to maddr in place of host in the domain. Say this is the desired scenario A -> B(Opensips1.6) -> C - If A send call to B with maddr the call works perfect and goes to C. - But if A send call to B with maddres B send invite back to A (Does not make any sense) Also in another case A Send call to B'is IP on some domain (Domain is in the table) B is not updating the maddr in the SIP header but update domain part of uri and sending call back to itself because of maddr and resulting in 403 Forbidden here. U 192.168.2.11:5060 -> 192.168.2.21:5060 INVITE sip:19498859...@somedomain.com:5060;user=phone;transport=UDP;maddr=192.168.2.21 SIP/2.0. Call processed through routing module found the rule that 19498859944 should be forwarded to 192.168.2.30 After loading the dr_load $ru is sip:19498859...@192.168.2.30 <sip%3a19498859...@192.168.2.30> ;user=phone;transport=UDP;maddr=192.168.2.21 t_relay send call to 192.168.2.21 and call fails in the (is_uri_local) cause it does not find 192.168.2.30 in the domain table. If you add 192.168.2.30 in the domain table that will create a loop cause maddr is never going to get update. :( Now I think this is bug here in drouting module, which is not updating the maddr. I believe the new $ru should be sip:19498859...@192.168.2.30 <sip%3a19498859...@192.168.2.30>;user=phone;transport=UDP;maddr=192.168.2.30 Hope I gave good example, any thoughts? So either t_relay should not send call to maddr. Or maddr should be updated in the drouting module as well as LCR and carrier route modules. I believe this can be fixed in the script itself. Looking for better suggestions. -Jai On Sun, Dec 13, 2009 at 12:12 PM, Jai Rangi <jpra...@didforsale.com> 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 -> 192.168.1.13:5060 > > INVITE > sip:19498858...@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:+19496794...@63.110.102.239<sip%3a%2b19496794...@63.110.102.239> > >;screen=yes;party=calling;privacy=off. > > f: <sip:+19496794...@199.173.94.144:5060 > ;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e. > > t: <sip:+19498858...@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 -> 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:+19496794...@199.173.94.144:5060 > ;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e. > > t: <sip:+19498858...@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 -> 192.168.1.11:5060 > * > *INVITE sip:19498858...@192.168.1.3 > <sip%3a19498858...@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:+19496794...@63.110.102.239<sip%3a%2b19496794...@63.110.102.239> > >;screen=yes;party=calling;privacy=off. > > f: <sip:+19496794...@199.173.94.144:5060 > ;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e. > > t: <sip:+19498858...@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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users