[OpenSIPS-Users] Issue with call routing due to maddr

Jai Rangi jprangi at didforsale.com
Mon Dec 14 04:20:18 CET 2009 

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: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>
;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>;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> 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: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>
> >;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 -> 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 -> 192.168.1.11:5060
> *
> *INVITE sip:19498858961 at 192.168.1.3 <sip%3A19498858961 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>
> >;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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20091213/f4b6ea88/attachment-0001.htm

More information about the Users mailing list