Core Issue
A call arrives from the Public Switched Telephone Network (PSTN) over the Primary Rate Interface (PRI) to destination 4149854. This matches the dial-peer 204 and is forwarded to the Inter-VSAN Routing (IVR) system (10.54.78.34). This part of the call is delivered successfully.
The IVR system then redirects the call to a new extension (96115) and sends a Session Initiation Protocol (SIP) REFER to the Cisco AS5350 Universal Gateway (10.56.252.11). The gateway accepts the SIP REFER, but then sends a SIP INVITE to itself (10.56.252.11), even though the dial-peer 220 instructs it to forward the call to 10.56.252.10 (another AS5350 gateway).
This is working as designed (WAD). As per the RFC 3515:
Processing a REFER request:
A UA accepting a well-formed REFER request should request approval from the user to proceed (this request could be satisfied with an interactive query or through accessing configured policy). If approval is granted, the UA must contact the resource identified by the URI in the Refer-To header field value.
The RFC explicitly states that SIP UA must contact resource identified in the Refer-To URI. Refer-To URI prescribes protocol, user, host and port.
In this case, The Refer-To in the SIP REFER reads:
Refer-To:<sip:96115@10.56.252.11;user=phone>
Since the release of Cisco IOS 12.3(4)T, the host is referred to from the Refer-To header itself. This is the reason why the triggered INVITE is seen going to 10.56.252.11.
For more information refer to CSCed50681
Resolution
This behavior can be reverted back to the old (non-standards compliant) behavior with these hidden Command Line Interface (CLI) commands:
Router# conf t
Router(config)# sip-ua
Router(config-sip-ua)# xfer target dial-peer
These commands allow the dial-peer to refer to the host.
For related information, refer to: Call Transfer Capabilities Using the Refer Method
