Media over TCP
The Oracle® Enterprise Session Border Controller now supports RFC 4145 (TCP-Based Media Transport in the SDP), also called TCP Bearer support. Media over TCP can be used to support applications that use TCP for bearer path transport.
RFC 4145 adds two new attributes, setup and connection, to SDP messages. The setup attribute indicates which end of the TCP connection should initiate the connection. The connection attribute indicates whether an existing TCP connection should be used or if a new TCP connection should be setup during re-negotiation. RFC 4145 follows the offer/answer model specified in RFC3264. An example of the SDP offer message from the end point 192.0.2.2 as per RFC4145 is as given below:
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
This offer message indicates the availability of t38 fax session at port 54111 which runs over TCP. Oracle® Enterprise Session Border Controller does not take an active part in the application-layer communication between each endpoint.
The Oracle® Enterprise Session Border Controller provides the means to set up the end-to-end TCP flow by creating the TCP/IP path based on the information learned in the SDP offer/answer process.
TCP Bearer Conditions
The following conditions are applicable to the Oracle® Enterprise Session Border Controller’s support of RFC 4145.
- The Oracle® Enterprise Session Border Controller can not provide media-over-TCP for HNT scenarios (endpoints behind a NAT).
- When media is released into the network, the TCP packets do not traverse the Oracle® Enterprise Session Border Controller because nNo TCP bearer connection is created.
- The Oracle® Enterprise Session Border Controller does not inspect the setup and connection attributes in the SDP message since the TCP packets transparently pass through the Oracle® Enterprise Session Border Controller. These SDP attributes are forwarded to the other endpoint. It is the other endpoint's responsibility to act accordingly.
-
After the
Oracle® Enterprise Session Border Controllerreceives a SYN packet, it acts as a pure pass through for that TCP connection and ignores all further TCP handshake messages including FIN and RST. The flow will only be torn down in the following instances:
-
The TCP initial guard timer, TCP subsequent guard timer, or the TCP flow time limit timer expire for that flow.
-
The whole SIP session is torn down.
-
TCP Port Selection
When a call is first set up, the Oracle® Enterprise Session Border Controller inspects the SDP message's m-line to see if any media will be transported via TCP. If the SDP message indicates that some content will use TCP, the Oracle® Enterprise Session Border Controller allocates a configured number of steering ports for the media-over-TCP traffic. These TCP media ports are taken from the each realm’s steering pool.
Each endpoint can initiate up to four end-to-end TCP flows between itself and the other endpoint. The Oracle® Enterprise Session Border Controller assigns one port to receive the initial TCP packet (server port), and one to four ports assigned to send TCP traffic (client ports) to the receiving side of the TCP flow. The number of TCP flows for each call is configured globally.
In order to configure the Oracle® Enterprise Session Border Controller to facilitate and support this process, you need to specify the number of ports per side of the call that can transport discrete TCP flows. You can configure one to four ports/flows. For configuration purposes, the Oracle® Enterprise Session Border Controller counts this number as inclusive of the server port. Therefore if you want the Oracle® Enterprise Session Border Controller to provide a maximum of one end-to-end TCP flow, you have to configure two TCP ports; one to receive, and one to send. The receiving port (server) is reused to set up every flow, but the sending port (client) is discrete per flow. For example: for 2 flows in each direction, set the configuration to 3 TCP ports per flow; for 3 flows in each direction, set the configuration to 4 TCP ports per flow, etc.
The server port is used for initiating a new TCP connection. An endpoint sends the first packet to a server port on the ingress interface. The packet is forwarded out of the Oracle® Enterprise Session Border Controller through a client port on the egress interface toward an endpoint:
The endpoint responds back to the client port on the egress interface. This message traverses the Oracle® Enterprise Session Border Controller and is forwarded out of the server port on the ingress interface where the initial packet was sent. The remainder of the TCP flow uses the server and client port pair as a tunnel through the Oracle® Enterprise Session Border Controller:
When the second TCP connection is set up in the same direction as in the first example, the first packet is still received on the server port of the ingress interface. The next unused client port is chosen for the packet to exit the Oracle® Enterprise Session Border Controller:
The response takes the same path back to the caller. The remainder of the second TCP connection uses this established path:
When the callee initiates a TCP connection, it must send its initial traffic to the server port on its Oracle® Enterprise Session Border Controller ingress interface. The packet is forwarded out of the first free client port on the egress side of this TCP connection toward the caller.
The caller’s response takes the same path back to the callee that initiated this TCP connection. The remainder of the third TCP connection uses this established path.
The Oracle® Enterprise Session Border Controller can support a total of eight media-over-TCP connections per call. A maximum of 4 connections are supported as initiated from each side of the call.
SDP Offer Example
The following abbreviated call flow diagram sets up a media-over-TCP flow. Observe that the caller listens for audio over TCP on 172.16.0.10:10000, as described in the SDP offer (1). The Oracle® Enterprise Session Border Controller re-writes the m and c lines in the SDP offer to reflect that it is listening for audio over TCP on its egress interface at 192.168.0.1:10000 (3). The Oracle® Enterprise Session Border Controller then forwards the SIP invite to the callee.
The SIP callee responds with an SDP answer in a 200 OK message. The callee indicates it is listening for the audio over TCP media on 192.168.0.10:10001 (6). The Oracle® Enterprise Session Border Controller re-writes the m and c lines in the SDP answer to reflect that it is listening for audio over TCP on the call's ingress interface at 172.16.0.1:10001 (7). The Oracle® Enterprise Session Border Controller then forwards the SIP invite to the caller.
All interfaces involved with the end-to-end TCP flow have now established their listening IP address and port pairs.
Timers
The Oracle® Enterprise Session Border Controller has three guard timers that ensure a TCP media flow does not remain connected longer than configured. You can set each of these from 0 (disabled) to 999999999 in seconds.
- TCP initial guard timer — Sets the maximum time in seconds allowed to elapse between the initial SYN packet and the next packet in this flow.
- TCP subsequent guard timer — Sets the maximum time in seconds allowed to elapse between all subsequent sequential TCP packets.
- TCP flow time limit — Sets the maximum time that a single TCP flow can last. This does not refer to the entire call.
Transparent BFCP Support over UDP and TCP
Binary Floor Control Protocol (BFCP) is a protocol for controlling the access to the media resources in a conference, such as conference and media session setup, conference policy manipulation, and media control (as defined in RFC 4582).
The Oracle® Enterprise Session Border Controller now supports BFCP for interworking between Polycom video devices and Siemens Enterprise Communications (SEN) endpoints. When a SIP INVITE request containing a Session Description Protocol (SDP) from a Polycom device is sent to a SEN device, the Oracle® Enterprise Session Border Controller passes the INVITE request between the two devices regardless of the transfer protocol being used by the devices (UDP or TCP). It also passes the INVITE whether or not it is accepted or rejected by the destination device. The transfer protocol changes between UDP and TCP during the dialog between both endpoints on either side of the Oracle® Enterprise Session Border Controller.
Note:
If both endpoints on either side of the Oracle® Enterprise Session Border Controller support BFCP, the BFCP is answered with the first SDP offer/answer cycle.The following illustrates the call flow between a Polycom device and a SEN device when an INVITE is sent from the Polycom device.
- Polycom device initiates a call to the SEN device by sending a SIP INVITE to the SD with SDP, using UDP and BFCP.
- SD forwards the SIP INVITE to the SEN device.
- SEN device does not support BFCP, and therefore, rejects the INVITE and sends a 200 Ok with port '0' from the SEN side to the SD.
- SD forwards the 200 Ok response to the Polycom device.
- Polycom device looks at port ‘0’ and changes the media transport type from UDP to TCP. It then sends a re-INVITE to the SD.
- SD forwards the re-INVITE to the SEN device.
- SEN device does not support BFCP, and therefore, rejects the re-INVITE, and sends a 200 Ok with port ‘0’ from the SEN side to the SD.
- SD forwards the 200 Ok response to the Polycom device.
- Polycom device looks at port ‘0’ and changes the media transport type from TCP to UDP. It then sends a re-INVITE to the SD.
- SD forwards the re-INVITE to the SEN device.
- SEN device does not support BFCP, and therefore, rejects the re-INVITE, and sends a 200 Ok with port ‘0’ from the SEN side to the SD.
- SD forwards the 200 Ok response to the Polycom device.
- Process repeats Steps 5 through 12 until the call is accepted by the SEN device.
