SRX Services Gateway
Reply
Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 789
Registered: ‎07-26-2008
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Looking at the trace, it seems like we are seeing some application drop errors for SIP when traffic is coming from the provider to the SRX:

 

Aug  4 13:04:51 13:04:50.1161249:CID-0:RT:<providerSIP.247.103/5060->publicIP.143.3/18138;17> matched filter provider:
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:packet [365] ipid = 0, @423f7c9e
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423f7b00, rtbl_idx = 20416
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow process pak fast ifl 69 in_ifp fe-0/0/2.0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: find flow: table 0x4d6bc358, hash 45133(0xffff), sa providerSIP.247.103, da publicIP.143.3, sp 5060, dp 18138, proto 17, tok 448
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_create_session
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:RM populated xlate info for nsp2: local.12.1/5060->providerSIP.247.103/5060out_ifp = fe-0/0/4.0, out_tunnel = 0x0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_in_dst_nat: in <fe-0/0/2.0>, out <fe-0/0/4.0> dst_adr publicIP.143.3, sp 5060, dp 18138
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_in_dst_nat: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_rule_dst_xlate: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_routing: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_policy_search: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_reverse_mip: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_src_xlate: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_get_out_ifp: bypassed by RM
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:is_loop_pak: No loop: on ifp: fe-0/0/4.0, addr: local.12.1, rtt_idx:0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:policy is NULL (wx/pim scenario)
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_interest_check: app_id 0, policy 10, app_svc_en 0, flags 0x2. not interested
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_interest_check: app_id 1, policy 10, app_svc_en 0, flags 0x2. not interested
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_interest_check: app_id 2, policy 10, app_svc_en 0, flags 0x2. interested
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_do_sm_interest_check: natp 0x4ce178d0, app_id 63, ALG & SZ vectors set, SZ 0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: service lookup identified service 63.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_final_check: in <fe-0/0/2.0>, out <fe-0/0/4.0>
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_first_final_check: flow_set_xlate_vector.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: existing vector list 1080-446c8ae8.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: Session (id:52264) created for first pak 1080
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow_first_install_session======> 0x4ce178d0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: nsp 0x4ce178d0, nsp2 0x4ce1793c
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: make_nsp_ready_no_resolve()
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: route lookup: dest-ip providerSIP.247.103 orig ifp fe-0/0/2.0 output_ifp fe-0/0/2.0 orig-zone 7 out-zone 7 vsd 0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: route to publicIP.143.6
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:Installing c2s NP session wing
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:Installing s2c NP session wing
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sm_flow_notify_session_creation: app_id 2, flags 0x0, ifl_in 69, zone_in 7, ifl_out 71, zone_out 8
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow got session.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: flow fast tcp/udp session id 52264
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_alg_vector(): VECTOR: pak_ptr(0x3fdedc70.0x423f7b00): natp(0x4ce178d0).nsp(0x4ce178d0): app_id: 63, flag: 0x00000003.
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip:
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip: ------------------sip vector entry -----------------
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... packet received (providerSIP.247.103 -> publicIP.143.3) len=365
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... udp packet received (5060 -> 18138) len=337, cksum=0x5854
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call Dialog dlg0x457c69cc received provisional 100 ((null))
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call ALG action 2
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg/call Dialog dlg0x457c8aa4 sending provisional 100 ((null))
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip_alg..... packet sent (providerSIP.247.103 -> publicIP.143.3) len=472
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:sip: sip alg vector finish successfully ret = 0
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT:flow_alg_vector: status -1
Aug 4 13:04:51 13:04:50.1161249:CID-0:RT: packet dropped, sm application error

 

But I also see some H323 packets seeing TTL expired error. I thought you are using SIP?

 

Aug  4 13:04:51 13:04:50.1177290:CID-0:RT:<local.10.21/3152->local.12.1/1720;6> matched filter avaya:
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT:packet [40] ipid = 1743, @423e861e
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423e8480, rtbl_idx = 20416
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: flow process pak fast ifl 70 in_ifp fe-0/0/3.0
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: fe-0/0/3.0:local.10.21/3152->local.12.1/1720, tcp, flag 10
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: find flow: table 0x4d6bc358, hash 23999(0xffff), sa local.10.21, da local.12.1, sp 3152, dp 1720, proto 6, tok 384
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: flow got session.
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: flow session id 51516
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT:flow_asp_vector tcp_proxy_inbound_handler, returned the packet m 0x423e8480, 13.
Aug 4 13:04:51 13:04:50.1177290:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc 5)
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: encap vector
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: no more encapping needed
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: **** pak processing end.
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT:flow_first_complete_session: Sending icmp for ttl expiry
Aug 4 13:04:51 13:04:50.1600294:CID-0:RT: packet dropped, ttl expiry
****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
PowerRanger
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

You right, we use H323 in the LAN but SIP for outside.

 

What cause the application errors SIP? How could we see from the SRX some SIP packets such as its format:

 

 

Sample SIP INVITE Message from a SIP Service Provider to the Avaya SES: 
 
