RFC2833 and KPML Interworking

Keypad Markup Language (KPML) is used to indicate DTMF tones in SIP messaging. KPML is used by the Key Press Stimulus Package as a SIP Event Notification Package, transmitting DTMF tone indications via NOTIFY messages. You can configure the Oracle® Enterprise Session Border Controller (E-SBC) to perform Event Notification with an endpoint on one call leg and perform digit encapsulation to RFC 2833 telephone-events on the other call leg.

KPML to RFC2833

KPML to RFC2833 interworking requires that the INVITE request or response's SDP does not contain telephone-event, and is received from

A session agent with kpml-interworking set to enabled
A session agent with kpml-interworking set to inherited from the SIP interface (with kpml-interworking set to enabled)
A previous hop that is not a session agent, and the SIP interface the message received on has kpml-interworking set to enabled.

The egress side of the call must have rfc2833-mode set to preferred in either the SIP interface or session agent, so that the E-SBC inserts telephone-event in the SDP. Setting rfc2833-mode to dual is unsupported for KPML interworking. The answerer must respond to the invite, accepting the telephone-event media. The Allow-Event: kpml header is removed from the INVITE request or response when KPML-interworking is not set to enabled on the next hop.

If the INVITE succeeds, the E-SBC replies with a SUBSCRIBE request for the KPML event to the caller.

If the caller replies to the SUBSCRIBE with a 2xx, all subsequent NOTIFY request received on the dialog are processed and replied to with a 200 OK. Each digit in the NOTIFY request will generate a telephone-event on the egress side of the call.

The E-SBC generates a refresh SUBSCRIBE before the subscription expires.

If the call negotiates to RFC 2833, no KPML interworking is performed.

The following diagram shows the standard case where KPML to RFC 2833 interworking is performed.

KPML to RFC 2833 translation is also supported when used in conjunction with SDP insertion on the KPML side of the call. For example:

RFC 2833 to KPML

RFC2833 to KPML interworking requires that the INVITE request or response's does not contain Allow-Event: kpml. When sending an INVITE when RFC2833 interworking applies, an Allow-Event: kpml header is added to the INVITE when the message's next hop on egress is either :

A session agent with kpml-interworking set to enabled
A session agent with kpml-interworking set to inherited from the SIP interface (with kpml-interworking set to enabled)
Not a session agent, and the SIP interface the message is sent from has kpml-interworking set to enabled.

If the scenario passes the above test and the Allow-Event: kpml header is added to the INVITE:

When the E-SBC subsequently receives a SUBSCRIBE request within the INVITE created dialog for the kpml event, it accepts the subscription and responds with a 200 OK. At this point, the E-SBC can generate a KPML NOTIFY request with a KPML digit corresponding to each 2833 telephone-event received from the far end until:

The INVITE dialog is terminated due to a BYE;
The subscription expires; or
The subscription is terminated with a subscribe request Expires: 0.

The following diagram shows a typical RFC2833 to KPML interworking call flow. Note the following:

While the example has SDP in the INVITE, delayed offer scenarios where the SDP exchange occurs in the 20 0OK and the ACK are supported
The rfc2833-mode parameter in the in either the SIP interface or session agent, is considered in the interworking. See next section:
If the call negotiates to RFC 2833 to RFC 2833, no KPML interworking is performed.
In RFC 2833 to KPML scenarios, if the SUBSCRIBE is not received quickly enough, RFC 2833 digits are dropped.

Originator	Terminator	SBC Behavior
rfc2833-mode=transparent, offers 2833 SDP	rfc2833-mode=transparent, answers NO 2833 SDP	Forwards 2833 offer, Adds `Allow-Event: kpml`, passes non-2833 capability to Originator (no 2833 support)
rfc2833-mode=preferred, offers 2833 SDP	rfc2833-mode=transparent, answers NO 2833 SDP	Forwards 2833 offer, Adds `Allow-Event: kpml`, inserts 2833 capability to Originator, performs 2833 to KPML translation
rfc2833-mode=transparent, offers 2833 SDP	rfc2833-mode=preferred, answers NO 2833 SDP	Forwards 2833 offer, Adds `Allow-Event: kpml`, passes non-2833 capability to Originator (no 2833 support)
rfc2833-mode=preferred, offers 2833 SDP	rfc2833-mode=preferred, answers NO 2833 SDP	Forwards 2833 offer, Adds `Allow-Event: kpml`, inserts 2833 capability to Originator, performs 2833 to KPML translation

Interworking RFC 2833 and KPML for Hairpin Sessions

