Issues with ACK with 2 NIC opensips + GW behind NAT

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with ACK with 2 NIC opensips + GW behind NAT

oso che bol
Dear Bogdan & All,

My network scenario:

SIP: UA 1 (behind NAT) ---- Nic1 (public) Opensips/Rtpproxy --- Nic 2 (private) ---- SIP GW (private) --- UA 2 (behind NAT)
RTP: UA1 ------------------------------------------ RTPPROXY ---------------------------------------------------------------------UA2

My Usecase:
UA1 dial UA2 (which is registered to SIP GW), Opensips do not have UA2 in DB. Opensips check usrloc and see UA2 is not in its DB, it force route to SIP GW, which is the same internal Lan with Opensips (Nic2).

Expected Result:
- When Opensips go to Route 2 (not found user route), it invoke INVITE, NAT processing and go to on_reply_route[2], it expect ACK. But it confirmed in logs console that "It's late for local ACK", "no transaction found"

Bellow is my attach configure and logs for more clear about description:

Thanks and Regards,
-LN

========Configuration==============
debug=4
log_stderror=yes
log_facility=LOG_LOCAL0

fork=yes
children=4
port=5060
listen=udp:OPENSIP_PUBLIC_IP:5060
listen=udp:OPENSIP_PRIVATE_IP:5060

####### Modules Section ########

route {
    log(1, "----------------------------------------------------------------------------------\r\n");
    log(1, "HTK: ENTER MAIN LOOP\r\n");
    log(1, "----------------------------------------------------------------------------------\r\n");
    #---------
    #Sanity Check
    #-------------
    if (!mf_process_maxfwd_header("10")) {
        sl_send_reply("483","Too Many Hops");
        exit;
    };
    if ( msg:len >= max_len ) {
        sl_send_reply("513", "Message too big");
        exit;
    }
  
    #--------------------------------------
    #Record-Route all messages
    #-- to make sure subsequent messages will go through our proxy
    #--------------------------------------
    if (method!="REGISTER") {
        record_route();
    }
  
    #-------------------------------
    # Loose-Route
    #-------------------------------
#    if (loose_route()) {
#        append_hf("P-hint: HTK: rr-enforced\r\n");
#        route(1);
#        exit;
#    }
  
  
#20090504-0232
# Comment Loose_route(), add saud ay
# http://www.voipembedded.com/resources/openser_cr.cfg
    if (has_totag()) {
        # sequential request withing a dialog should
        # take the path determined by record-routing
        if (loose_route()) {
            route(1);
        } else {
            if ( is_method("ACK") ) {
                if ( t_check_trans() ) {
                    # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server
                    t_relay();
                    exit;
                } else {
                    # ACK without matching transaction ... ignore and discard.\n");
                    xlog("L_WARN", "[$mi] discarding ACK\n");
                    log(1, "HTK: ------------Discarding ACK ---------------\r\n");
                    exit;
                };
            };
            sl_send_reply("404","Not here");
        };
        exit;
    };

    #initial requests

    # CANCEL processing
    if (is_method("CANCEL")) {
        if (t_check_trans())
            t_relay();
        exit;
    };

    t_check_trans();

#End     #20090504-0232
  
    #--------------------------------
    # uri != myself
    #--------------------------------
    if (uri!=myself) {
        append_hf("P-hint: HTK: uri!=myself  ----- Outbound---------------------------------------\r\n");
        log(1, "HTK: enter route 1 ----------------\r\n");
        route(1);
        exit;
    }
    #--------------------------------
    # uri==myself
    #--------------------------------
    if (uri==myself) {
        log(1, "HTK --- ENTER uri==myself ---------------------------------\r\n");
        if (method=="REGISTER") {
            if (nat_uac_test("19")) {
                setbflag(6);
                force_rport();
                fix_nated_register();
          
            }
            sl_send_reply("100", "HTK: Trying\r\n");
            #AUTHENTICATE
            if(!www_authorize("OPENSIP_PUBLIC_IP", "subscriber")) {
                www_challenge("OPENSIP_PUBLIC_IP", "0");
                exit;
            }
            consume_credentials();
          
            save("location");
            exit;
      
        }

      
        lookup("aliases");
        if (uri!=myself) {
            append_hf("P-hint: HTK: LOOKUP ALIASES --- outbound alias\r\n");
            route(1);
            exit;
        }
      
        if (!lookup("location")) {
            log(1, "HTK - User NOT FOUND - change to Route(2)---------------------------\r\n");
            route(2);
            exit;
        }

    } #End uri==myself
  
          
    if (method=="INVITE") {
        t_on_failure("1");
    } else if (method=="BYE" || method=="CANCEL") {
        unforce_rtp_proxy();
    }
  
    #---------------------------------------------------------------------
    # LOOSE_ROUTE - INVITE - FORCE_RTP_PROXY
    #-----------------------------------------------------------------------
    if (loose_route()) {
        if (method=="INVITE" || method=="ACK") {
            append_hf("P-hint: HTK - LOOSE ROUTE - Relay re-INVITE + FORCE_RTP_PROXY\r\n");
            force_rtp_proxy();
        }

        t_relay();
        exit;
    }
  
    #-----------------------------------------------------------------------
    #NAT - fix_nated_contact()
    #------------------------------------------------------------------------
    if (nat_uac_test("19") && !search("^Record-Route:")) {
        append_hf("P-hint: HTK: Fix nated contact\r\n");
        force_rport();
        fix_nated_contact();
    }
  
    if (method=="INVITE") {
        append_hf("P-hint: HTK: INVITE go to on_reply_route[1]\r\n");
        t_on_reply("1");
    }
  
    if (method=="INVITE" || method=="ACK") {
        append_hf("P-hint: INVITE||ACK + FORCE_RTP_PROXY\r\n");
        force_rtp_proxy();
    }
  
    if (!t_relay()) {
        append_hf("P-hint: INVITE||ACK - UNFORCE_RTP_PROXY\r\n");
        if (method=="INVITE" || method=="ACK") {
            unforce_rtp_proxy();
        }
        sl_reply_error();
    }

    append_hf("P-hint: HTK: usrloc applied\r\n");
}

