[OpenSIPS-Users] Issue with call routing due to maddr
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Mon Dec 14 13:49:06 CET 2009
Hi Jai,
I will open a bug report to fix item (2), but you should also try to fix
bug (1) also.
Thanks and Regards,
Bogdan
Jai Rangi wrote:
> **********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 <mailto: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>
> <http://192.168.2.11:5060> -> 192.168.2.21:5060
> <http://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 <mailto:sip%3A19498859944 at 192.168.2.30>
> > <mailto:sip%3A19498859944 at 192.168.2.30
> <mailto: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 <mailto:sip%3A19498859944 at 192.168.2.30>
> > <mailto:sip%3A19498859944 at 192.168.2.30
> <mailto: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>
> > <mailto: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>
> <http://192.168.1.11:5060> ->
> > 192.168.1.13:5060 <http://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>
> > <mailto:sip%3A%2B19496794816 at 63.110.102.239
> <mailto: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>
> <http://192.168.1.13:5060> ->
> > 192.168.1.11:5060 <http://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>
> <http://192.168.1.13:5060> ->
> > 192.168.1.11:5060 <http://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>
> > <mailto:sip%3A19498858961 at 192.168.1.3
> <mailto: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
> <mailto:sip%3A%2B19496794816 at 63.110.102.239>
> > <mailto:sip%3A%2B19496794816 at 63.110.102.239
> <mailto: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 <mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro <http://www.voice-system.ro>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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