**********snip***********<br>So, I see here 2 issues (bugs):<br>
<br>
1) why the A device places in RURI maddr its own IP ???? RURI points to<br>
destination, so no info about source should be there. Typically maddr is<br>
used in building Contact hdrs.<br>
<br>
2) opensips should automatically remove the maddr param when the script<br>
function do change the domain part of the RURI -> logically speaking, if<br>
you want to change the destination, all fields with destination info<br>
should be affected.<br>************ snip *******<br><br>Indeed. <br>For now the quick fix was to remove maddr just before relaying the call. I could have update $du as a work around, but that would have caused the issue with next hope using opensip. <br>
Either one of these 2 can do that trick<br>if($(ru{uri.maddr}) != "") {<br>$du = "sip:" + $rU + "@" + $rd + ":" + $rp ;<br>OR <br>$ru = "sip:" + $rU + "@" + $rd + ":" + $rp +";user=phone;transport=UDP"; // I prefered this one. <br>
<br>But ultimately would be nice to see the fix in module itself. Just pushed this to production, so far things looks good. Hope I will have good night sleep and happy morning :) <br><br>Best, <br><br>-Jai <br><br><br><br>
<br><br><div class="gmail_quote">On Mon, Dec 14, 2009 at 2:04 AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</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;">
Hi Jai,<br>
<div class="im"><br>
Jai Rangi wrote:<br>
> I found another discussion on this,<br>
> <a href="http://www.openser.org/pipermail/users/2007-July/012258.html" target="_blank">http://www.openser.org/pipermail/users/2007-July/012258.html</a><br>
</div>Correct :)<br>
<div class="im">><br>
> Again specially in this case it does not make sense at all to send<br>
> call to maddr in place of host in the domain.<br>
</div>yes, I agree -> I suggest you remove the maddr param from the RURI.<br>
<div class="im">><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>
</div>This works because lookup(location) replace the entire RURI (including<br>
the maddr), so the maddr is simply discarded.<br>
<div class="im"><br>
> - But if A send call to B with maddres B send invite back to A (Does<br>
> not make any sense)<br>
</div>If you just change the domain part (as drouting does) of the RURI, the<br>
maddr param is preserved and will break the outbound routing of the call.<br>
<br>
So, I see here 2 issues (bugs):<br>
<br>
1) why the A device places in RURI maddr its own IP ???? RURI points to<br>
destination, so no info about source should be there. Typically maddr is<br>
used in building Contact hdrs.<br>
<br>
2) opensips should automatically remove the maddr param when the script<br>
function do change the domain part of the RURI -> logically speaking, if<br>
you want to change the destination, all fields with destination info<br>
should be affected.<br>
<br>
Regards,<br>
Bogdan<br>
<div class="im"><br>
<br>
<br>
<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<br>
> of uri and sending call back to itself because of maddr and resulting<br>
> in 403 Forbidden here.<br>
><br>
</div>> U <a href="http://192.168.2.11:5060" target="_blank">192.168.2.11:5060</a> <<a href="http://192.168.2.11:5060" target="_blank">http://192.168.2.11:5060</a>> -> <a href="http://192.168.2.21:5060" target="_blank">192.168.2.21:5060</a><br>
> <<a href="http://192.168.2.21:5060" target="_blank">http://192.168.2.21:5060</a>><br>
<div class="im">> INVITE<br>
> sip:19498859944@somedomain.com:5060;user=phone;transport=UDP;maddr=192.168.2.21<br>
> 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><br>
</div>> <mailto:<a href="mailto:sip%253A19498859944@192.168.2.30">sip%3A19498859944@192.168.2.30</a>>;user=phone;transport=UDP;maddr=192.168.2.21<br>
<div class="im">><br>
> t_relay send call to 192.168.2.21 and call fails in the (is_uri_local)<br>
> cause it does not find 192.168.2.30 in the domain table. If you add<br>
> 192.168.2.30 in the domain table that will create a loop cause maddr<br>
> is never going to get update. :(<br>
><br>
> Now I think this is bug here in drouting module, which is not updating<br>
> 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><br>
</div>> <mailto:<a href="mailto:sip%253A19498859944@192.168.2.30">sip%3A19498859944@192.168.2.30</a>>;user=phone;transport=UDP;maddr=192.168.2.30<br>
<div class="im">><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<br>
> carrier route modules.<br>
><br>
> I believe this can be fixed in the script itself. Looking for better<br>
> suggestions.<br>
><br>
><br>
> -Jai<br>
><br>
><br>
><br>
><br>
> On Sun, Dec 13, 2009 at 12:12 PM, Jai Rangi <<a href="mailto:jprangi@didforsale.com">jprangi@didforsale.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:jprangi@didforsale.com">jprangi@didforsale.com</a>>> wrote:<br>
><br>
> I am having issue with call routing in certain situation. I am<br>
> using drouting module and permission module for authentications.<br>
><br>
> Here is the trace<br>
><br>
> * # Call comes from 192.168.1.11 to 192.168.1.11*<br>
><br>
</div>> U <a href="http://192.168.1.11:5060" target="_blank">192.168.1.11:5060</a> <<a href="http://192.168.1.11:5060" target="_blank">http://192.168.1.11:5060</a>> -><br>
> <a href="http://192.168.1.13:5060" target="_blank">192.168.1.13:5060</a> <<a href="http://192.168.1.13:5060" target="_blank">http://192.168.1.13:5060</a>><br>
<div class="im">><br>
> INVITE<br>
> sip:19498858961@192.168.1.13:5060;user=phone;transport=UDP;maddr=192.168.1.11<br>
> SIP/2.0.<br>
><br>
> Record-Route:<br>
> <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<br>
> 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<br>
> 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">sip:+19496794816@63.110.102.239</a><br>
</div>> <mailto:<a href="mailto:sip%253A%252B19496794816@63.110.102.239">sip%3A%2B19496794816@63.110.102.239</a>>>;screen=yes;party=calling;privacy=off.<br>
<div><div></div><div class="h5">><br>
> f:<br>
> <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:<br>
> ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.<br>
><br>
> v: SIP/2.0/UDP<br>
> 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>
</div></div>> U <a href="http://192.168.1.13:5060" target="_blank">192.168.1.13:5060</a> <<a href="http://192.168.1.13:5060" target="_blank">http://192.168.1.13:5060</a>> -><br>
> <a href="http://192.168.1.11:5060" target="_blank">192.168.1.11:5060</a> <<a href="http://192.168.1.11:5060" target="_blank">http://192.168.1.11:5060</a>><br>
<div class="im">><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<br>
> 65.243.172.245:5060;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.<br>
><br>
> v: SIP/2.0/UDP<br>
> 63.110.102.239:5060;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.<br>
><br>
> f:<br>
> <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<br>
> 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>
> *<br>
> According to drouting rules, call should be going to 192.168.1.3,<br>
> but somehow opensips is updating the maddress to the origination<br>
> IP (192.168.1.11 in this case) and is sending calls to *the IP in<br>
> maddr. in place to destination IP.<br>
><br>
> # Sending invite to originating IP.<br>
><br>
</div>> *U <a href="http://192.168.1.13:5060" target="_blank">192.168.1.13:5060</a> <<a href="http://192.168.1.13:5060" target="_blank">http://192.168.1.13:5060</a>> -><br>
> <a href="http://192.168.1.11:5060" target="_blank">192.168.1.11:5060</a> <<a href="http://192.168.1.11:5060" target="_blank">http://192.168.1.11:5060</a>><br>
<div class="im">> *<br>
> *INVITE <a href="mailto:sip%3A19498858961@192.168.1.3">sip:19498858961@192.168.1.3</a><br>
</div>> <mailto:<a href="mailto:sip%253A19498858961@192.168.1.3">sip%3A19498858961@192.168.1.3</a>>;user=phone;transport=UDP;maddr=192.168.1.11<br>
<div class="im">> SIP/2.0.*<br>
><br>
> Record-Route:<br>
> <sip:192.168.1.13;lr=on;ftag=dc7-13c4-5db56e-28caa21e-5db56e>.<br>
><br>
> Record-Route:<br>
> <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<br>
> 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<br>
> 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">sip:+19496794816@63.110.102.239</a><br>
</div>> <mailto:<a href="mailto:sip%253A%252B19496794816@63.110.102.239">sip%3A%2B19496794816@63.110.102.239</a>>>;screen=yes;party=calling;privacy=off.<br>
<div><div></div><div class="h5">><br>
> f:<br>
> <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:<br>
> ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.<br>
><br>
> v: SIP/2.0/UDP<br>
> 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<br>
> 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<br>
> IP in destination URI. Any help of link will be appreciated.<br>
><br>
> Best,<br>
> -Jai<br>
><br>
><br>
</div></div><div><div></div><div class="h5">> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
<br>
<br>
--<br>
Bogdan-Andrei Iancu<br>
<a href="http://www.voice-system.ro" target="_blank">www.voice-system.ro</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br>