route[1] {
  
    append_hf("P-hint: Route[1] Processing\r\n");
    if (!t_relay()) {
        sl_reply_error();
    }
}


onreply_route[1] {
    append_hf("P-hint: HTK: On_reply_route[1] processing\r\n");
    if (status=~"(180)|(183)|2[0-9][0-9]") {
        if (nat_uac_test("1")) {
            fix_nated_contact();
        }
        force_rtp_proxy();
    }
}

failure_route[1] {
    #unforce_rtp_proxy();
    exit;
}

route[2] {
    log(1, "HTK - ENTER route(2)-------------------\r\n");

    if ($ru=~"^sip:88059*") {
        log(1, "P-hint: HTK - match 880593---------------------------------\r\n");
        rewritehostport("SIPGW_PRIVATE_IP:5060");
        log(1, "P-hint: HTK - match 880593---------RewriteHostport------------------------\r\n");
      
        #200905032301
        #append_branch();
    }
    #200905032306 - comment out force_send_socket
    force_send_socket(udp:OPENSIP_PRIVATE_IP:5060);  

    if (loose_route()) {
        if (method=="INVITE" || method=="ACK") {
            append_hf("P-hint: HTK - ROUTE2 ---- LOOSE ROUTE - Relay re-INVITE + FORCE_RTP_PROXY\r\n");
            force_rtp_proxy();
        }
        t_relay();
        exit;
    }

    #-----------------------------------------------------------------------
    #NAT - fix_nated_contact()
    #------------------------------------------------------------------------
    if (nat_uac_test("19") && !search("^Record-Route:")) {
        append_hf("P-hint: HTK: ROUTE 2 --- Fix nated contact ---------------\r\n");
        force_rport();
        fix_nated_contact();
    }
  
    if (method=="INVITE") {
        append_hf("P-hint: HTK: ROUTE2 ------------- INVITE go to on_reply_route[2] ---------------\r\n");
        sl_send_reply("100", "HTK: ROUTE2 Trying\r\n");
        t_on_reply("2");
    }
  
    if (method=="INVITE" || method=="ACK") {
        append_hf("P-hint: ROUTE2 ------------ INVITE||ACK + FORCE_RTP_PROXY ---------------\r\n");
        force_rtp_proxy();
    }
  
    if (!t_relay()) {
        append_hf("P-hint: INVITE||ACK - UNFORCE_RTP_PROXY\r\n");
        #if (method=="INVITE" || method=="ACK") {
        #    unforce_rtp_proxy();
        #}
        sl_reply_error();
    }

    log(1, "HTK ---- OUT ROUTE 2------------------------------\r\n");
    exit;
}

