SIP Interfaces
This section explains how to configure a SIP interface. The SIP interface defines the transport addresses (IP address and port) upon which theOracle Communications Session Border Controller receives and sends SIP messages.
Overview
The SIP interface defines the signaling interface. You can define a SIP interface for each network or realm to which the Oracle Communications Session Border Controller is connected. SIP interfaces support both UDP and TCP transport, as well as multiple SIP ports (transport addresses). The SIP interface also lets Hosted NAT Traversal (HNT) be used in any realm.
The SIP interface configuration process involves configuring the following features:
- address and transport protocols (SIP ports)
- redirect action
- proxy mode
- trust mode
About SIP Ports
A SIP port defines the transport address and protocol the Oracle Communications Session Border Controller will use for a SIP interface for the realm. A SIP interface will have one or more SIP ports to define the IP address and port upon which the Oracle Communications Session Border Controller will send and receive messages. For TCP, it defines the address and port upon which the Oracle Communications Session Border Controller will listen for inbound TCP connections for a specific realm.
You need to define at least one SIP port, on which the SIP proxy will listen for connections. If using both UDP and TCP, you must configure more than one port. For example, if a call is sent to the Oracle Communications Session Border Controller using TCP, which it needs to send out as UDP, two SIP ports are needed.
Preferred SIP Port
When a SIP interface contains multiple SIP ports of the same transport protocol, a preferred SIP port for each transport protocol is selected for outgoing requests when the specific SIP port cannot be determined. When forwarding a request that matched a cached registration entry (HNT or normal registration caching), the SIP port upon which the original REGISTER message arrived is used. Otherwise, the preferred SIP port for the selected transport protocol is used. When selecting the preferred SIP port, the default SIP port of 5060 will be selected over other non-default ports.
For SIP interfaces using the SIP NAT function, the preferred SIP port address and port will take precedence over the external address of the SIP NAT when they do not match. If both TCP and UDP SIP ports are defined, the address and port of the preferred UDP port is used.
Proxy Mode
The Oracle Communications Session Border Controller’s proxy mode determines whether it forwards requests received on the SIP interface to target(s) selected from local policy; or sends a send a redirect response to the previous hop. Sending the redirect response causes the previous hop to contact the targets directly.
If the source of the request matches a session agent with a proxy mode already defined, that mode overrides the proxy mode defined in the SIP interface.
You can configure the proxy mode to use the Record-Route option. Requests for stateless and transaction operation modes are forwarded with a Record-Route header that has the Oracle Communications Session Border Controller’s addresses added. As a result, all subsequent requests are routed through the Oracle Communications Session Border Controller.
Redirect Action
The redirect action is the action the SIP proxy takes when it receives a SIP Redirect (3xx) response on the SIP interface. If the target of the request is a session agent with redirect action defined, its redirect action overrides the SIP interface’s.
You can set the Oracle Communications Session Border Controllerto perform a global redirect action in response to Redirect messages. Or you can retain the default behavior where the Oracle Communications Session Border Controller sends SIP Redirect responses back to the previous hop (proxy back to the UAC) when the UAS is not a session agent.
The default behavior of the Oracle Communications Session Border Controller is to recurse on SIP Redirect responses received from the user agent server (UAS) and send a new request to the Contact headers contained in the SIP Redirect response.
Instead of this default behavior, the Oracle Communications Session Border Controller can proxy the SIP Redirect response back to the user agent client (UAC) using the value in the session agent’s redirect action field (when the UAS is a session agent). If there are too many UASes to define as individual session agents or if the UASs are HNT endpoints, and SIP Redirect responses need to be proxied for UASs that are not session agents; you can set the default behavior at the SIP Interface level.
SIP maddr Resolution
Release S-C6.2.0 provides enhanced resolution of addresses found in SIP contact headers, or in the maddr (multicast address) parameter of SIP 3xx REDIRECT messages. Previous releases resolved these addresses as either a host address or as a session agent name. With Release 6.2.0 these addresses can also be resolved as session agent group (SAG) names.
Support for SAG-based resolution is provide by a new sip-config parameter, sag-lookup-on-redirect. By default, SAG lookup is disabled, providing compatibility with prior releases.
The following sample SIP REDIRECT and ACLI configuration fragment illustrate enhanced processing.
Status-Line: SIP/2.0 302 Moved
Message Header
Via: SIP/2.0/UDP
192.168.200.224:5060;branch=z9hG4bKa0fs40009o90sc8oo780.1
From: <sip:1111@192.168.1.222:6000>;tag=1
To: sut <sip:2223@192.168.1.224:5060>;tag=11
Call-ID: 1-28515@192.168.1.222
CSeq: 1 INVITE
Contact: <sip:1111@192.168.1.223;maddr=test.acmepacket.com>
Privacy: user;id;critical;session
P-Preferred-Identity: sipp <sip:sipp@192.168.200.222:5060>
P-Asserted-Identity: abc.com
Subject: abc
Proxy-Require: privacy,prack,abc
Content-Length: 0
session-group
group-name test.acmepacket.com
description
state enabled
app-protocol SIP
strategy Hunt
dest
192.168.200.222
192.168.200.223
...
...In this case, when the Oracle Communications Session Border Controller receives the 302, it resolves the information from maddr to a SAG name. In the above example, it will resolve to the configured SAG – test.acmepacket.com. The destinations configured in SAG test.acmepacket.com will be used to route the call.
SAG-based address resolution is based on the following set of processing rules.
Trust Mode
The Oracle Communications Session Border Controller supports the Calling Identity privacy requirements based on RFC 3323 and RFC 3325. The trust mode in the SIP interface determines whether the source and destination of a request is a trusted entity. With the implementation of this feature, the Oracle Communications Session Border Controller can understand and support the privacy headers and provide the capability for anonymous packets
The Oracle Communications Session Border Controller, which acts as a boundary device between the trusted platform and the untrusted Internet, understands the following headers:
- Privacy Header
- P-Asserted-Identity Header
- P-Preferred-Identity Header
Depending on the value of these headers and the mode in which the Oracle Communications Session Border Controller is being operated (B2BUA or the proxy), the appropriate actions are performed.
About the Process
On receiving a message, the Oracle Communications Session Border Controller checks whether the message source is trusted or not. It checks the SIP interface’s trust mode value and, if the source is a session agent, the session agent’s trust me value. Depending on these values, the Oracle Communications Session Border Controller decides whether the request’s or response’s source is trusted. If it receives message from a trusted source and the message contains the P-Asserted-Identity header field, the Oracle Communications Session Border Controller passes this message to the outgoing side. The outgoing side then decides what needs to be done with this request or response.
If the request or the response is received from an untrusted source, the Privacy header value is id (privacy is requested), and the P-Asserted-Identity header field is included, the Oracle Communications Session Border Controller strips the Privacy and the P-Asserted-Identity headers and passes the request or the response to the outgoing side.
If the request or the response contains the P-Preferred-Identity header and the message source is untrusted, the Oracle Communications Session Border Controller strips the P-Preferred-Identity header from the request or the response and passes the message to the outgoing side.
If the source is trusted or privacy is not requested (the value of the Privacy Header is not id) and the request or the response contains the P-Preferred-Identity header, the Oracle Communications Session Border Controller performs the following actions:
- inserts the P-Asserted-Identity header field with the value taken from the P-Preferred-Identity header field
- deletes the P-Preferred-Identity header value
- passes this request or the response to the Outgoing side for the appropriate action, depending on the whether the destination is trusted or not
After the Oracle Communications Session Border Controller passes the request or the response to the outgoing side, it checks whether the destination is trusted by checking the SIP interface’s trust mode value and the session agent’s trust me value (if the destination is configured as session agent).
- The destination is trusted
The Oracle Communications Session Border Controller does nothing with the request or the response and passes it to the destination. If the P_Asserted_Identity headers are present, they are passed to the session agent (if the destination is configured as session agent).
- The destination is untrusted
The Oracle Communications Session Border Controller looks at the value of the Privacy header. If set to id, the Oracle Communications Session Border Controller removes all the P-Asserted-Identity headers (if present). It strips the Proxy-Require header if it is set to privacy. The Oracle Communications Session Border Controller also sets the From field of SIP header to Anonymous and strips the Privacy header.
If the Privacy header is set to none, the Oracle Communications Session Border Controller does not remove the P-Asserted-Identity header fields.
If there is no Privacy header field, the SD will not remove the P-Asserted-Identity headers.
To implement this feature, you need to configure the session agent’s trust me parameter to enabled (if the message source is a session agent) and the SIP interface’s trust mode to the appropriate value.
Call Duration Counters
The Oracle Communications Session Border Controller maintains aggregate call duration in seconds for the current period, lifetime total and the lifetime-period-maximum. These counters are maintained for each session agent, realm, SIP Interface, and globally across the system. The call duration counter can count up to a 32 bit value, after which time it rolls over.
- show sipd agents
- show sipd realms
- show sipd interface
- show sipd status
Call Duration Calculation
Call duration is calculated as the time between (t1) when the SBC receives the 200OK for the INVITE from terminating endpoint, and (t2) the time when SBC receives the final 200OK for the BYE message from terminating endpoint, regardless of whether media is released. If the set-disconnect-time-on-bye parameter is enabled in the sip-config, then the call termination time (t2') is when the SBC receives the BYE message originally from the endpoint ending the call.
Figure 5-1 Call Duration Calculation Example - Ladder Diagram
Table 5-1 Call Duration Calculation Example - Results
| Element | Inbound Duration (sec) | Outbound Duration (sec) |
|---|---|---|
| Session Agent: SA-1 | t2 - t1 | 0 |
| Session Agent: SA-2 | 0 | t2 - t1 |
| Realm: InRealm | t2 - t1 | 0 |
| Ream: OutRealm | 0 | t2 - t1 |
| Interface: 1.1.1.1 | t2 - t1 | 0 |
| Interface: 2.2.2.2 | 0 | t2 - t1 |
The global system call duration for the previous example is t2' - t1 seconds if the set-disconnect-time-on-bye parameter is enabled.
Configurable Timers and Counters
SIP timers and counters can be set in the global SIP configuration, and two can be specific for individual SIP interfaces.
You can set the expiration times for SIP messages, and you can set a counter that restricts the number of contacts that the Oracle Communications Session Border Controller tries when it receives a REDIRECT. These are similar to two parameters in the global SIP configuration, trans-expire and invite-expire. You can also set a parameter that defines how many contacts/routes the Oracle Communications Session Border Controller will attempt on redirect.
Timer to Tear Down Long Duration Calls
The Oracle Communications Session Border Controller currently provides the “flow-time-limit” timer to terminate long duration calls. However, this timer is reset whenever the Oracle Communications Session Border Controller receives a Re-INVITE or UPDATE message, even when it is provided for the session timer. This feature adds a non-resettable timer that, when enabled and upon expiration, tears down long duration calls.
When the “flow-time-limit” timer for terminating long media flow expires, the Oracle Communications Session Border Controller sends a SIP BYE or H323 Release Complete message to tear down the long call. However, this timer is reset whenever the SBC receives a Re-INVITE or UPDATE message. In most call scenarios, long duration calls are terminated with the expiration of this timer, but there are some cases where a call can stay connected for a longer duration. For example, if a user connects to an IVR service and does not hang up the phone receiver properly, there is no way for the network provider to free up the IVR resources if the user devices send session updating requests. To prevent this situation, this feature adds a new timer session-max-life-limit, which starts when the call or session is established and does not reset for any session update, keep-alive or SBC switchover. On expiry, the call is torn down if it’s in established state.
The new timer session-max-life-limit can be provisioned in the following configuration elements, in order of precedence from highest to lowest: session-agent, realm-config, sip-interface, and sip-config. Its range of values is {0-2073600} seconds with an additional special case value of “Unlimited”, which is treated as the highest possible value. The default value is 0 (no timer).
Difference between 0 and Unlimited
No timer is created when session-max-life-limit is configured to either the value 0 or “Unlimited”, so no timeout can occur. The difference between the two values is how they are handled when determining which value of session-max-life-limit to use when there are several specified within the various configuration elements. When a session is created the timer examines both the ingress side and the egress side and, in cases where both sides have a configured value for session-max-life-limit, uses the side with the lower (stricter) value. On each side, the SBC reviews the configuration elements relevant to the session and uses the value of session-max-life-limit from the configuration element with the highest precedence (session-agent, then realm-config, then sip-interface, and lastlysip-config). When the value is set to 0, the configuration element is ignored and the next configuration element in the precedence chain is looked at. A value between 1 and 2073600 (24 days) or the value “Unlimited” is treated as a valid configured value. In this case the SBC will not move onto the next element in the precedence chain and the value is used in the final comparison between the egress and ingress values. The value “Unlimited” is viewed as the highest possible value, and therefore is considered greater than any other value it is compared against. The value 0 is skipped over and completely ignored.
For example, on the ingress side the value of session-max-life-limit in realm-config is set to 86400 and the value of session-max-life-limit in session-agent is set to "Unlimited". The session-agent value has a higher precedence than the realm-config value so, therefore, the value “Unlimited” is used for the ingress side. On the egress side the value of session-max-life-limit in realm-config is set to 43200 and the value of session-max-life-limit in session-agent is set to 0 (no timer), so the value of session-max-life-limit in realm-config is used. When compared against the ingress side the value 43200 is less than “Unlimited”; therefore, the value set for the timer is 43200.
Timer to Tear Down Long Duration Calls Configuration
Use the following procedure to configure, in the session-agent, realm-config, sip-interface, and sip-config configuration elements, a non-resettable timer that, when enabled and upon expiration, tears down long duration calls.
Asymmetric Preconditions
This feature allows you to reserve network resources for a session before the called party is alerted by establishing preconditions for individual call legs. Currently, the Oracle Communications Session Border Controller transparently passes precondition attributes in SIP signaling and the UEs negotiate preconditions end to end. However, some networks support the SIP preconditions and other networks do not. To help provide precondition interworking between these networks, the Oracle Communications Session Border Controller supports SIP preconditions on a per call leg basis.
Some architectures require minimizing the chance of session establishment failure after alerting the called party. One source of failure is the inability to reserve network resources for a session, which can cause media clipping and "ghost rings". The solution is to allow preconditions to reserve network resources for the session before alerting the called party. A precondition is a set of constraints about the session which are introduced in the offer. The recipient of the offer generates an answer, but does not alert the user or otherwise proceed with session establishment until the preconditions are met. This can be known through a local event (such as a confirmation of a resource reservation), or through a new offer sent by the caller. The concept of preconditions is explained in RFC 3312, updated by RFC 4032, and also 3GPP TS 24.229.
- The SBC does not use preconditions when the received INVITE request does not include the precondition option tag in the Supported or Require header fields.
- When the received INVITE request includes the precondition option tag in the Supported or Require header fields, the SBC uses the precondition mechanism and inserts a Require header field with the precondition option tag in any response including an SDP or subsequent request (also with SDP) that it sends to the originating UE during session establishment.
- When the received INVITE request includes the 100rel and preconditions option tags and the SDP offer contains no precondition attributes, the equipment behaves as if the INVITE was received without an SDP. In this case the SBC just proxies the request and no preconditions interworking occurs.
- When the received INVITE request includes the 100rel and preconditions option tags and there is no SDP (content) in the incoming INVITE, the SBC treats the INVITE as an offerless case and preconditions interworking occurs.
- The SBC always has resources reserved, so the value of the SDP parameter direction-tag in the preconditions current attribute line will always be sendrecv for the SDP parameter status-type value local for the SBC.
- The SBC always has resources reserved, so the value of the SDP parameter direction-tag in the preconditions current attribute line will always be sendrecv for the SDP parameter status-type value local for the SBC.
- If the UE answers with a request for confirmation of resources, the SBC resends the UPDATE with sendrecv on the local preconditions for the SBC. As the SBC always confirms the preconditions in the first response or in the request it sends towards the UE, there is no need for the UE to confirm resources on the SBC.
When appropriately configured, the Oracle Communications Session Border Controller inserts SDP into an outgoing INVITE when the corresponding incoming INVITE has none. Because no SDP information is available for the session, the Oracle Communications Session Border Controller uses a media profile from a previously configured list to determine the content to insert. You cannot enable asymmetric preconditions without first enabling PRACK interworking by setting the value of sip-interface, options to 100rel-interworking. The SBC does precondition interworking by creating SDP offers or answers before the actual ones have reached the UE; thus, transcoding policies are needed to cover the cases where different codecs are negotiated. However, in cases where different codecs are not expected, interworking works without defining codec policies. When codec policies are not defined and a final SDP answer comes with a different codec, the SBC will drop the call with 488 Not Acceptable.
To establish preconditions interworking, you must first enable it on the SIP interface with the parameter asymmetric-preconditions and then define when the initial offer will be sent to the endpoint that doesn’t support preconditions with the parameter asymmetric-preconditions-mode. When the value of asymmetric-preconditions-mode is send-with-nodelay, the SBC forwards the INVITE as soon as it is received; however, it strips the precondition option tag from the Require and Supported header fields and also removes the preconditions related SDP. This triggers preconditions interworking on the calling side of the SBC. Responses received from the called party are queued until resource reservation is complete on the calling side. When resource reservation is complete, all buffered responses from the called party are sent to the calling party (after, if necessary, removing the SDP as in PRACK interworking) and the call proceeds as normal. When the value of asymmetric-preconditions-mode is send-with-delay on the egress, the initial INVITE forwarded to the called party is held until preconditions are met by the calling party. For offerless 18x INVITEs, that is, when the incoming INVITE has no STP, the SBC inserts the SDP, as configured in the media profile names listed in add-sdp-profiles-in-msg, in the 18x (183) response towards the UE.
Asymmetric Preconditions Configuration Guidelines
Set the asymmetric-preconditions parameter to enabled on any sip-interface that connects to networks requiring preconditions support.
Note:
Offer-less scenarios do not use SDP attributes to denote the use of preconditions. All such messaging uses precondition tags.| Egress | Ingress | Notes |
|---|---|---|
| disabled | disabled | INVALID configuration
Proxy the request, no IWF |
| disabled | enabled |
If the INVITE has no precondition attributes, then proxy. If the INVITE has precondition tags and attributes, trigger precondition IWF. If, the egress interface has asymmetric-preconditions-mode set to send-with-no delay, the INVITE will be forwarded immediately as soon as SBC receives it. If, the egress interface has asymmetric-preconditions-mode=send-with-delay, the INVITE will be held until preconditions are complete and SBC will forward it. |
| enabled | disabled |
If, Incoming INVITE has preconditions, then proxy, no IWF. If, Incoming INVITE has no preconditions, insert precondition tags and SDP. If response comes with precondition tag, then continue with IWF. If response has no precondition option tags, no IWF - disable the functionality and proxy. |
| enabled | enabled | INVALID configuration
Proxy the request, no IWF |
When an INVITE arrives with both precondition tags and precondition SDP attributes, the SBC behaves as listed below, sending the message with or without delay, based on the asymetric-preconditions-mode configuration on the outgoing interface.
- The SBC performs preconditions-to-nonpreconditions interworking by stripping
the precondition tags and attributes and forwarding when it is configured with:
- Incoming interface:
- 100rel-interworking option enabled
- asymetric-preconditions parameter set to enabled
- Outgoing interface:
- asymetric-preconditions parameter set to disabled
- Incoming interface:
- The SBC proxies the request, and does not perform interworking when it is
configured with:
- Incoming interface:
- 100rel-interworking option disabled
- asymetric-preconditions parameter set to disabled
- Outgoing interface:
- 100rel-interworking option enabled
- asymetric-preconditions parameter set to enabled
- Incoming interface:
- The SBC proxies the request, and does not perform interworking when it is
configured with:
- Incoming and outgoing interfaces have asymetric-preconditions enabled
- Incoming and outgoing interfaces have asymetric-preconditions disabled
In situations when the INVITE arrives with no preconditions tags and no precondition SDP attributes, the SBC behaves as listed below.
- The SBC proxies the request, and does not perform interworking when it is
configured with:
- Incoming interface:
- 100rel-interworking option enabled
- asymetric-preconditions parameter set to enabled
- Outgoing interface:
- asymetric-preconditions parameter set to disabled
- Incoming interface:
- The SBC performs nonpreconditions-to-preconditions interworking by inserting
the precondition tags and attributes and forwarding when it is configured with:
- Incoming interface:
- 100rel-interworking option disabled
- asymetric-preconditions parameter set to disabled
- Outgoing interface:
- 100rel-interworking option enabled
- asymetric-preconditions parameter set to enabled
The SBC proxies the request, and performs no interworking when it is configured with:- Incoming and outgoing interfaces have asymetric-preconditions enabled
- Incoming and outgoing interfaces have asymetric-preconditions disabled
- Incoming interface:
Transcoder Free Operation for Asymmetric Preconditions
You can configure the SBC to avoid using transcoding resources while supporting call flows with asymmetric preconditions. After establishing a call that includes transcoding, the SBC can trigger this Transcoder Free Operation (TrFO) feature if the asymmetric preconditions parameter is present in the caller's SDP and a compatible codec can still be identified. Having determined that the call can proceed without transcoding, the SBC originates a reINVITE towards the calling party containing the called side codec. Once the reINVITE is completed, the call can continue without transcoding. The negotiated codec on the called party side must have been included in the calling party's original offer (after ingress codec-policy execution).
When preconditions are enabled on either the caller or callee side and disabled on the other side, the SBC is able to trigger preconditions interworking. The SBC stores all the provisional and final responses from the callee until the preconditions are met. At this point in the call flow, the negotiated codec in the 200 OK may be different than that of the calling side triggering transcoding. To avoid this transcoding, you can configure the SBC to issue a re-INVITE to the caller after call establishment with a compatible codec on the called side. The SBC initiates this re-INVITE only if the following conditions are true:
- Transcoding is induced by asymmetric preconditions
- The negotiated codec on the called side is within the allowed codecs of the calling party's initial offer
To determine whether it can send out this re-INVITE, the SBC retains the codec list sent by the calling party, usually within the initial offer with all supported codecs. It also monitors the result of the ingress codec-policy for compatible codecs.
Important limitations to when the SBC can use TrFO with asymmetric preconditions include:
- Although asymmetric preconditions are supported for either side of a call, the SBC only supports TrFO for the caller side. If asymmetric preconditions are applied on the called interface or on both the interfaces, thisTrFO feature does not work.
- This feature does not apply to call flows with offerless INVITEs.
- This feature does not apply to call flows with multiple-early dialog.
- The TrFO for ringback and asymmetric preconditions features can conflict with each other. If there is a configuration wherein a session agent has ringback enabled, and TrFO for Asymmetric Preconditions is enabled on that session agent's realm, the configuration is invalid and, thisTrFO feature does not work.
- The SBC does not fully support TrFO when you configure the feature-trfo parameter with both ringback and asymmetric-preconditions. If you configure both ringback and asymmetric-preconditions on the ingress and egress realms, such that the system is expected to perform both functions simultaneously on opposite ends of a call, the TrFO would be applicable only to one of the features.
Configuration
This functionality requires that you configure the EVS WB media profile. In addition, you must configure the initial INVITE ingress realm with the feature-trfo parameter using the syntax below.
ORACLE(realm-config)# feature-trfo asymmetric-preconditionsUnder the conditions described in this section, this configuration allows the SBC to force SDP re-negotiation and prevents the call from requiring transcoding.
As mentioned above, although you can configure the feature-trfo parameter with multiple parameters, the SBC only acts on one of those parameters at any give time. Under the condition where more than one parameter applies, the SBC refers to your configuration's parameter order to determine which function to perform:
- If the configuration order appear with ringback first, the SBC applie TrFO for ringback. (feature-trfo : ringback,asymmetric preconditions).
- If the configuration order appear with asymmetric preconditions first, the SBC applie TrFO for asymmetric preconditions. (feature-trfo : asymmetric preconditions, ringback).
TrFO Statistics for Asymmetric Preconditions
The show sipd preconditions-trfo command shows Asymmetric Preconditions TrFO statistics:
- Initiated: number of initiated TRFO reINVITE transactions
- Success: number of successfully completed TRFO reINVITE transactions
- Failure: number of failed TRFO reINVITE transactions (either error returned or timed out)
ORACLE# show sipd preconditions-trfo
Asymmetric Preconditions TrFO statistics (2011-09-24 12:03:37.051)
---- Lifetime ----
Recent Total PerMax
Initiated 0 3 2
Success 0 3 2
Failure 0 0 0
You can reset this data back to zero using the reset sipd command.
Asymmetric Preconditions and EVS using Super Wide-band
The SBC supports transcoding the EVS codec, but not when the bandwidth presented is SWB, NB-SWB, or WB-SWB. When presented with these within asymmetric preconditions call flows, the SBC performs an "internal transcode" using the EVS WB instead of the EVS-SWB codec. This works because a UE that supports EVS-SWB also supports EVS-WB. The SBC performs this function for asymmetric preconditions call flows only.
To support EVS-SWB for within an asymmetric precondition call flow, the SBC monitors initial INVITEs for the EVS codec with SWB in the offer/answer SDP. If present, the system maps the bandwidth parameter from SWB to WB/NB and updates the media flows. Once media flows are updated, and before sending out the request/response, the SBC uses the original offer to compare and revert the bandwidth parameter back to support the caller or callee.
The SBC performs this mapping when triggered by the caller or callee. This could be the initial INVITE from the caller as well as the 200 OK from the callee. Internally, the SBC maps these to evs-wb and, before sending out the request or response, replaces them with evs-swb, in accordance with the stored offer.
Supported methods include INVITE, UPDATE and PRACK within the context of asymmetric preconditions call flow. The system maps EVS-SWB bandwidth as follows:
- bw=nb-swb mapped to bw=nb-wb
- bw=wb-swb mapped to bw=wb
- bw=swb mapped to bw=wb
You configure this behavior with the following, in addition to the TrFo configuration.
ORACLE(sip-config)# asymm-preconditions-evs-swb-support enabledImportant considerations while deploying this feature include:
- The SBC does not support EVS-SWB within codec policy, because it does not encode EVS-SWB packets.
- If the environment changes the codec's payload type before forwarding the request, the SBC still tries to negotiate using wideband bandwidth. This is because , while reverting the bw parameter, the SBC continues to use the original SDP, performing the inherent operation by referring to the payload type.
- If and end-station issues EVS-SWB within a re-INVITE, such as when the caller rejects the TrFO re-INVITE, the SBC does not perform this mapping function. The SBC only negotiates preconditions before the call is established, and clears them after it receives the final response for the INVITE.
Call Flows for Asymmetric Preconditions TrFo
The image below depicts the SBC performing TrFo with asymmetric preconditions, wherein the egress mode is send-with-nodelay.
- The UAC issues an invite with SDP that offers EVS, AMR-WB and AMR.
- The SBC, supporting asymmetric preconditions, forwards this list to the UAS, per SBC configuration. Note the use of thesend-with-nodelay mode causes the SBC to immediately send the INVITE.
- The SBC proceeds with confirming preconditions with the UAC.
- In the meantime, the UAS proceeds with agreeing to the call using AMR.
- The UAC and SBC confirm the call with transcoding.
- Immediately after confirming the call, the SBC triggers its TrFO function, changing the agreed upon codec to AMR with the UAC.
- The call proceeds without transcoding (TrFo).
The image below depicts the SBC performing TrFo with asymmetric preconditions and PRACK interworking, wherein the egress mode is send-with-nodelay.
- The UAC issues an invite with SDP that offers AMR and G729.
- The SBC, supporting asymmetric preconditions, forwards this list to the UAS, per SBC configuration. Note the use of the send-with-nodelay mode causes the SBC to immediately send the INVITE.
- The SBC proceeds with confirming preconditions with the UAC. This process specifies AMR as the codec agreed upon by the UAC and the SBC.
- In the meantime, the UAS proceeds with agreeing to the call using G729.
- The UAC and SBC confirm the call with transcoding.
- Immediately after confirming the call, the SBC triggers its TrFO function, changing the agreed upon codec to G729 with the UAC.
- The call proceeds without transcoding (TrFo).
The image below depicts the SBC performing TrFo with asymmetric preconditions, wherein the egress mode is send-with-delay.
- The UAC issues an invite with SDP that offers AMR and G729.
- The SBC, supporting asymmetric preconditions, forwards this list to the UAS, per SBC configuration. Note the use of the send-with-delay mode causes the SBC to hold the INVITE.
- The SBC proceeds with confirming preconditions with the UAC. This process specifies G729 as the codec agreed upon by the UAC and the SBC.
- After establishing preconditions and agreeing the G729 with the UAC, the SBC forwards the INVITE.
- The UAS proceeds with agreeing to the call using AMR.
- The UAC and SBC confirm the call with transcoding.
- Immediately after confirming the call, the SBC triggers its TrFO function, changing the agreed upon codec to AMR with the UAC.
- The call proceeds without transcoding (TrFo).
The image below depicts the SBC performing a simple TrFo process for a call flow with asymmetric preconditions. In addition, you have enabled the asymm-preconditions-evs-swb-support parameter in the sip-config.
- The UAC issues an invite with SDP that offers EVS-SWB and AMR. The SBC, supporting asymmetric preconditions, forwards to the UAS adding AMR-WB to the offered list, per SBC configuration.
- The UAS continues with the call while the SBC exchanges an UPDATE with the UAC.
- As the UAS proceeds with accepting the call using AMR, the SBC reverts from EVS-SWB to EVS-WB and proceeds with the call using transcoding. Note the enabled asymm-preconditions-evs-swb-support parameter allows the SBC to use EVS wideband instead of super-wideband without transcoding.
- The SBC recognizes AMS as an option and issues a re-INVITE, as described, the establish the leg using AMR.
- Once the leg is confirmed for AMR, the call proceeds without transcoding (TrFo).
