In this section:

Related articles:

Overview

The SBC Core supports TCP (Transmission Control Protocol) for peering, enterprise, and access configurations.

In an Access scenario, connections are on a per-subscriber-registration basis. The SBC keeps track of subscriber-initiated TCP “flow” beginning with when the endpoint registers, and uses it to forward any requests to the subscriber. The connection stays up as long as the subscriber is registered with the SBC .

A connection is deleted when the flow cannot reach the subscriber (example a broken TCP connection), when the connection is replaced by a newer one through successful modification, or when the registration is deleted.

For Peering, there are typically two connections, one for each direction. Connections to the peers are maintained and reused for all requests to the peer, independent of calls. The SBC can accept multiple connections from the same remote peer.

The SBC also supports TCP Fallback. When enabled, the following functionality is available:

  • Reject incoming INVITE over UDP with PDU size greater than allowed configured size if enabled on ingress Trunk Group. However, the same INVITE is supported by the SBC, if it is received over TCP.
  • Send out INVITE over TCP if outgoing INVITE size is more than the configured size enabled on the egress Trunk Group.

When TCP fallback feature is enabled it overrides any other configuration related to transport preference.

When a UE sends REGISTER request to the SBC over a TCP connection and the registration is successful, the TCP connection is present between UE and SBC for the life of the registration. If the registration becomes inactive, the SBC relies on the UE to clear (close) the TCP connection between the two.

The SIP Trunk Group flag clearTcpConnectionsforRegistration allows the SBC to clear the TCP connection between the UE and SBC once the registration becomes inactive. The SBC closes the TCP connection even when there are user agent failure registrations.

TCP Keep-alive Timer 

The SBC Core supports configuring TCP Keep-alive timer settings for SIP Trunk Group and Signaling Port configurations. These parameters enable the SBC to send out TCP Keep-alive packets to peer devices (for example, registered SIP phones) at configured intervals. 

Examples

SIP Trunk Group Configuration

The following example sets the NAT keep-alive timer to 200 seconds for SIP over TCP.

% set addressContext default zone ZONE_IAD sipTrunkGroup SBX10_IAD services natTraversal tcpKeepaliveTimer 200
% commit

% show addressContext default zone ZONE_IAD sipTrunkGroup SBX10_IAD services
natTraversal {
    tcpKeepaliveTimer 200;
}  

For configuration details, refer to SIP Trunk Group - Services (EMA) or SIP Trunk Group - Services - CLI.

SIP Signaling Port Configuration

The following example sets tcpKeepaliveTime to 90 seconds, tcpKeepaliveInterval to 60 seconds and tcpKeepaliveProbes count to 2 for SIP Signaling Port 2:

% set addressContext default zone ZONE_SIPART_AS sipSigPort 2 tcpKeepaliveTime 90 tcpKeepaliveInterval 60 tcpKeepaliveProbes 2
% commit
 
% show details addressContext default zone ZONE_SIPART_AS sipSigPort 2
ipInterfaceGroupName      LIG2;
ipAddressV4               10.7.14.179;
portNumber                5060;
mode                      inService;
state                     enabled;
recorder                  disabled;
siprec                    disabled;
tcpConnectTimeout         5;
dscpValue                 0;
tlsProfileName            defaultTlsProfile;
transportProtocolsAllowed sip-tcp;
sctpProfileName           defaultSctpProfile;
tcpKeepaliveTime          90;
tcpKeepaliveInterval      60;
tcpKeepaliveProbes        2;

For configuration details, refer to Signaling Ports - SIP Sig Port (EMA) or Zone - SIP Sig Port - CLI.

TCP Media Port Ranges

The SBC Core supports the ability to specify a TCP port range for MSRP and BFCP (over TCP) streams using the configurable TCP Port Range object. TCP port ranges are used by the SBC to advertise TCP ports on which it can accept connections. TCP port ranges can be configured at the system level and on the SIP trunk group level.

The two configurable fields/parameters under tcpPortRange for the system include:

  • baseServerPort – The starting (base) port number for the range of TCP ports to use for media. The allowed baseServerPort range is 1-65534, with a system default value of 1024.
  • maxServerPort – The maximum TCP port number for the range of TCP ports to use for media. This value must be greater than the baseServerPort. The allowed maxServerPort range is 1-65534, with a system default value of 65534.