onreply_route[2] {
    append_hf("P-hint: HTK: On_reply_route[2] processing\r\n");
    #20090504-1313
    if (status=~"(180)|(183)|2[0-9][0-9]") {
        if (nat_uac_test("1")) {
            fix_nated_contact();
        }
        force_rtp_proxy();
    }
  
}

================ END CONFIGURATIOON

##################LOGs#####################
20090504_ack_01.txt
interface: eth0 (172.30.40.0/255.255.255.0)
filter: (ip or ip6) and ( port 5060 )

U OPENSIP_PRIVATE_IP:5060 -> SIPGW_PRIVATE_IP:5060
INVITE sip:880593@SIPGW_PRIVATE_IP:5060 SIP/2.0.
Record-Route: <sip:OPENSIP_PRIVATE_IP;r2=on;lr=on;ftag=4835a45a>.
Record-Route: <sip:OPENSIP_PUBLIC_IP;r2=on;lr=on;ftag=4835a45a>.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Max-Forwards: 69.
Contact: <sip:2501000@118.68.253.68:18740>.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
Call-ID: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
CSeq: 1 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Content-Type: application/sdp.
User-Agent: X-Lite release 1100l stamp 47546.
Content-Length: 671.
P-hint: HTK: ROUTE 2 --- Fix nated contact ---------------.
P-hint: HTK: ROUTE2 ------------- INVITE go to on_reply_route[2] ---------------.
P-hint: ROUTE2 ------------ INVITE||ACK + FORCE_RTP_PROXY ---------------.
.
v=0.
o=- 0 2 IN IP4 192.168.1.33.
s=CounterPath X-Lite 3.0.
c=IN IP4 RTPPROXY_PUBLIC_IP.
t=0 0.
m=audio 46144 RTP/AVP 107 119 100 106 0 105 98 8 3 101.
a=alt:1 1 : NrtWWMn2 071Xungd 192.168.1.33 23650.
a=fmtp:101 0-15.
a=rtpmap:107 BV32/16000.
a=rtpmap:119 BV32-FEC/16000.
a=rtpmap:100 SPEEX/16000.
a=rtpmap:106 SPEEX-FEC/16000.
a=rtpmap:105 SPEEX-FEC/8000.
a=rtpmap:98 iLBC/8000.
a=rtpmap:101 telephone-event/8000.
a=sendrecv.
m=video 40440 RTP/AVP 115 34.
a=alt:1 1 : nV/r+DfM sMsjjQna 192

U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 100 Trying.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Contact: sip:SIPGW_PRIVATE_IP.
Content-Length: 0.
.


U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 200 OK.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>;tag=21241.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Content-Type: application/sdp.
Content-Length: 324.
Date: Mon, 04 May 2009 06:11:08 GMT.
Contact: sip:SIPGW_PRIVATE_IP.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING.
User-Agent: SIPGWNAME (WinNT).
Accept-Language: .
.
v=0.
o=SIPGWNAME 1 1 IN IP4 SIPGW_PRIVATE_IP.
s=SIPGWNAME - call.
c=IN IP4 SIPGW_PRIVATE_IP.
t=0 0.
m=audio 17000 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=maxptime:30.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
m=video 17002 RTP/AVP 34.
a=rtpmap:34 h263/90000.
a=fmtp:34 QCIF=1/MaxBR=655.
a=framerate:10.


