Cisco Adapter and Diversion Type Adapter

Last Updated : Dec 04, 2023 |

Cisco Adapter (CiscoAdapter) provides two basic header manipulations: converting between Diversion and History-Info headers and converting between P-Asserted-Id and Remote-Party-Id headers. IETF does not accept Diversion and Remote-Party-Id headers. The Diversion and Remote-Party-Id headers are replaced by History-Info and P-Asserted-Identity respectively but are still used in the Cisco products. Cisco Adapter also performs all the conversions available by the Digit Conversion Adapter.

Note:

DiversionTypeAdapter performs the same function as the Cisco Adapter for Avaya Business Communication Manager systems.

Diversion to History-Info Header Adaptation

Cisco requires the use of the Diversion header, rather than the History-Info header to provide information related to how and why the call arrives to a specific application or user. The following examples illustrate the adaptations.

Example 1:

Communication Manager user 66600001 forwards to Cisco user 60025.

The outgoing INVITE of Communication Manager has this history-info:

History-Info: "<sip:66600001@ny.avaya.com>;index=1
History-Info: "stn 66600001" <sip:66600001@ny.avaya.com?     
	Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20Temporarily%22     
	&Reason=Redirection%3Bcause%3DCFI>;index=1.1
History-Info: <sip:600025@ny.avaya.com>;index=1.2

In the message sent to Cisco this is converted to:

Diversion: "stn 66600001" <sip:66600001@ny.avaya.com>;reason=no-answer;privacy=off;screen=no

Example 2:

Communication Manager user calls Cisco user 60025. This call is routed to Modular Messaging at extension 688810.

The INVITE message from the Cisco server contains the following Diversion Header:

Diversion: "Ken's Desk" <sip:600025@ny.avaya.com>;reason=user-
	busy;privacy=off;screen=no

The message is adapted and the outgoing INVITE to MM replaces the Diversion header with the following:

History-Info: <sip:600025@ny.avaya.com>;index=1
History-Info: "Ken's Desk" <sip:600025@ny.avaya.com? 
	Reason=SIP%3Bcause%3D486%3Btext%3D%22Busy%20Here%22 
	&Reason=Redirection%3Bcause%3DNORMAL%3Bavaya-cm-reason%3D%22 
	cover-busy%22%3Bavaya-cm-vm-address-digits%3D81080000%3Bavaya-cm-vm-address-handle%3Dsip:80000%40avaya.com>;index=1.1
History-Info: "MM" <sip:688810@ny.avaya.com>;index=1.2

Remote-Party-Id to P-Asserted-Identity Header Adaptation

Cisco requires information in the P-Asserted-Identity (PAI) header to be received in the Remote-Party-Id (RPI) header. Any incoming message containing a P-Asserted-Identity header being routed to Cisco replaces that header with the Remote-Party-Id header. Similarly, calls from Cisco containing the Remote-Party-Id header are converted to a P-Asserted-Identity header when routed to non-Cisco entities.

Example 3:

A call is placed from 12345 at Communication Manager and routed to the Cisco PBX.

The INVITE from Communication Manager contains:

P-Asserted-Identity: Ryan <sip:12345@avaya.com>

This header is converted to RPI when the request is sent to the Cisco PBX:

Remote-Party-Id: Ryan

<sip:12345@avaya.com>;party=called;screen=no;privacy=off

Example 4:

A call is placed from 23456 at Cisco PBX and routed to Communication Manager.

The INVITE from Cisco PBX contains:

Remote-Party-Id: Ryan

<sip:23456@avaya.com>;party=called;screen=no;privacy=off

This header is converted to PAI when the request is sent to Communication Manager:

P-Asserted-Identity: Ryan <sip:23456@avaya.com>