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

[Jai Rangi]

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/7e023a41/attachment.htm