U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 200 OK.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>;tag=21241.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Content-Type: application/sdp.
Content-Length: 324.
Date: Mon, 04 May 2009 06:11:08 GMT.
Contact: sip:SIPGW_PRIVATE_IP.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING.
User-Agent: SIPGWNAME (WinNT).
Accept-Language: .
.
v=0.
o=SIPGWNAME 1 1 IN IP4 SIPGW_PRIVATE_IP.
s=SIPGWNAME - call.
c=IN IP4 SIPGW_PRIVATE_IP.
t=0 0.
m=audio 17000 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=maxptime:30.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
m=video 17002 RTP/AVP 34.
a=rtpmap:34 h263/90000.
a=fmtp:34 QCIF=1/MaxBR=655.
a=framerate:10.


U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 200 OK.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>;tag=21241.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Content-Type: application/sdp.
Content-Length: 324.
Date: Mon, 04 May 2009 06:11:08 GMT.
Contact: sip:SIPGW_PRIVATE_IP.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING.
User-Agent: SIPGWNAME (WinNT).
Accept-Language: .
.
v=0.
o=SIPGWNAME 1 1 IN IP4 SIPGW_PRIVATE_IP.
s=SIPGWNAME - call.
c=IN IP4 SIPGW_PRIVATE_IP.
t=0 0.
m=audio 17000 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=maxptime:30.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
m=video 17002 RTP/AVP 34.
a=rtpmap:34 h263/90000.
a=fmtp:34 QCIF=1/MaxBR=655.
a=framerate:10.


U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 200 OK.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>;tag=21241.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Content-Type: application/sdp.
Content-Length: 324.
Date: Mon, 04 May 2009 06:11:08 GMT.
Contact: sip:SIPGW_PRIVATE_IP.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING.
User-Agent: SIPGWNAME (WinNT).
Accept-Language: .
.
v=0.
o=SIPGWNAME 1 1 IN IP4 SIPGW_PRIVATE_IP.
s=SIPGWNAME - call.
c=IN IP4 SIPGW_PRIVATE_IP.
t=0 0.
m=audio 17000 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=maxptime:30.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
m=video 17002 RTP/AVP 34.
a=rtpmap:34 h263/90000.
a=fmtp:34 QCIF=1/MaxBR=655.
a=framerate:10.


U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 200 OK.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>;tag=21241.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Content-Type: application/sdp.
Content-Length: 324.
Date: Mon, 04 May 2009 06:11:08 GMT.
Contact: sip:SIPGW_PRIVATE_IP.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING.
User-Agent: SIPGWNAME (WinNT).
Accept-Language: .
.
v=0.
o=SIPGWNAME 1 1 IN IP4 SIPGW_PRIVATE_IP.
s=SIPGWNAME - call.
c=IN IP4 SIPGW_PRIVATE_IP.
t=0 0.
m=audio 17000 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=maxptime:30.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
m=video 17002 RTP/AVP 34.
a=rtpmap:34 h263/90000.
a=fmtp:34 QCIF=1/MaxBR=655.
a=framerate:10.


U SIPGW_PRIVATE_IP:5060 -> OPENSIP_PRIVATE_IP:5060
SIP/2.0 200 OK.
From: "2501000"<sip:2501000@OPENSIP_PUBLIC_IP>;tag=4835a45a.
To: "880593"<sip:880593@OPENSIP_PUBLIC_IP>;tag=21241.
Call-Id: NTc4ZmJiYzFkM2MzZjI1YWE2MmY0OTA1ZDYxOTY1YmY..
Cseq: 1 INVITE.
Via: SIP/2.0/UDP OPENSIP_PRIVATE_IP;branch=z9hG4bK5184.3c89a5b.0.
Via: SIP/2.0/UDP 192.168.1.33:11968;received=118.68.253.68;branch=z9hG4bK-d8754z-b6322657453ffa34-1---d8754z-;rport=18740.
Content-Type: application/sdp.
Content-Length: 324.
Date: Mon, 04 May 2009 06:11:08 GMT.
Contact: sip:SIPGW_PRIVATE_IP.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING.
User-Agent: SIPGWNAME (WinNT).
Accept-Language: .
.
v=0.
o=SIPGWNAME 1 1 IN IP4 SIPGW_PRIVATE_IP.
s=SIPGWNAME - call.
c=IN IP4 SIPGW_PRIVATE_IP.
t=0 0.
m=audio 17000 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=maxptime:30.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
m=video 17002 RTP/AVP 34.
a=rtpmap:34 h263/90000.
a=fmtp:34 QCIF=1/MaxBR=655.
a=framerate:10.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

