Troubleshooting Scenarios; Sip; Attended Transfer Example - ASCOM i62 Troubleshooting Manual

Troubleshooting Guide
Ascom i62 VoWiFi Handset
6.

Troubleshooting Scenarios

This section illustrates, through examples, how a support engineer might approach SIP call
problems by analysing the setup and flow of a call between two parties. The section focuses
upon how traces and logs of SIP signaling and RTP voice packet flows can be analyzed, the
kinds of information these sources provide, and how this information can be used by the
support engineer to identify problems. The section therefore suggests an approach to
troubleshooting issues rather than providing a single definitive method for resolving issues.
6.1

SIP

The following troubleshooting scenarios are described:
• Attended Transfer problem and one-way audio: user1 places a call to user2, and user2
transfers the call to user3. However, either user3 cannot hear user1 or user1 cannot hear
user3. In this scenario, user1 is the call transferee, user2 the call transferor and user3 the
call target.
• Name Presentation problem: user1 places a call to user2, but when user2 accepts the call,
user2's number is not displayed on the handset of user1.
Depending on the configuration and functionality of the SIP proxy the RTP stream may be
passing through the SIP proxy or may be routed directly between the handsets.
A support engineer needs to be aware of the route the signaling and VoIP packets take
through the network and which devices are involved.
If the problem with voice cannot be related to the correct settings of the SIP and VoIP
parameters and the configuration of the IP-PBX used then a recording of the traffic flow
may need to be made on both the wired LAN and the WLAN.
Tip: It can be very beneficial to use a Fixed IP phone connected to the wired LAN as a
terminal and thus quickly eliminate if there is a PBX problem or a WiFi problem. In this case
there will also be just one AP and one handset to troubleshoot.
6.1.1

Attended Transfer Example

A call transfer happens when user2 transfers a call from user1 to another user, say user3.
The sequence of the transfer is as follows:
1 user1 (number, for example: 4111) dials user2's number 4112 and presses the
handset Call button.
2 user2 accepts the call by pressing the handset Accept button and begins a
conversation with user1. user1's number 4111 is displayed in user2's handset.
3 During the conversation the parties agree that user1 should be talking to user3
instead. user2 agrees to transfer the call to user3.
4 user2 presses the handset More button and selects the menu item Tranf. to new
5 user2 enters 4113, the number of user3, in the Transfer to input field, then clicks the
OK button. A Transferred message is displayed in user2's handset.
6 user3's phone rings with 4111, the number of user1, displayed in the handset.
7 user3 selects Accept and begins the conversation with user1. user3's number 4113 is
displayed in user1's handset.
8 The conversation between user1 and user2 is dropped and user2's handset reverts to
displaying the idle screen.
9 user1 and user3 continue the conversation until one of the parties hangs up.
The following sections describe the exchange of SIP requests and responses required to
support the transfer scenario described above. The scenario from a signaling perspective
occurs in three broad steps:
28 June 2012 / Ver. A
6. Troubleshooting
TD 92685EN
40