The two configurable fields/parameters under tcpPortRange for a SIP trunk group are similar:

  • baseServerPort – The starting (base) port number for the range of TCP ports to use for media for the trunk group. The allowed baseServerPort range is 1-65534, or "none." The default value is none which indicates the SBC uses the baseServerPort value specified at the system level.
  • maxServerPort – The maximum TCP port number for the range of TCP ports to use for media. This value must be greater than the baseServerPort. The maxServerPort range is 1-65534, or "none." The default value is none which indicates the SBC uses the maxServerPort value specified at the system level.

Each SIP trunk group can include a mediaIpAddress to indicate which IP address to use when allocating TCP media. The default value is 0.0.0.0 indicating that the system will choose an IP address from the mediaIpInterfaceGroup. The mediaIpAddress can be configured as either an IPv4 or IPv6 address. Any media IP address configured must belong to the IP Interface Group configured as the mediaIpInterfaceGroup for the trunk group.

Use the CLI 'show table' command to view the ipInterfaceGroup table listing TCP (or UDP) port ranges that are in assigned (mediaPortRangeAssigned) or available (mediaPortRangeUnassigned) for the indicated IP Interface Group.

For configuration details, refer to:

Alternative Solution for TCP Packet Relay of m=application Data

The SBC can establish/disconnect a TCP-SIP session by:

  • using a SIP device (not the SBC itself) to trigger the establishment of a TCP-SIP connection, and
  • disconnecting TCP from SIP without disconnecting the SIP session.

The flag enhancedApplicationMediaSupport supports this feature when enabled (Default = Disabled).

This flag is applicable only to application media stream and application media transport type is TCP


When enhancedApplicationMediaSupport is enabled, the following functionality is supported:

  1. The SBC initiates and establishes TCP on the egress leg only after the TCP connection is successful on ingress leg.
  2. The SBC supports transmitting URG (urgent) data from one leg to another.
  3. The SBC supports establishing and disconnecting a TCP connection multiple times within the same SIP session.

TCP-SIP Session Behavior

After the SBC establishes TCP connection at ingress, it generates the “TCP SYN” at egress:

  • Establish a TCP connection on ingress leg and then initiate TCP connection on egress leg
  • Accept Data from ingress leg only after the TCP connection is established on both legs
  • This implementation is based on assumption that the SBC need to support UAC and UAS Roles.         

When the SBC receives “TCP FIN” at either leg, it terminates and re-generates the “TCP FIN” at the other leg:

  • The SBC terminates the TCP connection on both legs when TCP FIN/RST is received on any of the legs.
  • For application media, the SBC always terminates the TCP connection on both legs if FIN is received on any of the legs.

When the SBC works for latch/re-latch, it creates a new TCP connection at the other leg:

  • For a re-latch, the endpoint sends a FIN before initiating TCP SYN again. In that case, the SBC terminates the existing connection on both legs and initiate new TCP connection on the other leg.
  • Any change in port on one leg results in re-establishing the connection on other leg.
  • Port and setup role modifications support for both re-INVITE and UPDATE.

As part this feature, the SBC supports transmitting Urgent (URG) data from one leg to another. The TCP connection terminates on both legs whenever TCP FIN or TCP RST is received on any of the legs.

Also as part of this feature, the SBC supports re-latch behavior meaning peer can disconnect and re-establish TCP connection any number of times within the same SIP session.

For configuration details, refer to:

TCP Relay Crankback Support

Modified: for 12.1.4



The SBC Core is enhanced to improve the reliability and fault tolerance of TCP relay calls when one or more IP peers are configured on the egress side. In this scenario, the SBC attempts to connect to multiple IP peers sequentially using its routing table from the PSX, if the primary IP peer is unreachable or if the User Agent Server (UAS) server is not running on that peer.

Call Flow Example:

  • Start

    • The User Agent Client (UAC) initiates TCP relay calls and the SBC attempts to connect to multiple UAS's configured on the egress side.
    • The UAC initiates a call to the SBC, and the SBC uses its routing table from PSX to establish a connection with the configured UAS (IP peer).

  • Redundancy and Fault Tolerance:

    • The SBC (Using built-in redundancy) to automatically fail over to the next UAS if the current one is unreachable or non-functional.
    • The SBC retries each UAS up to two times (with a one-second interval between each attempt) before moving on to the next one in the routing table list.

  • Sequential Processing:

    • The SBC starts with the first IP peer from its routing table and progresses through each configured IP peer until it establishes a successful connection or all attempts fail.
    • Once the SBC successfully connects to a UAS, it bridges the connection between the UAC and the selected UAS.

  • Failure Handling:

    • If the SBC fails to connect to all configured IP peers after the maximum number of retries, the TCP relay call setup is terminated and the SBC closes the connection with the UAC.