Iñaki Baz Castillo
2009/5/4 oso che bol <[hidden email]>:
> Expected Result:
> - When Opensips go to Route 2 (not found user route), it invoke INVITE, NAT
> processing and go to on_reply_route[2], it expect ACK. But it confirmed in
> logs console that "It's late for local ACK", "no transaction found"

As you can see in the SIP flow capture, OpenSIPS is not sending the
200 upstream to the caller, so GW retransmits it waiting for the ACK.
You should investigate why OpenSIPS os not relaying the 200 to the caller.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

oso che bol
Hi IBC, bogdan,

I capture on UA 1 (caller)
1. Invite from caller send to opensips
2. opensips send to caller 100 Give a try
3. Opensips send 200 OK with SDP to Caller
4. RTP setup between Caller and RTPPRoxy
5. Caller send ACK to SIP_GW_PRIVATE_IP (that break here )

Could you please explain why ACK do not go through Opensips?
Thanks,
-LN

On Mon, May 4, 2009 at 5:26 PM, Iñaki Baz Castillo <[hidden email]> wrote:
2009/5/4 oso che bol <[hidden email]>:
> Expected Result:
> - When Opensips go to Route 2 (not found user route), it invoke INVITE, NAT
> processing and go to on_reply_route[2], it expect ACK. But it confirmed in
> logs console that "It's late for local ACK", "no transaction found"

As you can see in the SIP flow capture, OpenSIPS is not sending the
200 upstream to the caller, so GW retransmits it waiting for the ACK.
You should investigate why OpenSIPS os not relaying the 200 to the caller.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

Iñaki Baz Castillo
2009/5/4 oso che bol <[hidden email]>:

> Hi IBC, bogdan,
>
> I capture on UA 1 (caller)
> 1. Invite from caller send to opensips
> 2. opensips send to caller 100 Give a try
> 3. Opensips send 200 OK with SDP to Caller
> 4. RTP setup between Caller and RTPPRoxy
> 5. Caller send ACK to SIP_GW_PRIVATE_IP (that break here )
>
> Could you please explain why ACK do not go through Opensips?
> Thanks,

First of all, I don't see the 200 arriving to caller in the SIP flow
you pasted (probably because you just did the capture for one
interface).

Anyway I see a *bug* in the 200 sent by the GW: It doesn't contain
"Route" header !!!
It should include it since the INVITE arriving to it did contain "Record-Route".

So, the 200 arrives to the caller with NO "Route" headers and the
following Contact:
  Contact: sip:SIPGW_PRIVATE_IP.

So, the caller would sent the ACK *directly* to SIPGW_PRIVATE_IP, and
of course, it's unreachable from its LAN.

The problem is in the GW which doesn't add "Route" header to the 200.
This "Route" should mirror the value of the received "Record-Route"
headers in the first INVITE.

PD:  Please, *don't* add Bogdan in the CC of all your mails, he *does*
read this maillist. Just add the maillist as recipient of your
questions.

Regards.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

oso che bol
Dear IBC,

with the bug "No Route" in 200 sent by GW, there are any workaround on opensips to fix that? We could force ACK go through opensips?

Thanks,
-LN