The E-SBC supports RFC 2833-KPML interworking scenarios that include forwarded calls that hairpin to an endpoint out the original interface. If the initial callee supports one of these digit encapsulation methods, and the caller and final callee support the other, the default E-SBC behavior of preferring RFC 2833 may block the KPML digit tranmission. You can configure the E-SBC to support interworking within these hairpin scenarios in the egress direction.

Forwarded hairpin calls can cause a problem to RFC 2833-to-KPML interworking for which the E-SBC can recognize and compensate. The issue exists for both RFC 2833-to-KPML and KPML-to-RFC 2833 calls, wherein a called endpoint that requires this interworking forwards the call back to the E-SBC, which hairpins the call to an endpoint that supports the initial encapsulation.

By default, the E-SBC uses RFC 2833 for digit transmission if there is an SDP attribute that includes telephone-event. This remains true even if there is also an allow event parameter set to kpml. The above scenario results in an SDP that includes both, causing the E-SBC to present digit encapsulation towards the KPML endpoint within RFC 2833 RTP.

To compensate for environments that need to support this hairpin forwarding, you can enable the kpmlRFC2833-iwf-on-hairpin parameter on the applicable session-agent or sip-interface. When configured for this hairpin support:

RFC 2833-to-KPML with hairpin to a RFC 2833 endstation—Although the E-SBC receives an SDP answer that supports both KPML and RFC 2833 from KPML side, it honors the SUBSCRIBE request from the KPML endpoint and generates NOTIFY requests with DTMF digits towards the KPML end point.
KPML-to-RFC 2833 with hairpin to a KPML endstation—Although the E-SBC receives an SDP offer that supports both KPML and telephone event from the KPML endpoint, it sends NOTIFY requests with the DTMF digits towards the RFC 2833 end point.

The diagram below shows an endpoint supporting RFC 2833 initiating a call, which terminates via hairpin on another RFC 2833 endpoint. The call initially targets an endpoint supporting KPML, but is forwarded back to the E-SBC. SDP2 includes the KPML allow event parameter and the telephone-event attribute. But this configuration causes the E-SBC to send digits to the KPML endpoint using NOTIFY message, and encapsulate those same digits in RTP for the RFC 2833 endpoints.

Bi-Directional Subscriptions

Within the context of hairpinned sessions that starts from a KPML endpoint and ultimately targets a KPML endpoint, the E-SBC both accepts the SUBSCRIBE from the called endpoint, and sends a SUBSCRIBE to the calling endpoint. In the diagram below, The E-SBC hairpins a call originating from a KPML endpoint, towards an RFC 2833 endpoint, and back out the initial interface to another KPML endpoint. Within the context of the INVITE signaling, the E-SBC issues and receives KPML SUBSCRIBE messages from both endpoints. Given the preference outlined in RFC 4370 that KPML subscriptions be unique to each DIALOG, the E-SBC monitors the local tag (From:) to discriminate between subscriptions, thereby supporting bi-directional subscriptions.

Configuration Considerations

You configure this support by enabling the kpmlRFC2833-iwf-on-hairpin parameter on the applicable sip-interface and/or session-agent.

Important configuration considerations include:

Set the rfcRFC 2833-mode parameter to preferred on the leg with the RFC 2833 endpoint.
Set the kpml-interworking and kpmlRFC2833-iwf-on-hairpin parameters to enabled on the leg with the KPML end point.
The session-agent configuration takes precedence.
If you target a configured session-agent and configure this interworking on the sip-interface, configure kpml-interworking to inherit on the session-agent.

KPML-2833 Interworking on a SIP Interface Configuration

To configure KPML - 2833 interworking on a SIP interface:

Access the sip-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#

Select the sip-interface object to edit.

ORACLE(sip-interface)# select
<RealmID>:
1: realm01 172.172.30.31:5060

selection: 1
ORACLE(sip-interface)#

kpml-interworking—Set this parameter to enabled to use KPML-2833 interworking.
Type done to save your configuration.

KPML-2833 Interworking on a Session Agent Configuration

To configure KPML - 2833 interworking on a session agent:

Enter the prerequisites here (optional).

Enter the context of your task here (optional).

Access the session-agent configuration element.

ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-agent
ORACLE(session-agent)

Select the session-agent object to edit.

ORACLE(session-agent)# select
<hostname>:
1: 192.168.100.101:1813

selection: 1
ORACLE(session-agent)#

kpml-interworking—Set this parameter to enabled for the Oracle® Enterprise Session Border Controller to interwork RFC2833 from the other call leg to the call leg running through this session agent. This parameter may be set to inherit to use the kpml-interworking value configured on the receiving SIP interface.
Type done to save your configuration.