TD 92685EN
28 June 2012 / Ver. A
Troubleshooting Guide
Ascom i62 VoWiFi Handset
40
6. Troubleshooting
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: us
er1 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 num
ber is not displayed on the handset of user1.
Depending on the configuration and functionality of the SIP proxy t
he 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 s
ignaling and VoIP packets take
through the network and which devices are involved.
If the problem with voice cannot be related to t
he 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 bene
ficial 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 b
utton.
2 user2 accepts the call by pressing the handset Ac
cept 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
inste
ad. user2 agrees to transfer the call to user3.
4 user2 presses the handset More button and sel
ects 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 numbe
r of user1, displayed in the handset.
7 user3 selects A
ccept 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:
To Next Page
Loading...
Need help?
General
