uaCSTA NAT Support
The Oracle Communications Session Border Controller offers User Agent Computer Supported Telecommunications Application (uaCSTA) support, which allows for the network address translation (NAT) of a key XML element in SIP INFO messages to use a phone’s real contact URI.
Overview
Certain customers who use a uaCSTA for third party call control have encountered difficulties with the XML in their SIP messages used to support business applications. In these cases, the XML—specifically the <deviceID> XML tag—carries encoded IP addresses that need to be changed as they traverse the Oracle Communications Session Border Controller.
The SIP business application allows users to click-to-dial another party using e-mail application clients. The user’s click triggers the application server to send a uaCSTA SIP INFO message through the system to the UA/phone. These SIP INFO messages contain XML with the user’s Contact-URI. But the server is only aware of the Oracle Communications Session Border Controller’s NAT’d Contact-URI and not the user’s, so the XML in the SIP INFO is carrying incorrect information.
The XML element, then, needs to be NAT’d to the phone’s real Contact-URI. This is especially important because of the broad use of SIP INFO messages, which instruct a phone to:
- Answer a call
- Hold a call
- Retrieve a call
All of these functions are available via a clickable interface on the e-mail application.
The Oracle Communications Session Border Controller performs the NAT to the <deviceID> XML tag only if it is configured to perform registration caching.
When the Oracle Communications Session Border Controller receives a SIP message from the core side and the request has:
- A Content-Type of application/csta+xml
- A Content-Length greater than 0
it parses the message’s message body into an XML document. Should parsing fail, then the Oracle Communications Session Border Controller will forward the SIP INFO request without modification to the XML message body. Otherwise, the Oracle Communications Session Border Controller searches for the <deviceID> subelement within the XML document. If it finds the <deviceID> subelement, the Oracle Communications Session Border Controller searches through its registration cache for a registered Contact that matches the value of the <deviceID>. If it finds a match, the Oracle Communications Session Border Controller replaces the value of the <deviceID> with that of the corresponding registered Contact. If the value of the <deviceID> is a Contact that the Oracle Communications Session Border Controller generates for a registered UA, the corresponding contact from the look-up would be the Contact of the registered UA.
These functions performed, the Oracle Communications Session Border Controller then reformats the SIP INFO request with the modified XML message body before sending it to the next hop. If there is no match found, then the Oracle Communications Session Border Controller forwards the SIP INFO request without modifying the XML message body.
Other than ensuring your Oracle Communications Session Border Controller is configured to perform registration caching, you do not need take any further steps.