On Mon, May 4, 2009 at 6:19 PM, Iñaki Baz Castillo <[hidden email]> wrote:
2009/5/4 oso che bol <[hidden email]>:
> Hi IBC, bogdan,
>
> I capture on UA 1 (caller)
> 1. Invite from caller send to opensips
> 2. opensips send to caller 100 Give a try
> 3. Opensips send 200 OK with SDP to Caller
> 4. RTP setup between Caller and RTPPRoxy
> 5. Caller send ACK to SIP_GW_PRIVATE_IP (that break here )
>
> Could you please explain why ACK do not go through Opensips?
> Thanks,

First of all, I don't see the 200 arriving to caller in the SIP flow
you pasted (probably because you just did the capture for one
interface).

Anyway I see a *bug* in the 200 sent by the GW: It doesn't contain
"Route" header !!!
It should include it since the INVITE arriving to it did contain "Record-Route".

So, the 200 arrives to the caller with NO "Route" headers and the
following Contact:
 Contact: sip:SIPGW_PRIVATE_IP.

So, the caller would sent the ACK *directly* to SIPGW_PRIVATE_IP, and
of course, it's unreachable from its LAN.

The problem is in the GW which doesn't add "Route" header to the 200.
This "Route" should mirror the value of the received "Record-Route"
headers in the first INVITE.

PD:  Please, *don't* add Bogdan in the CC of all your mails, he *does*
read this maillist. Just add the maillist as recipient of your
questions.

Regards.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

Iñaki Baz Castillo
2009/5/4 oso che bol <[hidden email]>:
> Dear IBC,
>
> with the bug "No Route" in 200 sent by GW, there are any workaround on
> opensips to fix that? We could force ACK go through opensips?

A really *dirty* workaround would be:

In onreply_route[] for replies from GW, add the "Route" header to the
200 Ok (look for a funtion which does it in "tm" module).

But this is really dirty.



--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

oso che bol
Hi IBC,

Do you mean function record_route_preset() ?

Thanks,
-LN

On Mon, May 4, 2009 at 11:36 PM, Iñaki Baz Castillo <[hidden email]> wrote:
2009/5/4 oso che bol <[hidden email]>:
> Dear IBC,
>
> with the bug "No Route" in 200 sent by GW, there are any workaround on
> opensips to fix that? We could force ACK go through opensips?

A really *dirty* workaround would be:

In onreply_route[] for replies from GW, add the "Route" header to the
200 Ok (look for a funtion which does it in "tm" module).

But this is really dirty.



--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

Iñaki Baz Castillo
2009/5/5 oso che bol <[hidden email]>:
> Do you mean function record_route_preset() ?

No, that function add a Record-Route header with custom value in a
*request*. Your problem is that the UAS (GW) is *not* mirroring the
Record-Route in the "200 OK" (it's a dirty bug in your UAS).
So the only solution (but really dirty) is adding the Record-Route in
the reply (in onreply_route[]). For that, you need a function of *tm*
module which allows adding custom headers to the reply.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

oso che bol
Hi Ibc,

you mean this one :

append_hf(txt, hdr)

Thanks,
-LN
On Tue, May 5, 2009 at 4:25 PM, Iñaki Baz Castillo <[hidden email]> wrote:
2009/5/5 oso che bol <[hidden email]>:
> Do you mean function record_route_preset() ?

No, that function add a Record-Route header with custom value in a
*request*. Your problem is that the UAS (GW) is *not* mirroring the
Record-Route in the "200 OK" (it's a dirty bug in your UAS).
So the only solution (but really dirty) is adding the Record-Route in
the reply (in onreply_route[]). For that, you need a function of *tm*
module which allows adding custom headers to the reply.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with ACK with 2 NIC opensips + GW behind NAT

Iñaki Baz Castillo
2009/5/5 oso che bol <[hidden email]>:
> Hi Ibc,
>
> you mean this one :
>
> append_hf(txt, hdr)

Yes, it's in TEXOPS module (my fault). Some time ago, AFAIR, that
function just worked for requests and there was a specific function to
add headers in responses. Now it's better :)

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users