Forum Discussion

rolf's avatar
rolf
Icon for Cirrus rankCirrus
Aug 03, 2014

Source port of SIP UDP request gets translated regardless of source port setting 'preserve strict'

Hi Guys,

 

I configured a SIP (UDP) service on a 11.5.1 HF3 LTM at a customer site. A SIP profile is bound to the SIP Virtual Service. The LTM ist set up in the L3 Path. Most of the VS configuration ist default.

 

What I see is, that the LTM translates the source port on the traffic from the LTM to the SIP server. The behaviour does not change if I configure 'preserve strict' on the source port setting in the VS:

 

09:47:50.418275 IP 1.1.1.1.sip > 1.1.2.1.sip: SIP, length: 452 (client to SIP VS on LTM)

 

09:47:50.418560 IP 1.1.1.1.25350 > 1.1.3.1.sip: SIP, length: 547 (forwarded request to SIP server)

 

09:47:50.424877 IP 1.1.3.1.sip > 1.1.1.1.25350: SIP, length: 378 (response from SIP server)

 

09:47:50.424927 IP 1.1.2.1.sip > 1.1.1.1.sip: SIP, length: 277 (response form LTM VS to client)

 

Any ideas?

 

Thanks, Rolf

 

application delivery
deployment
LTM
sip
source port translation

3 Replies

Sort By
  • Vsevolod_Petrov's avatar
    Vsevolod_Petrov
    Icon for Cirrostratus rankCirrostratus
    Jul 02, 2015

    There's a note in the official SIP Deployment Guide available at https://www.f5.com/pdf/deployment-guides/load-balancing-sip-dg.pdf that states the following: 

    One example of a scenario this guide would not cover is for SIP UDP where
clients and servers always use a source and destination port of 5060.
Contact F5 technical support for configuration guidance for such use cases.

    Did you try to contact?

    Setting Idle Timeout to Immediate helps, but you loose packet in reverse direction and auto-lasthop also becomes unavailable.
  • SyedNazir_20946's avatar
    SyedNazir_20946
    Historic F5 Account
    Aug 21, 2015

    Hi All,

    This is a standard behavior of F5 where there is an already existing server side connection with port 5060 associated with the another client. Then for the new client the NATTED port will be always random.

    ClientA:

     1.2.3.4:5060 --> 1.1.2.1:5060 
 1.1.1.1:5060 --> 1.1.3.1:5060

    ClientB:

    4.3.2.1:5060 --> 1.1.2.1:5060    
1.1.1.1:23010 --> 1.1.3.1:5060

    Irrespective of these change in port there should not be any issue in message routing back to client from F5.

    Since the server side connection mapping with source port 5060 is already used by ClientA any other client that comes later will be assigned the natted port randomly so that F5 can able to route the request back to the correct client based on connection mapping.

    If there are requirements to use always source port 5060 with the server it is not possible with just plain configuration we need a combination of following

    1) SIP one connect profile similar to http one connect(* conditions apply)

    a) N no of client side connection entry
b) A pool of server side connection

    2) SIP session persistence based on unique values likes callid, ClientIP:Port etc

    3) iRule to route message from server to client based on SIP persistence records.

    You can look something called as Message Routing function in 11.6.0 if that solves the purpose.

    -- Syed Nazir