Avaya Attended-Transfer-Enable SPL

Legacy Oracle® Enterprise Session Border Controller software versions do not fully support the standard attended transfer scenario as it is described in RFC 5589, which describes best practices for call control and transfer of SIP-based call sessions. In a deployment in which the IP addresses on the public, or access, side of the Oracle® Enterprise Session Border Controller are not routable from the private or core sides, the flow will fail. The Attended-Transfer-Enable SPL addresses this issue.

Within an Avaya environment, each Avaya endpoint is known by a different URI on the access side of the Oracle® Enterprise Session Border Controller than it is on the core side. Currently, when the REFER message sent from the Transferor to the Transferee crosses from the access side to the core side, the URIs in the Refer-to and Referred-by headers are not changed from the URIs known on the access side to those known on the core side. Often this is easily overcome because the REFER that eventually reaches the Transferee still contains access-side URIs, which are known to the Transferee. Thus, the transferee can construct the INVITE correctly. In an environment in which some element of the core, such as an Avaya Session Manager (SM) or Call Manager (CM) has more control over the calls, this element may use the Refer-to and Referred-by URIs in its logic. For this reason, the Refer-to and Referred-by headers must contain the core-side URIs for those endpoints because the core element will have no knowledge of the access-side URIs

In order to control the flow properly, certain key URIs must be mapped from access-side to core-side and vice versa in the following messages:

• The REFER send from the Transferor to the Transfer Target
• The INVITE with Replaces header sent from the Transferee to the Transfer Target
• All subsequent requests sent from the Transferee to the Transfer Target in the dialog established by the INVITE with Replaces header

The Avaya Attended Transfer SPL provides RFC 5589 conformity by mapping access-side and core address as follows:

1. When transferor-->transfer target INVITE passes through the E-SBC from access to core, change the Refer-to URI from the access URI to the corresponding core URI.
2. When transferor-->transfer target INVITE passes through the E-SBC from access to core, change the Referred-by URI from the access URI to the corresponding core URI.
3. When transferor-->transfer target INVITE passes through the E-SBC from core to access, change the Refer-to URI from the core URI to the corresponding access URI
4. When transferor-->transfer target INVITE passes through the E-SBC from core to access, change the Referred-by URI from the core URI to the corresponding access URI.
5. When transferree-->transfer target INVITE with Replaces header passes through the SBC from access to core, change the Request-URI from the access URI to the corresponding core URI.
6. When transferree-->transfer target INVITE with Replaces header passes through the SBC from access to core, change the Referred-by URI from the access URI to the corresponding core URI.
7. When transferree-->transfer target INVITE with Replaces header passes through the SBC from core to access, change the Request-URI from the core URI to the corresponding access URI.
8. When transferree-->transfer target INVITE with Replaces header passes through the SBC from core to access, change the Referred-by URI from the core URI to the corresponding access URI
9. When any subsequent request in the dialog initiated by the INVITE with Replaces header passes through the SBC from access to core, change the Request-URI from the access URI to the corresponding core URI.
10. When any subsequent request in the dialog initiated by the INVITE with Replaces header passes through the SBC from core to access, change the Request-URI from the core URI to the corresponding access URI.