INVITE sip:6023334000@150.100.100.130 SIP/2.0 
Via:SIP/2.0/UDP 20.1.1.54;branch=z9hG4bK-xyz.20.1.1.54-V5060-0-951040837 
From:<sip:7336731730@20.1.1.54;user=phone>;tag=26074514-1178723120777- 
To:"ABC Corp"<sip:6023334000@150.100.100.130> 
Call-ID:BW110520777090507561442054@20.1.1.54 
CSeq:951040837 INVITE 
Contact:<sip:20.1.1.54:5060> 
Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY 
Supported:100rel 
Accept:multipart/mixed,application/sdp 
Max-Forwards:10 
Content-Type:application/sdp 
Content-Length:285 
 
v=0 
o=xyz 57542641 1 IN IP4 20.211.120.15 
s=- 
c=IN IP4 20.211.120.15 
t=0 0 
m=audio 17040 RTP/AVP 18 0 8 101 
c=IN IP4 20.211.120.15 
a=rtpmap:18 G729/8000 
a=fmtp:18 annexb=no 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-16

 

 

Contributor
PowerRanger
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hi guys,

 

I figured out why the inbound didn't work.

 

I had a src nat(for outbound) and dest nat(inbound) with the publicIpAvaya.143.1 . I use the publicIP.143.3 for surfing which is affected to my fe-0/0/2.0.

 

When inbound call, i found via show log sip-trace | matchh "publicIP.143." the line below:

 

Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:Failed to get real out-ifp for .local..0, dst:public.143.1, in vr_id: 0

Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:  Output ifp is self but it is not for self packet and the IP(public.143.1) is in Source NAT pool, we don't create the session.
Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:  packet dropped, self ip in src nat pool.

Aug  5 23:12:08 23:12:07.1108010:CID-0:RT:  flow didn't create session, code=-1.

 

So I change src and dest for avaya to a static nat including a proxy-arp pointing to the avayaIP and then god it works !!!

 

 

Contributor
jmartinez
Posts: 45
Registered: ‎09-28-2009
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hello,

 

I have the same problem, can you post the last configuration you did?

 

Thanks in advance.

 

Regards.

Contributor
PowerRanger
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Hi,

 

My config changed to a cluster configuration so i give it from my mind :smileyhappy: 

 

interfaces {
fe-0/0/0 {
        unit 0 {
            family inet {
                address pubic.143.2/29;
            }
        }
    }
}
fe-0/0/1 {
        unit 0 {
            family inet {
                address local.12.254/24; # connect to the same vlan than server avaya(dmz)
            }
        }
    }
fe-0/0/2 {
        unit 0 {
            family inet {
                address local.11.9/29; #interconnect with the switch
            }
        }
    }
}
security{
   nat {
          static {
    rule-set avaya-SIPTrunk-nat {
        from zone untrust;
        rule publicAvayaNat {
            match {
                destination-address public.143.1/32;
            }
            then {
                static-nat prefix local.12.1/32;
            }
        }
    }
}
proxy-arp {
    interface fe-0/0/0.0 {
        address {
            public.143.1/32;
        }
    }
}

   }
   zones {
        security-zone trust {
           address-book {
                address address httpAvaya local.14.3/32; # http server for update ip phone and so
           }
           host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                fe-0/0/2.0;
            }
        security-zone untrust {
           host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                fe-0/0/0.0;
            }
         security-zone dmz{
           address-book {
                address dmz_int local.12.0/24;
                address server-avaya local.12.1/32; #main IP for SIP provider
                address avayaServices local.12.0/29;
            }

           host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                fe-0/0/1.0;
            }
      policies {
          from-zone trust to-zone dmz {
                    policy voice-to-avaya {
                match {
                    source-address trust_voice; # voice vlan to avaya servers
                    destination-address avayaServices;
                    application any;
                }
                then {
                    permit;
                }
            }
            policy httpAvaya-to-avayaServices {
                match {
                    source-address httpAvaya;
                    destination-address avayaServices;
                    application any;
                }
                then {
                    permit; # for administration of avaya
                }
            }
            from-zone dmz to-zone trust {
        policy dmzAvaya-to-Dect {
            match {
                source-address server-avaya;
                destination-address trust_voice;
                application any;
            }
            then {
                permit; # Avaya server needs to connect to DECT
            }
        }
    }

          }
      }
}

 

Let me know if there is something missing. Good luck

Contributor
jmartinez
Posts: 45
Registered: ‎09-28-2009
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

Thanks!

 

I'll go to test!

 

Regards

Contributor
PowerRanger
Posts: 62
Registered: ‎07-08-2010
0

Re: SIP Trunk Provider <-> SRX <-> AVAYA Communication Provider

HI Jmartinez,

 

Be carefull, i have some troubles every night. VOIP doesn't work. 

 

I use EX4200 in virtual chassis, Avaya G450 with S8300 and 2 SRX240H in cluster.

Ip Phone are on voice vlan, they pass through the SRX (that manage the DMZ vlan) to register to Avaya (dmz vlan)

 

What about yours?

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.