Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
The SIP REFER does not work correctly. When the IOS gateway receives a SIP REFER to a number, it attempts a SIP INVITE based on SIP URI from REFER TO rather than the destination as specified by the dial-peer
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:
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.