[OpenSIPS-Users] Issue with call routing due to maddr
Jai Rangi
jprangi at gmail.com
Mon Dec 14 11:27:32 CET 2009
**********snip***********
So, I see here 2 issues (bugs):
1) why the A device places in RURI maddr its own IP ???? RURI points to
destination, so no info about source should be there. Typically maddr is
used in building Contact hdrs.
2) opensips should automatically remove the maddr param when the script
function do change the domain part of the RURI -> logically speaking, if
you want to change the destination, all fields with destination info
should be affected.
************ snip *******
Indeed.
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.
Either one of these 2 can do that trick
if($(ru{uri.maddr}) != "") {
$du = "sip:" + $rU + "@" + $rd + ":" + $rp ;
OR
$ru = "sip:" + $rU + "@" + $rd + ":" + $rp +";user=phone;transport=UDP"; //
I prefered this one.
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 :)
Best,
-Jai
On Mon, Dec 14, 2009 at 2:04 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> Hi Jai,
>
> Jai Rangi wrote:
> > I found another discussion on this,
> > http://www.openser.org/pipermail/users/2007-July/012258.html
> Correct :)
> >
> > Again specially in this case it does not make sense at all to send
> > call to maddr in place of host in the domain.
> yes, I agree -> I suggest you remove the maddr param from the RURI.
> >
> > 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.
> This works because lookup(location) replace the entire RURI (including
> the maddr), so the maddr is simply discarded.
>
> > - But if A send call to B with maddres B send invite back to A (Does
> > not make any sense)
> If you just change the domain part (as drouting does) of the RURI, the
> maddr param is preserved and will break the outbound routing of the call.
>
> So, I see here 2 issues (bugs):
>
> 1) why the A device places in RURI maddr its own IP ???? RURI points to
> destination, so no info about source should be there. Typically maddr is
> used in building Contact hdrs.
>
> 2) opensips should automatically remove the maddr param when the script
> function do change the domain part of the RURI -> logically speaking, if
> you want to change the destination, all fields with destination info
> should be affected.
>
> Regards,
> Bogdan
>
>
>
>
> >
> > 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 <http://192.168.2.11:5060> -> 192.168.2.21:5060
> > <http://192.168.2.21:5060>
> > INVITE
> > sip:19498859944 at 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:19498859944 at 192.168.2.30 <sip%3A19498859944 at 192.168.2.30>
> > <mailto:sip%3A19498859944 at 192.168.2.30<sip%253A19498859944 at 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:19498859944 at 192.168.2.30 <sip%3A19498859944 at 192.168.2.30>
> > <mailto:sip%3A19498859944 at 192.168.2.30<sip%253A19498859944 at 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 <jprangi at didforsale.com
> > <mailto:jprangi at 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 <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<sip%3A%2B19496794816 at 63.110.102.239>
> > <mailto:sip%3A%2B19496794816 at 63.110.102.239<sip%253A%252B19496794816 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 <sip%3A19498858961 at 192.168.1.3>
> > <mailto:sip%3A19498858961 at 192.168.1.3<sip%253A19498858961 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<sip%3A%2B19496794816 at 63.110.102.239>
> > <mailto:sip%3A%2B19496794816 at 63.110.102.239<sip%253A%252B19496794816 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20091214/da6ac054/attachment-0001.htm
More information about the Users
mailing list