I found another discussion on this,<br><a href="http://www.openser.org/pipermail/users/2007-July/012258.html">http://www.openser.org/pipermail/users/2007-July/012258.html</a> <br><br>Again specially in this case it does not make sense at all to send call to maddr in place of host in the domain. <br>
<br>Say this is the desired scenario<br><br>A -> B(Opensips1.6) -> C<br><br>- If A send call to B with maddr the call works perfect and goes to C. <br>- But if A send call to B with maddres B send invite back to A (Does not make any sense) <br>
<br>Also in another case <br> <br>A Send call to B'is IP on some domain (Domain is in the table) <br>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. <br>
<br>U <a href="http://192.168.2.11:5060">192.168.2.11:5060</a> -> <a href="http://192.168.2.21:5060">192.168.2.21:5060</a><br>INVITE sip:19498859944@somedomain.com:5060;user=phone;transport=UDP;maddr=192.168.2.21 SIP/2.0.<br>
<br>Call processed through routing module found the rule that<br>19498859944 should be forwarded to 192.168.2.30<br><br>After loading the dr_load<br>$ru is <br><a href="mailto:sip%3A19498859944@192.168.2.30">sip:19498859944@192.168.2.30</a>;user=phone;transport=UDP;maddr=192.168.2.21<br>
<br>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. :( <br>
<br>Now I think this is bug here in drouting module, which is not updating the maddr. I believe the new $ru should be<br><a href="mailto:sip%3A19498859944@192.168.2.30">sip:19498859944@192.168.2.30</a>;user=phone;transport=UDP;maddr=192.168.2.30 <br>
<br>Hope I gave good example, any thoughts? <br>So either t_relay should not send call to maddr. <br>Or maddr should be updated in the drouting module as well as LCR and carrier route modules. <br><br>I believe this can be fixed in the script itself. Looking for better suggestions. <br>
<br><br>-Jai<br><br><br><br><br><div class="gmail_quote">On Sun, Dec 13, 2009 at 12:12 PM, Jai Rangi <span dir="ltr"><<a href="mailto:jprangi@didforsale.com">jprangi@didforsale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font size="2">I am having issue with call routing in certain situation. I am using drouting module and permission module for authentications.<br><br>Here is the trace<br><br><b> # Call comes from 192.168.1.11 to 192.168.1.11</b><br>
<br>U <a href="http://192.168.1.11:5060" target="_blank">192.168.1.11:5060</a> -> <a href="http://192.168.1.13:5060" target="_blank">192.168.1.13:5060</a><br><br>INVITE sip:19498858961@192.168.1.13:5060;user=phone;transport=UDP;maddr=192.168.1.11 SIP/2.0.<br>
<br>Record-Route: <sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on>.<br><br>Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.<br><br>v: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.<br>
<br>Record-Route: <sip:65.243.172.245:5060;lr>.<br><br>v: SIP/2.0/UDP 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.<br><br>record-route: <sip:63.110.102.239;lr>.<br>
<br>Remote-Party-ID: <<a href="mailto:sip%3A%2B19496794816@63.110.102.239" target="_blank">sip:+19496794816@63.110.102.239</a>>;screen=yes;party=calling;privacy=off.<br><br>f: <sip:+19496794816@199.173.94.144:5060;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e.<br>
<br>t: <sip:+19498858961@63.110.102.239:5060;user=phone>.<br><br>i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.<br><br>CSeq: 1 INVITE.<br><br>Max-Forwards: 16.<br><br>k: 100rel, replaces.<br><br>allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.<br>
<br>v: SIP/2.0/UDP SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.<br><br>m: <sip:199.173.94.144:5060;transport=UDP>.<br><br>c: application/SDP.<br><br>l: 233.<br><br>
.<br><br>v=0.<br><br>o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.<br><br>s=-.<br><br>p=+1 6135555555.<br><br>c=IN IP4 199.173.77.34.<br><br>t=0 0.<br><br>m=audio 55632 RTP/AVP 18 0 8 101.<br><br>a=rtpmap:101 telephone-event/8000.<br>
<br>a=fmtp:101 0-15.<br><br>a=ptime:20.<br><br>a=fmtp:18 annexb=no.<br><br> <br><br># <br><br>U <a href="http://192.168.1.13:5060" target="_blank">192.168.1.13:5060</a> -> <a href="http://192.168.1.11:5060" target="_blank">192.168.1.11:5060</a><br>
<br>
SIP/2.0 100 Giving a try.<br><br>Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.<br><br>v: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.<br><br>v: SIP/2.0/UDP 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.<br>
<br>f: <sip:+19496794816@199.173.94.144:5060;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e.<br><br>t: <sip:+19498858961@63.110.102.239:5060;user=phone>.<br><br>i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.<br>
<br>CSeq: 1 INVITE.<br><br>v: SIP/2.0/UDP SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.<br><br>Server: OpenSIPS (1.6.0-notls (x86_64/linux)).<br><br>Content-Length: 0.<br>
<br>.<br><b><br> 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 </b>the IP in maddr. in place to destination IP. <br>
<br># Sending invite to originating IP. <br><br><b>U <a href="http://192.168.1.13:5060" target="_blank">192.168.1.13:5060</a> -> <a href="http://192.168.1.11:5060" target="_blank">192.168.1.11:5060</a><br></b><br><b>INVITE <a href="mailto:sip%3A19498858961@192.168.1.3" target="_blank">sip:19498858961@192.168.1.3</a>;user=phone;transport=UDP;maddr=192.168.1.11 SIP/2.0.</b><br>
<br>Record-Route: <sip:192.168.1.13;lr=on;ftag=dc7-13c4-5db56e-28caa21e-5db56e>.<br><br>Record-Route: <sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on>.<br><br>Via: SIP/2.0/UDP 192.168.1.13;branch=z9hG4bK2c7a.cb3da61.0.<br>
<br>Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.<br><br>v: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.<br><br>Record-Route: <sip:65.243.172.245:5060;lr>.<br>
<br>v: SIP/2.0/UDP 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.<br><br>record-route: <sip:63.110.102.239;lr>.<br><br>Remote-Party-ID: <<a href="mailto:sip%3A%2B19496794816@63.110.102.239" target="_blank">sip:+19496794816@63.110.102.239</a>>;screen=yes;party=calling;privacy=off.<br>
<br>f: <sip:+19496794816@199.173.94.144:5060;user=phone>;tag=dc7-13c4-5db56e-28caa21e-5db56e.<br><br>t: <sip:+19498858961@63.110.102.239:5060;user=phone>.<br><br>i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.<br>
<br>CSeq: 1 INVITE.<br><br>Max-Forwards: 15.<br><br>k: 100rel, replaces.<br><br>allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.<br><br>v: SIP/2.0/UDP SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.<br>
<br>m: <sip:199.173.94.144:5060;transport=UDP>.<br><br>c: application/SDP.<br><br>l: 233.<br><br>.<br><br>v=0.<br><br>o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.<br><br>s=-.<br><br>p=+1 6135555555.<br><br>
c=IN IP4 199.173.77.34.<br><br>t=0 0.<br><br>m=audio 55632 RTP/AVP 18 0 8 101.<br><br>a=rtpmap:101 telephone-event/8000.<br><br>a=fmtp:101 0-15.<br><br>a=p<br><br>#<br><br>My Routing logic is quite simple. <br><br>if (is_uri_host_local()) {<br>
# -- outbound to inbound<br> route(12);<br> }<br><br><br>route[4] {<br> #Routing to Public Network<br> <br> if (!do_routing("10","1")) {<br>
xlog("-- do_routing failed \n");<br> sl_send_reply("503", "Unable to load gateways");<br> exit ;<br> } else {<br> t_on_failure("1"); #<--- This will be where you load the nextgateway<br>
route(1);<br> exit;<br> };<br>} # End Route 4<br><br>route[12] {<br> # From an External Domain -> inbound<br><br> lookup("aliases");<br> if (!lookup("location")) {<br>
route(4);<br> exit ;<br> }<br> route(1);<br>}<br>route[1] {<br> <br> if (!t_relay()) {<br> sl_reply_error();<br> };<br> exit;<br>
}<br><br>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. <br><br>Best, <br>-Jai<br><br></font>
</blockquote></div><br>