SIPconnect
The Oracle Communications Session Border Controller supports the SIPconnect 2.0 model to provide direct peering between SIP-enabled IP PBXs and SIP-enabled service provider networks.
An SBC can operate in the enterprise network and as the SP-SSE in the service provider network.
SIPconnect operates in two modes:
- In registration mode, PBXs register themselves so that service providers do not need to know IP addresses or locations in advance for static configurations. This is particularly helpful when the PBX is behind a NAT.
- In static mode, you configure the service provider with the PBX signaling address, or use DNS to discover the address.
The following sections describe how the SBC supports SIPconnect requirements in both modes.
Registering Multiple Addresses of Record
In the PBX registration process, the PBX creates a binding between one of its phone numbers as the address of record (AoR) and Contact-URI in the REGISTER message. The registrar knows that the single AoR actually represents many addresses, and so it registers them implicitly. However, the registrar does not return the implicit AoR number in P-Associated-URIs.
The SIPconnect feature resolves the following issues that arise from using this model:
- SIP INVITEs sent to the PBX from the Registrar through the SBC have the Request-URI of registered contact. Because it typically ignores the To-URI, the PBX needs the Request-URI username portion to be the specific extension number being called.
With the SIP connect feature enabled, the SBC overwrites the Request-URI username with the To-URI username, and generates the To header based on the Request-URI.
- SIP INVITEs from the PBX have the From AoR and Contact-URI usernames of specific phones rather than of the registered AoR and Contact-URI. For the SBC, this means that it cannot use the allow-anonymous parameter value of register; there would be no registered user matches, and the SBC would reject them (with a 403 Forbidden).
With the SIP connect feature enabled, the SBC performs allow-anonymous checking based on the registered Via address, which is the same for all requests for the same PBX.
TLS Support
The SBC supports Transport Layer Security (TLS) v1, v1.1, and v1.2 for SIP. For SIPconnect purposes:
- Because using transport=tls in Contact headers has been deprecated, the SBC ignores it if it appears. The SBC determines TLS based on the connection established by the registration instead.
- When configuring TLS, use the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite to comply with SIPconnect 2.0.
You configure these in the cipher-list parameter on the tls-profile configuration element.
See the Transport Layer Security topic in the Security chapter of this guide for more information about TLS support.
E.164 Number Resolution
When a user agent sends a request with a SIP URI that contains a tel URL (an E.164 format phone number preceded by +), the SBC performs name resolution by using an ENUM query and routes the request according to the returned ENUM records. If the ENUM request returns no records corresponding to a telephone number, the local policy determines how to forward the request.
See the ENUM Lookup topic in the Session Routing and Load Balancing chapter of this guide for more information.
DNS
The SBC supports DNS resolution.
See the DNS on the OCSBC topic in the System Configuration chapter of this guide for more information.
Routing for Outgoing Calls
When routing to the next hop, the SBC matches the incoming Request-URI with the to-address configured on the local policy, and uses that to route the request, rather than the To field of the incoming SIP message request.
See the About Local Policy and SIP Routing topics in the Session Routing and Load Balancing chapter of this guide for more information.
Caller Privacy
To support RFC 3323 and RFC 3325 caller privacy standards, the SBC determines whether the source and destination are trusted based on the trust-mode configured for a sip-interface.
See the discussion of Trust Mode in the SIP Interfaces topic in the SIP Signaling Services chapter of this guide for more information, including information about how the SBC handles Privacy, P-Asserted-Identity, and P-Preferred-Identity headers.
Call Forwarding and Transfer
The SBC supports call forwarding (SIP REDIRECT) and call transfers (SIP REFER).
See the Recurse 305 Only Redirect Action and SIP REFER Method Call Transfer topics in the SIP Signaling Services chapter of this guide for information about the redirect and refer options.
Emergency Sessions
The SBC can handle emergency sessions for trusted or non-trusted endpoints, configured based on priority settings in the sip-interface and local-policy on the session-router. See the Emergency Session Handling topic in the SIP Signaling Services chapter of this guide for more information.
To comply with IR.92 standards, you can alternatively use Network Management Control (NMC) rules to handle emergency calls. See the Network Management Controls topic in the Admission Control and QoS chapter, and IR.92-related topics in the IMS Support chapter of this guide for more information.
SDP Offer/Answer
The SBC supports the following SIPconnect 2.0-compliant SDP offer/answer scenarios:
- Offerless INVITE: The SBC forwards the INVITE without SDP and generates the media session according to the SDP in the response.
- ReINVITE without SDP version change or SDP body change (SRTP-to-SRTP):
- The SBC forwards the reINVITE unchanged, unless the media-manager has the unique-sdp-id option. If so, the SBC increments the version number.
- If the reINVITE is a refresh and srtp-rekey-on-reinvite is enabled, the SBC updates the outbound encryption information, but not the version number. See the discussion of SRTP re-keying in the Secure Real-Time Transport Protocol topic in the Security chapter of this guide for more information.
- ReINVITE with SDP body change but no SDP version change: The SBC increments the version number.
- ReINVITE with no SDP body: The SBC forwards the reINVITE with no SDP body and updates the media session according to the SDP in the response.
SRTP Encryption
The SBC supports using SRTP with the AES_CM_128_HMAC_SHA1_80 algorithm to send and receive media, including SRTP-to-SRTP, RTP-to-SRTP, and mixed offers containing two m-lines.
See the Secure Real-Time Transport Protocol topic in the Security chapter of this guide for more information.
Media Interactions
The SBC supports the following SIPconnect 2.0-compliant media interaction scenarios:
- Comfort noise codecs (CN):
- Supported by adding CN to add-codecs-on-egress in the codec-policy for the realm.
- You can also enable or disable the G729 to use annex B for voice detection activity by creating a media-profile to set annexb according to your needs with an annex B-specific subname, and including the subname when specifying codecs in the codec-policy.
See the Comfort Noise Transcoding and Media Type Subnames topics in the Transcoding chapter of this guide for more information .
- DTMF tones: See the DTMF Interworking chapter of this guide.
- Early Media: See the Early Media Support topic in the SIP Signaling Services chapter of this guide.
- Ringback tones: See the Local Media Playback chapter of this guide.
- SIP T.38 Fax calls. See the FAX Transcoding topic in the Transcoding chapter of this guide.
Note:
Fax Redirect is not required for SIPconnect 2.0.
IPv6 Support
The SBC supports IPv6 address configuration for routing.
See the IPv6 Address Configuration topic in the System Configuration chapter of this guide for more information.
Modifications to Registration Caching Behavior
With the SIP connect feature enabled, Oracle Communications Session Border Controller registration caching works the same way that it does with the feature disabled, with the following exceptions:
The SBC determines the destination realm for the sip-connect-pbx-reg option, and then:
- If it is configured, the SBC replaces the user part of the Request-URI with the user part of the To header. When the INVITE contains a P-Called-Party-ID header, the SBC uses the user part of the P-Called-Party-ID header instead of the To header.
- If it is not configured for the realm, the SBC determines if the destination address is for a session agent and whether that session agent has sip-connect-pbx-reg option configured. If it is configured for the session agent, the SBC performs the same replacements previously described.
When it is not configured for the session agent or realm, the SBC does not make any replacements.
When it receives an INVITE request, the SBC checks the incoming realm for the sip-connect-pbx-reg option, and then:
- If it is configured, the SBC uses the INVITE’s source address instead of the AoR and Contact-URI to search the registration cache for a matched registration entry.
- If it is not configured for the realm, the SBC determines if the INVITE’s source address is for a session agent and whether that session agent has sip-connect-pbx-reg option configured.
If it is configured for the session agent, the SBC performs the same replacements previously described.
If it is not configured for the session agent or realm, the SBC does not make any replacements.
The SBC also supports 401 and 407 digest-authentication challenges. After forwarding the REGISTER request, if the registrar challenges with a 401 or 407 response, the SBC generates authentication information using MD5 digest authentication, and sends it in a a second REGISTER to the registrar.
The REGISTER request also contains the expires parameter in the Contact header, by default set to a minimum of 300 in the min-reg-expire parameter. After the registration expires, if the SIP endpoint does not refresh the registration, the SBC removes the AoR mapping and stops forwarding requests.
Configuring SIPconnect Support
You configure SIPconnect support by applying the required configurations described in this section. Oracle also recommends some additional optional configurations.
Required Configuration
- Registration caching is enabled.
- For the realm from which registrations come, the options list must include sip-connect-pbx-reg; this is new configuration introduced to support this feature. The presence of this option instructs the
Oracle Communications Session Border Controller to skip matching the Contact header in the INVITE request with the registered Contact of the registration entry. The
Oracle Communications Session Border Controller finds a registration using only the INVITE’s source address.
Alternatively, you can configure the sip-connect-pbx-reg option in the options list for a session agent. When the realm where an INVITE comes from does not have this option set, the Oracle Communications Session Border Controller determines whether or not the INVITE came from a session agent. You might choose to configure session agents with this option if you do not want it applied to an entire realm. If the PBX is behind a NAT device, the session agent’s IP address for the PBX (if statically configured) must be the IP address of the NAT device. And if DNS is use, the session agent’s hostname must resolve to the NAT device’s IP address.
Suggested Additional Configuration
- In the SIP ports configuration (accessed through the SIP interface configuration), the allow-anonymous parameter must be set to registered. This setting allows the SBC to accept SIP requests from session agents and registered endpoints only, but to accept REGISTER requests from any endpoint.
- For the SIP interface that accepts registrations, the options parameter must be set to reg-via-key. This setting allows the SBC to use the source address of an INVITE as the key to find a registration entry in the registration cache. If a matching entry is found, the SBC treats the INVITE as coming from a registered endpoint and accepts the request.
- For full SIPconnect 2.0 compliance, enable and configure the various features list in the SIPconnect section as described in the topics referenced there.