Call Transfer Fails on Intra-Office Phones

Publication Date:  2015-07-25 Views:  366 Downloads:  0
Issue Description
Network: U1930–SIP–PSTN

In an office, the U1930 is used as the voice gateway, and eSpace 7800 series IP phones are used as terminals. The U1930 is connected to the carrier through the SIP trunk. When users transfer calls to outer-office users, the message "transfer failed" is displayed.

Alarm Information
Use the UCMaint to capture logs for SIP-related modules. It is found that the carrier side returns the message "403 Do not use late offer-answer model" when users transfer calls.
Handling Process
After comparison of SIP-related standards with the carrier side, it is confirmed that the fault occurs because the peer end system does not support standard capabilities. The fault is rectified when the peer end updates the system.
Root Cause
Cause analysis process:
Based on the logs, the entire call scenario and signaling process are as follows:
  • Calling party A: 27767039335
  • Called party B: 27117159010
  • Transferred-to number C: 0723967794
User A makes a call to user B. User B answers the call. User B presses the transfer key, enters number C, and presses the send key. The message "transfer failed" is displayed. From the signaling, the transfer fails because the peer end returns the message "403 Do not use late offer-answer model", as shown in the yellow part in the following figure.



1. When the call is transferred to number C, the INVITE message sent by the U1930 does not contain the session description line that can be considered as an offer.

2. Confirm with the peer end. It is leaned that the peer end requires that the INVITE message contain an offer during session initialization.

3. Query SIP-related RFC standards. Rules about carrying an offer/answer in SIP messages are defined in RFC 3261[1], RFC 3262[2], and RFC 3311[4]. These RFCs define the following modes for exchanging an offer/answer in SIP messages:

− Mode 1: The UAC carries an offer in the INVITE request, and the UAS returns an answer in the 200 INVITE response. This is the most common mode.
− Mode 2: The UAC does not carry an offer in the INVITE request. The UAS carries an offer in the 200 INVITE response. The UAC returns an answer in the ACK message. This mode is commonly used in 3PCC.
− Mode 3: The UAC carries an offer in the INVITE request, and the UAS returns an answer in the 1xx-rel response. In this way, the session is set up before the call is completed (the UAC does not receive the 200 INVITE message). Later, session parameters can be updated.
− Mode 4: The UAC does not carry an offer in the INVITE request. The UAS carries an offer in the 1xx-rel response. The UAC returns an answer in the PRACK message. The session is also set up before the call is completed (the UAC does not receive the 200 INVITE message). Later, session parameters can be updated.
− Mode 5: After the UAC and UAS set up the session in mode 3, the call is not completed. Later, mode 5 can be used to update parameters in the session that has been set up. The UAC carries a new offer in the PRACK request. The UAS returns an answer in the 200 PRACK response. In this way, session parameters are updated.
− Mode 6: The UAC (or UAS) carries a new offer in the UPDATE request. The UAS (or UAC) returns an answer in the 200 UPDATE message. In this way, session parameters are updated.
Note that before sending the UPDATE request for updating the session, the UAS or UAC must ensure that the previous session update process has been completed. In other words, an answer is received for a sent offer, or an answer is generated for a received offer.

In the signaling process, it complies with the standard that the INVITE message in call transfer does not carry an offer. The call can be set up in mode 2.

The message "403 Do not use late offer-answer model" returned by the carrier side clearly indicates that the peer end does not support the late off-answer model. The late offer-answer model is a standard RFC model. The peer end upgrades the system, and the fault is rectified.

END