Service Provider SPLs
The following SPLs are available for service providers.
Universal Call Identifier SPL
The Universal Call Identifier SPL generates or preserves a UCID based on configuration. Once a UCID is generated or preserved, the system adds the value to subsequent egress SIP INVITE and ACK messages within the session. The SBC only inserts a UCID into methods it does not generate itself. Any methods that the SBC generates to send to the egress side do not have the UCID. You can also set the SPL to remove unwanted UCID headers to avoid duplicity in egress SIP requests.
Using the Universal Call Identifier SPL, you can identify requests within a particular session by manipulating the following vendor specific UCID headers:
- User-to-User
- Cisco-GUID
- Cisco-GUCID
- Genesys-UUID
The UCID is added as extension data to the session element of the recording’s metadata when using SIPREC.
You must configure one of the following SPL options for it to be enabled:
- UCID-App-ID
- GUID-Node-ID
- GUCID-Node-ID
- GenUUID-App-ID
Each SPL option allows you to set an identifying value, as defined by the vendors. The SPL does not validate any input for the SPL options. It is the responsibility of the Administrator to set the correct value.
You may further modify the action of the SPL by adding replace-ucid or convert-to or both to your SPL options.
Note:
The replace-ucid and convert-to options have no effect unless you also configure UCID-App-ID, GUID-Node-ID, GUCID-Node-ID, or GenUUID-App-ID.UCID-App-ID
The UCID-App-ID SPL option allows the Oracle Communications Session Border Controller (SBC) to examine ingress SIP requests for the “User-to-User” header. When present, the header is transparently passed through the egress SIP message. If set to replace-ucid or the header is not present, the system generates a new value for “User-to-User”.
You must set the value to a 2-byte hex-ascii value that represents the app ID. All input is truncated to 4 characters. Any characters outside the range of 0-9 and A-F will result in an invalid User-to-User header.
GUCID-Node-ID
The GUCID-Node-ID SPL option allows the Oracle Communications Session Border Controller (SBC) to examine ingress SIP requests for the Cisco-GUCID header. When present, the header is transparently passed through the egress SIP message. If set to replace-ucid or the header is not present, the system generates a new value for Cisco-GUCID.
You must set the value to a 48-bit node ID in the version 1 UUID defined by RFC 4122. You can enter the value in decimal or hexadecimal notation. The value must be prefixed with 0x when hexadecimal.
GUID-Node-ID
The GUID-Node-ID SPL option allows the Oracle Communications Session Border Controller (SBC) to examine ingress SIP requests for the Cisco-GUID header. If present, the header is transparently passed through the egress SIP message. The system generates a new value for Cisco-GUID if not present or the SPL option is set to replace-ucid.
You must set the value to a 48-bit node ID in the version 1 GUID defined by RFC 4122. You can enter the value in decimal or hexadecimal notation. The value must be prefixed with 0x when hexadecimal.
GenUUID-App-ID
The GenUUID-App-ID SPL option allows the SBC to examine ingress SIP requests for the “X-Genesys-CallUUID” header. When present, the header is transparently passed through the egress SIP message.
If you configure the option with the replace-ucid parameter or the header is not present, the system generates a new value for “X-Genesys-CallUUID”. The SBC replaces the Genesys UUID value only if the incoming message has a X-Genesys- CallUUID header. If the header is not present, the SBC adds the SIP header with the value equal to the generated/preserved UUID.
The uuid specified is a 33 byte unique string, including the \0 terminating symbol.
convert-to
The convert-to SPL option allows the Oracle Communications Session Border Controller (SBC) to examine ingress SIP requests for multiple UCID headers. This option has no effect unless appended to another SPL option.
You must set the convert-to SPL option to one of the following values:
- Avaya—Removes all Cisco-GUCID and Cisco-GUID headers from egress SIP requests.
- GUID—Removes all User-to-User and Cisco-GUCID headers from egress SIP requests.
- GUCID—Removes all User-to-User and Cisco-GUID headers from egress SIP requests.
- Genuuid—Remove any Avaya or Cisco UUID header and will add the XGenesys-CallUUID header.
Example SPL Options
The following are examples of the Universal Call Identifier SPL.
Example 1
UCID-App-ID=0023,replace-ucid,convert-to=AvayaThis creates a User-to-User header based on a node ID of 23. Any value on the ingress side is replaced with the newly generated value. Removes all Cisco-GUID and Cisco-GUCID headers from egress messages.
Example 2
GUID-Node-ID=0x124578,convert-to=GuidThis creates a Cisco-GUID header if one does not exist in the ingress request. Removes all User-to-User and Cisco-GUCID headers from egress messages.
Sample Metadata
The following sample shows metadata with new extension data added by the Universal Call Identifier SPL:
<extensiondata xmlns:apkt=http:/acmepacket.com/siprec/extensiondata>
<apkt:ucid>00FA08001900014E3E7D5C;encoding=hex</apkt:ucid>
</extensiondata>
<extensiondata xmlns:apkt=http:/acmepacket.com/siprec/extensiondata>
<apkt:ucid>C0934BE72BF711D6800285D16359919A</apkt:ucid>
</extensiondata>Configuring Universal Call Identifier Options
The SPL options must be configured on the ingress session-agent, realm-config, or sip-interface. If you update the values of the SPL options for the Universal Call Identifier SPL, you must perform a save and activate in order for the new option to take effect.
To configure the SPL options:
Inserting SIP Headers into SIPREC Metadata
The SIPREC Extension Data Enhancements SPL provides additional header information in the originating SIP messages metadata sent to the Interactive Session Recorder. With this SPL, you can introduce more options for recording policy decisions when using the SIPREC feature of the Oracle Communications Session Border Controller (SBC). The enhanced metadata also allows for the realm-id to be used as an indicator of the recording account. The SPL also provides configurable values that collect additional header information to store in the metadata.
When the SPL is configured, the SIPREC Extension Data Enhancements SPL is only triggered upon INVITE/UPDATE requests, and stores the additional header information in the metadata that is sent to the Interactive Session Recorder (ISR). Metadata is a XML MIME attachment that describes recording details to the ISR.
By default, the Extension-Headers SPL option collects only the Request-URI in a received INVITE. You can store additional header information by configuring the SPL with additional attributes in the spl-options under the global spl-config. The values must be in a comma separated list enclosed in double quotation marks. For example:
Extension-Headers="P-Asserted-Identity,Diversion"This configuration of the Extension-Headers option adds the originating Request-URI along with all P-Asserted-Identity and Diversion-Headers into the participant section of the metadata.
You can configure the LRE-Identifier SPL option to add an identifier of the logical remote entity (LRE) that triggered the recording to the <apkt:realm> element of the extension metadata. When configured with a value added, the value appears in place of the identifier. When configured without a value, the identifier of the logical remote entity is used. For example, session-agent will be the hostname, realm-config will be the realm, and sip-interface will be the realm name.
Note:
Both options are required for the SPL to function properly.Sample Metadata
The sample below shows metadata with new extension data added by the SIPREC Extension Data Enhancements SPL:
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns="urn:ietf:params:xml:ns:recording">
<datamode>complete</datamode>
<session id="BYiC7uSZQGN3VQdzWI1HWw==">
<associate-time>2012-06-26T13:44:13</associate-time>
</session>
<participant id="hq18GJs3TtJdhjPsfPNV8A==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<nameID aor="sip:sipp@192.168.10.1">
<name>sipp</name>
</nameID>
<send>aD50KX+LTvxNzASg+/GQTg==</send>
<associate-time>2012-06-26T13:44:13</associate-time>
<extensiondata xmlns:apkt="http://acmepacket.com/siprec/extensiondata">
<apkt:callingParty>true</apkt:callingParty>
<apkt:request-uri>sip:service@192.168.101.13:5060 </apkt:request-uri>
<apkt:in-realm>net192</apkt:in-realm>
<apkt:header label="P-Asserted-Identity">
<value>sip:mike@acme.com</value>
<value>sip:bob@cisco.com</value>
</apkt:header>
<apkt:header label="Diversion">
<value><sip:jojo@divert.com>;happy=days;green=envy</value>
<value><sip:bebe@MediaTen.net>;green=monster;go=carts</value>
<value><tel:+8675309;night=mare>;gear=head;green=monitor</value>
</apkt:header>
</extensiondata>
</participant>
<participant id="Ki6WEUi4TPRUPLtEaEhA7Q==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<nameID aor="sip:service@192.168.101.13">
<name>sut</name>
</nameID>
<send>f9NDVhyMTul+ePlM2SceQA==</send>
<associate-time>2012-06-26T13:44:13</associate-time>
<extensiondata xmlns:apkt="http://acmepacket.com/siprec/extensiondata">
<apkt:callingParty>false</apkt:callingParty>
</extensiondata>
</participant>
<stream id="aD50KX+LTvxNzASg+/GQTg==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<label>65804</label>
<mode>separate</mode>
<associate-time>2012-06-26T13:44:13</associate-time>
</stream>
<stream id="f9NDVhyMTul+ePlM2SceQA==" session="BYiC7uSZQGN3VQdzWI1HWw==">
<label>65805</label>
<mode>separate</mode>
<associate-time>2012-06-26T13:44:13</associate-time>
</stream>
</recording>Configure SIP Headers for SIPREC Metadata
To get more detailed information about a recorded session, you can add more SIP headers within the SIPREC metadata by way of the Extension-Headers option. The default behavior stores only the Request-URI and realm-id.
You must configure the Extension-Headers option at the global level under spl-config because the session-agent, realm-config, and sip-interface configurations do not recognize the option. The first time you configure one or more extension headers, you need only to save and activate the configuration for the system to recognize the extension headers. When you modify the existing SPL extension header list you need to save and activate the configuration, and reboot the system for the changes to take effect. Real Time Configuration (RTC) does not apply to extension header options.
Configure LRE for SIPREC Metadata
The LRE-Identifier option may be configured on each session-agent, realm-config, or sip-interface that interacts with the session recording server. This option is not recognized in the global spl-config. This option is required for SPL functionality.
To configure the LRE-Identifier option:
SBC Deployment Behind a NAT Device
Use the Support for SBC Behind NAT SPL plug-in for deploying the Oracle Communications Session Border Controller (SBC) on the private network side of a Network Address Translation (NAT) device. The Support for SBC Behind NAT SPL plug-in changes information in SIP messages to hide the end point located inside the private network. The specific information that the Support for SBC Behind NAT SPL plug-in changes depends on the direction of the call, for example, from the NAT device to the SBC or from the SBC to the NAT device.
Configure the Support for SBC Behind NAT SPL plug-in for each SIP interface that is connected to a NAT device. One public-private address pair is required for each SIP interface that uses the SPL plug-in, as follows.
- The private IP address must be the same as the SIP Interface IP address.
- The public IP address must be the public IP address of the NAT device.
The following illustrations show the SBC deployed in the private network behind a NAT device, using the Support for SBC Behind NAT SPL plug-in. Examples follow each illustration to show where the Support for SBC Behind NAT SPL plug-in changes the SIP message information.
Call Initiated on the Access Side
In the following illustration, UA1 invites UA2 to a session and UA2 responds.
-
UA1 sends an INVITE through the NAT device to the SBC with the following message.
INVITE sip:service@10.0.0.99:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK-3539-1-0 Contact: sip:sipp@10.0.0.1:5060 … Content-Type: application/sdp o=user1 53655765 2353687637 IN IP4 10.0.0.1 c=IN IP4 10.0.0.1 …The Support for SBC Behind NAT SPL plug-in looks for the public SIP Interface IP address 10.0.0.99 in R-URI, Via, Contact, and SDP. The SPL plug-in finds 10.0.0.99 in R-URI and changes it to the private SIP Interface IP address 192.168.0.1.
INVITE sip:service@192.168.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK-3539-1-0 Contact: sip:sipp@10.0.0.1:5060 … Content-Type: application/sdp o=user1 53655765 2353687637 IN IP4 10.0.0.1 c=IN IP4 10.0.0.1 … -
The SBC sends a Reply to UA1.
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.1:5060;received=192.168.0.70;branch=z9hG4bK-3539-1-0 Contact: <sip:192.168.0.1:5060;transport=udp> Content-Type: application/sdp … o=user1 53655765 2353687637 IN IP4 192.168.0.1 c=IN IP4 192.168.0.1 …The Support for SBC Behind NAT SPL plug-in looks for the private SIP interface IP address 192.168.0.1 in R-URI, Via, Contact, and SDP. The SPL plug-in finds 192.168.0.1 in Contact and SDP and changes it to the public IP 10.0.0.99.
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.1:5060;received=192.168.0.70;branch=z9hG4bK-3539-1-0 Contact: <sip:10.0.0.99:5060;transport=udp> Content-Type: application/sdp … o=user1 53655765 2353687637 IN IP4 10.0.0.99 c=IN IP4 10.0.0.99 …
Call Initiated on the Core Side
In the folowing illustration, UA2 invites UA1 to a session and UA1 responds.
-
The SBC sends an Invite to UA1.
INVITE sip:service@10.0.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9hG4bKbgs21h30a8kh8okcv790.1 Contact: <sip:sipp@192.168.0.1:5060;transport=udp> Content-Type: application/sdp … o=user1 53655765 2353687637 IN IP4 192.168.0.1 c=IN IP4 192.168.0.1 …The Support for SBC Behind NAT SPL plug-in looks for the private IP address 192.168.0.1 in R-URI, Via, Contact, and SDP. The SPL plug-in finds 192.168.0.1 in Via, Contact, and SDP and changes it to the public IP address 10.0.0.99.
INVITE sip:service@10.0.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.99:5060;branch=z9hG4bKbgs21h30a8kh8okcv790.1 Contact: <sip:sipp@10.0.0.99:5060;transport=udp> Content-Type: application/sdp … o=user1 53655765 2353687637 IN IP4 10.0.0.99 c=IN IP4 10.0.0.99 … -
UA1 sends a Reply to the SBC.
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.99:5060;branch=z9hG4bKbgs21h30a8kh8okcv790.1 Contact: <sip: 10.0.0.1:5060;transport=UDP> Content-Type: application/sdp … o=user1 53655765 2353687637 IN IP4 10.0.0.1 c=IN IP4 10.0.0.1 …The Support for SBC Behind NAT plug-in looks for the public IP 10.0.0.99 in R-URI, Via, Contact, and SDP. The SPL plug-in finds 10.0.0.99 in Via, changes it to the private SIP interface IP address 192.168.0.1.
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9hG4bKbgs21h30a8kh8okcv790.1 Contact: <sip: 10.0.0.1:5060;transport=UDP> Content-Type: application/sdp … o=user1 53655765 2353687637 IN IP4 10.0.0.1 c=IN IP4 10.0.0.1 …
Configure the SBC Behind a NAT Device Option
Configure one public-private address pair for each SIP interface that uses the Support for SBC Behind NAT SPL plug-in, as follows.
- The private IP address must be the same as the SIP interface IP address.
- The public IP address must be the public IP address of the NAT device.
Before You Begin
- Confirm that the SIP interface is configured.
- Confirm that you are in the Superuser mode.
To configure the SIP interface IP addresses:
Surrogate Registration
- dyn-contact-start—Configure on the sip-interface facing the CUCM realm.
- dyn-contact-method=randomseed—Configure on the sip-interface facing the NTT trunk.
When configured, the SBC:
- Sends the IP address of the egress sip-interface in the host part of the Call-ID within SIP INVITE requests to KDDI.
- Removes the string “sbc” from the host part of the Call-ID while sending out de-REGISTER requests.
- Adds the egress sip-interface IP address to the host part of the call-id.
- Sends two de-REGISTERs messages with at least a 1 second interval for the same AOR.
SPL functions persist after a reboot.
Note:
These features make use of the SurrogateContact SPL. When using this SPL, triggered by the configurations described below, the system supports only one surrogate agent within the entire configuration.NTT Message Converter
When required by your service provider, set spl-options to +NttMsgConverter.
- ocNttMsgConverterTagging=opposite—Configure on the sip-interface facing the Unified Call Manager (CUCM) realm.
- dyn-contact-start—Configure on the sip-interface facing the CUCM realm.
- dyn-contact-method=randomseed—Configure on the sip-interface facing the NTT trunk.
To support these trunks, you load all of these SPLs on the appropriate sip-interface elements. When configured, these SPLs trigger the following functions by the SBC:
- As a part of the surrogate registration process, sends a unique, random user-info portion in every REGISTER request to the NTT SIP trunk as well as within outgoing INVITE messages for calls.
- Applies validity check to an incoming INVITE from the SIP trunk before sending out 100 TRYING and subsequent 1xx, 2xx messages. It is expected that the incoming INVITE Request-URI user portion contains the same randomized value that the SBC sent in the most recent REGISTER message to the trunk.
- In compliance with NTT requirements, sets the tag size of From and To headers in the SIP messages to be less than 32 bytes. This resolves issues with, for example, the tags sent by Avaya in originating SIP messages, which are approximately 51 bytes.
- In compliance with NTT requirements, sets the Rseq, Cseq, Session ID (in SDP) values less than 999900, and sets the SDP o line username character length to a maximum of 10 bytes. This resolves issues with, for example, messages from an Enterprise PBX with a large RSeq value in 18x messages. This also resolves issues with the SDP o line generated by some Enterprise PBXs, which have a username that is 19 bytes.
- Checks the RURI user portion of incoming CANCEL request for the AoR and compares it with the AoR specified in the Request-URI of the initial INVITE received. If the value is different, the SBC responds with a 481 Call/Transaction Does Not Exist.
Note:
These features make use of the SurrogateContact SPL. When using this SPL, triggered by the configurations described below, the system supports only one surrogate agent within the entire configuration.Emergency Location Identification Number (ELIN) Gateway Support
An ELIN-capable gateway supports connection to a qualified E911 service provider. The connection supports PSTN-based E911 functions, including user callback when there is a disconnect. Enterprises often deploy ELIN numbers based on physical location to locate the physical source of a 911 call. By using multiple ELINs, an enterprise can support multiple, simultaneous E911 calls.
Typically, an enterprise purchases multiple ELIN numbers. An ELIN gateway replaces VoIP extension URIs with ELIN numbers and maintains the mapping. For example, if an emergency service replied to a VoIP URI without using an ELIN gateway, the reply would be delayed or fail. An ELIN gateway can use its mapping to translate the ELIN number back to the VoIP extension from within the enterprise session network. The gateway can immediately forward the call back to the original client.
The Oracle Communications Session Border Controller supports E911 ELIN for Lync-enabled Enterprises using the ELIN_Gateway SPL option. Enable this option in the global SPL configuration. The Oracle Communications Session Border Controller supports up to 300 ELIN numbers simultaneously and it can reuse numbers allowing a greater number of emergency calls.
Note:
This ELIN Gateway SPL is not supported by the Oracle Communications Session RouterHow the Emergency Location Identification Number (ELIN) SPL Works
When a Lync client places a 911 emergency call through a mediation server to a Oracle Communications Session Border Controller (SBC), the server indicates the emergency status in the priority field and provides a list of ELIN numbers. When the ELIN gateway module is enabled, the SBC intelligently selects a particular ELIN number and uses it as the ANI in the “From” field SIP URI in the outgoing INVITE.
The SBC preserves the mapping of used ELIN numbers in an internal table. This table includes the ELIN number, the caller (VoIP extension), the “in-use” count, and a timer field. The SBC retains these mappings for a configurable time period ranging from 30 to 60 minutes after the call is terminated. The default is 30 minutes. When the timer expires, the entry is purged from the table. The timer field shows the time of day that the timer started.
You can view the current ELIN table at any time using the ACLI command
spl show sip elins.
After the Lync client call is disconnected, the 911 service may call back using the number provided in the “From” field of the original INVITE. This presence of this number in its ELIN number table allows the SBC to route the call back to the original caller.
Number Reuse
The SBC can use an ELIN number for multiple calls. When a call that requires an ELIN mapping arrives at the SBC, it checks to see if the numbers presented by the mediation server are in use. If a number is not in use, it simply uses that number. A number is not in use if it is not in the table or its “used count” is 0. An entry’s used count is zero when its not in use and its purge timer has not yet expired.
- If the “caller” is in the ELIN table, the SBC selects that mapping.
- The SBCselects the number with the lowest “ELIN count”.
If an ELIN number is used by multiple calls, it maps callback attempts to that ELIN number to the client that was last associated with the number.
Error Handling
Lync mediation servers always expect 503 “Service Unavailable” as an error message to a failed ELIN call. There is a variety of error messages that the network may send back when a call fails. For the purposes of Lync support, the SBC sends 503 “Service Unavailable” to indicate call failure to a mediation server, regardless of the error it receives.
PSAP Callback Options
When you enable the ELIN gateway, the SBC does not support Public Safety Answering Point (PSAP) callback handling to numbers that are not in the PSAP callback list, which includes 911, 112 and any number you have added. You can, however, further configure the SBC to support such callbacks for scenarios wherein the PSAP service does not use a known emergency number or uses "anonymous" as the FROM. You can also configure the SBC to replace the request-URI in a PSAP callback to resolve routing issues. You enable global SPL options for these configurations.
By default, the SBC creates entries in its ELIN table using the ELINs it finds in the PIDF and the FROM in an emergency INVITE. If the call terminates unexpectedly, the emergency service may make a PSAP callback towards the calling station. When the SBC receives a PSAP callback, it performs PSAP callback handling only if the callback's FROM is in its PSAP callback list. The SBC then uses the mapping of the ELIN number and the source number to determine where to send its INVITE by setting the TO, and, if configured, the request-URI.
When enabled, the Elin-Ignore-PSAP-Source SPL option modifies the processing flow the SBC uses to identify a PSAP callback and forward its ensuing INVITE. When the SBC receives an INVITE, it first checks to see if you have enabled this option.
- When Elin-Ignore-PSAP-Source is enabled, the SBC identifies an emergency call if the INVITE includes a Priority: emergency header and a destination to 911, 112 or a number you have added using Elin-Add-PSAP option.
- When Elin-Ignore-PSAP-Source is not enabled, the SBC identifies an emergency call only if the INVITE includes a Priority: emergency header.
If the call is not an emergency call, the default behavior checks the source. If the source is 911, 112 or a number you have added using Elin-Add-PSAP option, the system sends the call to its PSAP callback handling logic, ultimately forwarding the call using the ELIN mapping table to replace the TO from the ELIN to the mapped target number.
In contrast, if the system finds you have enabled Elin-Ignore-PSAP-Source, it sends the all calls that are not emergency calls to PSAP callback handling. At this point, further PSAP callback handling is the same whether or not you have configured Elin-Ignore-PSAP-Source. If there is no ELIN mapping table match, the system forwards the call as a normal INVITE.
Handling of PSAP callbacks always includes updating the To-URI from the ELIN to the target number. This handling optionally includes updating the request-URI to the target number. Applicable option definitions include:
- Elin-Ignore-PSAP-Source—Allows the SBC to forward a PSAP callback from any number, uncoupling the PSAP callback with the source of the incoming INVITE.
- Elin-Modify-RURI—Allows the SBC to change the request-URI to match the TO during a PSAP callback scenario. This can allow the system to successfully forward the callback by replacing the request-URI with the original TO.
These options are global. You configure these features using the spl-options branch under the global spl-config. The system does not offer these options within realm, interface or session agent elements.
Processing the Elin-Ignore-PSAP-Source SPL Option
When the SBC receives a call, it first determines whether you have enabled the Elin-Ignore-PSAP-Source option.
- If not, the SBC checks for
a Priority:emergency header:
- If true, the SBC performs emergency call handling and updates the ELIN mapping table based on this emergency call.
- If not true, the SBC checks whether the source is 911, 112 or a PSAP number
you configured with the Elin-Add-PSAP option.
- If true, the SBC performs a PSAP call back and a "To" header
modification.
- The SBC does or does not modify the request-URI, based on the state of the Elin-Modify-RURI option. (See below.)
- The SBC modifies the TO header.
- The SBC forwards the call.
- If not true, the SBC treats this call as a normal call and forwards it without any modifications.
- If true, the SBC performs a PSAP call back and a "To" header
modification.
- If you have enabled the
Elin-Ignore-PSAP-Source option, the SBC checks for Priority:emergency header
and whether the destination is in the PSAP callback list (911, 112 or PSAP
numbers you configured using the Elin-Add-PSAP
option):
- If true, the SBC performs emergency call handling and updates the ELIN mapping table based on this emergency call.
- If not true, the SBC
passes the call to PSAP callback and performs an ELIN table lookup:
- If there is no match in the ELIN table, the SBC hands the call to local policy and forwards it as a normal call.
- If there is a match:
- The SBC does or does not modify the request-URI, based on the state of the Elin-Modify-RURI option. (See below.)
- The SBC modifies the TO header.
- The SBC forwards the call.
At this point, the SBC has supported PSAP callback without needing to know the call's source.
Processing the Elin-Modify-RURI SPL Option
Regardless of your Elin-Ignore-PSAP-Source setting, the SBC refers to the Elin-Modify-RURI option only if processing comes to the point where the system has found a match in the ELIN table. If so, the system would currently be supporting a PSAP callback based on an ELIN table lookup. At this point, the SBC checks to see if you have enabled Elin-Modify-RURI.
- If not, the SBC:
- Performs a routing lookup to identify routes.
- Updates the To header with the FROM in the ELIN table.
- Forwards the PSAP callback.
- If so, the SBC:
- Changes the request-URI to the FROM in the ELIN table.
- Performs a routing lookup to identify routes.
- Updates the To header with the FROM in the ELIN table.
- Forwards the PSAP callback.
Note:
This option has no impact on emergency call handling.Configuration
You configure the Elin-Ignore-PSAP-Source and Elin-Modify-RURI SPL options using the spl-options branch under the global spl-config. You must also configure the system to use the ElinGateway SPL:
ORACLE(spl-config)#spl-options +Elin-Gateway=60
ORACLE(spl-config)#spl-options +Elin-Ignore-PSAP-Source
ORACLE(spl-config)#spl-options +Elin-Modify-RURI
PSAP Callback Call Flows
Call flows for PSAP callbacks include the contents of SIP messages and detail on the processing.
In all the cases below, the SBC modifies the “FROM” number in its INVITE to the PSAP to the ELIN number, creates an entry in the ELIN mapping table, and forwards the INVITE.
Note:
When you have enabled the Elin-Ignore-PSAP-Source option and a call arrives at the SBC with a “PRIORITY: emergency” header and a random, non-emergency number in the TO, the SBC would not handle this call as an emergency and not use the ELIN gateway function.PSAP Callback with No Options Set
This call flow depicts the system not forwarding a PSAP call back because you have not configured Elin-Modify-RURI.
PeerA has sent an emergency call to 911. In addition, there is no local policy configured that matches a to-address with the ELIN number 7774442211. The SBC identifies the call from PeerA as an emergency call since it contains “PRIORITY: emergency” header. It modifies the “FROM” number in INVITE request to the ELIN number, and forwards the INVITE. The SBC receives the PSAP callback from 911, but replies with no route found because there is no local route that matches 7774442211.
This next call flow depicts the system not forwarding a PSAP call back despite the system having a local-policy with to-address of 9991112222. The flow is the same as above, with the exception that the PSAP has initiated a callback using a 8884445555 as the FROM.
The SBC receives the PSAP callback with 8884445555 as the FROM. The SBC does not find 8884445555 in its PSAP callback table because it has not been added using Elin-Add-PSAP. In addition, the Elin-Ignore-PSAP-Source option is not set, so the system exits PSAP callback handling and treats the call as a normal call. Ultimately, there is no route to the ELIN, 7774442211.
This call flow would succeed if both of the following were true:
- You had enabled the Elin-Ignore-PSAP-Source SPL option, which would have ignored the PSAP from and proceeded with performing an ELIN mapping table lookup.
- You had enabled the Elin-Modify-RURI SPL option, which would have replaced the request-uri with 9991112222.
PSAP Callback with Both Options Enabled
This next call flow depicts the system forwarding a PSAP call back using both the Elin-Ignore-PSAP-Source and Elin-Modify-RURI SPL options.
This flow is the same as the example directly above, with the exception that you have enabled both SPL options.
The SBC receives the PSAP callback with 8884445555 as the FROM. The SBC ignores this FROM because you have enabled Elin-Ignore-PSAP-Source. The SBC proceeds with PSAP callback handling. It finds a match for 7774442211 in the ELIN mapping table and proceeds. The SBC changes the request-uri in its subsequent INVITE to 9991112222 because you have enabled Elin-Modify-RURI. Standard ELIN handling also changes the TO header in its subsequent INVITE to 9991112222.
The use of both of these options allows this call flow to succeed.
Configure the ELIN Gateway Options
To enable an Emergency Location Identification Number (ELIN) gateway to support connections to an emergency service provider, you must configure the ELIN gateway option on the (SBC). Oracle delivers the SBC pre-configured with the 911 and 112 Public Safety Answering Point (PSAP) callback numbers. You can add more PSAP numbers, as needed. You can also specify the length of time that you want the SBC to retain ELIN mappings.
- Determine the preferred length of time, in minutes, that you want the SBC to retain ELIN mappings.
- Determine whether or not you want to add more PSAP callback numbers.
- The Elin-Ignore-PSAP-Source and Elin-Modify-RURI spl-options are available in the ElinGateway.1.8.spl version and higher. Determine your current plugin version to determine whether you need to remove any existing ELIN plugin configuration from the SBC and reboot before performing this configuration.
The SBC requires ELIN configuration at the global level, rather than at the session-agent, realm-config, or sip-interface level. Select the spl-config option under system for this ELIN configuration. In the following configuration you can set the time limit for retaining ELIN mappings and you can add more PSAP callback numbers.
To configure the ELIN Gateway option:
Comfort Noise Generation SPL
Comfort noise (CN) is the noise in a Real Time Transport Protocol (RTP) message (defined in RFC 3389) that is played to prevent a user from hearing completely dead silence on the connection. The Session Description Protocol (SDP) negotiates this RTP message containing the comfort noise using payload type 13 and an rtpname of "CN".
However, when CN is received, normal RTP ceases. Thus, with no RTP traffic, guard timers may trigger and cause the call to be terminated. To correct this, you can load a Comfort Noise Generation SPL that allows the Oracle Communications Session Border Controller (SBC) to generate "noise" RTP using the normal audio codec when it receives a CN indication.
After loading the SPL on the SBC, comfort noise is added and removed from the SDP to allow for proper negotiation. If properly negotiated in SDP, CN interworking facility (IWF) is enabled in the media flows allowing the SBC to generate noise RTP when CN is received.
Note:
CN generation configuration is supported on realms only.The following describes two different cases of how the SBC performs the SDP manipulation using the CN Generation SPL.
Case 1
- SDP offer received from the realm that has comfort-noise-generate enabled. If the SDP offer contains CN, no IWF is required. If it does not contain CN, and at least one of the offered audio codecs is PCMU or PCMA, CN is added in outgoing SDP offer.
- If SDP Answer contains the CN codec and topmost audio codec is PCMU or PCMA, SBCenables CN IWF.
- SBC strips CN from outgoing SDP Answer.
Case 2
- SDP offer is sent to a realm that has comfort-noise-generate enabled. If CN was not offered, IWF cannot be performed. If CN is in the offer, the SBC forwards the offer to the outbound side.
- SDP Answer is received from a realm that has comfort-noise-generate enabled. If it contains CN, no IWF is required because both sides support CN. If there is no CN in the Answer, and the topmost audio codec is PCMU or PCMA, the SBC enables CN IWF.
- If CN IWF is enabled, the SBC adds CN to the outgoing SDP Answer.
Configure the Comfort Noise Generation SPL
Use the following procedure to configure the CN Generation SPL on the SBC.
Example Configuration
The following is an example of a CN Generation SPL configuration.
media-manager
realm-config
identifier SP
addr-prefix 172.16.0.0/16
network-interfaces Core1:0
mm-in-realm enabled
spl-options comfort-noise-generateHigh Availability (HA) Support
High Availability (HA) supports the use of Comfort noise. The codec encoding (PCMU/PCMA), codec ptime, and CN generation enabled/disabled state is exchanged with the standby in Middlebox Control Daemon (MBCD). If CN generation occurs in a call flow, and a switchover occurs, the CN generation stops until the next CN message is received.
Licensing Information
The following licensing applies to the CN Generation SPL.
| Process | Description |
|---|---|
| Package name | G711 |
| License category | Open Source |
| Package version | N/A |
| Vendor | Sun Microsystems |
| Applicable license | This source code is a product of Sun
Microsystems, Inc. and is provided for unrestricted use. Users may copy or
modify this source code without charge.
SUN SOURCE CODE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. Sun source code is provided with no support and without any obligation on the part of Sun Microsystems, Inc. to assist in its use, correction, modification or enhancement. SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY THIS SOFTWARE OR ANY PART THEREOF. In no event will Sun Microsystems, Inc. be liable for any lost revenue or profits or other special, indirect and consequential damages, even if Sun has been advised of the possibility of such damages. Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, California 94043 |
| Software builds | SC[z]
BC[z]640 |
| Purpose | Conversion from linear samples to alaw/ulaw |
| Used in modified or unmodified form | Unmodified |
| Used internally or distributed | Distributed with Product Binaries |
| Location in source code tree | linux/kernel/modules/acme |
| Used by itself or in combination with other software | Used exclusively and tightly integrated into acme.ko. The code is compiled as part of acme.ko. |
| Link to website hosting Software | N/A |
| License requires notice provided in product documentation? | No |