You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

 

Overview

The SBC 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 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 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 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 

Unable to show "metadata-from": No such page "_space_variables"
supports configuring TCP Keep-alive timer settings for SIP Trunk Group and Signaling Port configurations. These parameters enable the
Unable to show "metadata-from": No such page "_space_variables"
to send out TCP Keep-alive packets to peer devices (for example, registered SIP phones) at configured intervals. The TCP Keep-alive packets allow a TCP connection between the
Unable to show "metadata-from": No such page "_space_variables"
and the peer device to remain active when there are no SIP packets being exchanged between them.

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, see SIP Trunk Group - Services (EMA) or sipTrunkGroup 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, see Signaling Ports - Sip Sig Port (EMA) or zone sipSigPort - CLI.

TCP Media Port Ranges

The 

Unable to show "metadata-from": No such page "_space_variables"
supports the ability to specify TCP port range for MSRP and BFCP (over TCP) streams using the configurable TCP Port Range object. TCP port ranges are used by the
Unable to show "metadata-from": No such page "_space_variables"
to advertise TCP ports on which it can accept connections.

The two configurable fields/parameters under tcpPortRange include:

  • baseServerPort – The starting (base) port number for the range of TCP ports to use for media. The baseServerPort range is 1-65534, or "none" (the default value which indicates SBC does not apply this SIP trunk group control, and instead uses the tcpPortRange specified by system-wide settings.
  • 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 which indicates SBC does not apply this SIP trunk group control, and instead uses the tcpPortRange specified by system-wide settings.

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 function as it currently does by choosing 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 marked (mediaPortRangeAssigned) or unmarked (mediaPortRangeUnassigned) for the indicated IP Interface Group.

For configuration details, see:

 

  • No labels