TD 92685EN
28 June 2012 / Ver. A
Troubleshooting Guide
Ascom i62 VoWiFi Handset
41
6. Troubleshooting
• RTP sessions are established between the users but are then put on hold pending the
transfer
• The signaling of the actual transfer takes place;
existing RTP sessions are terminated
between the transferee (user1) and transferor (user2) and transferor and transfer
target (user3). A new RTP session is established between user1 and user3.
• One of the parties terminates the call, and a fi
nal
exchange of SIP messages takes place
to signal the completion of the call.
Parties on Hold with Transferor
The flow of SIP messages in the setup between user1 an
d user 2 analogous to any
conventional SIP call between two parties such as that depicted in Appendix 10. The initial
INVITE message creates a header that would contain
the following kind of sample data:
INVITE user1 -> user2
From: user1 <sip: user1@servera.com>;tag=u1
To: user2 <sip: user2@serverb.com>
Call ID: u1-to-u2-cid
l
However, after the establishment of an RTP ses
s
ion between the parties, user2 initiates a
transfer of the call from the handset to user 3. This requires user2 to start the transfer by
putting user 1 on hold in the following way:
1 user2 sends user1 an INVITE to hold the current RTP exchange. The message header
contain
the following sample data:
INVITE (hold) user2 -> user1
From: user2 <sip: user2@servera.com>;tag=u2
To: user1 <sip: user1@servera.com>;tag=u1
Call ID: u1-to-u2-cid
2 user1 responds with a 200 OK
3 user2 acknowledges with ACK
4 user1 indicates that it now neither wishes to send nor receive media from user2
by
marking the RTP stream as inactive through the SDP session attribute "a=inactive".
5 The RTP exchange stops and user1 is now on hold
user2 announces the transfer to user3
with a dialog of messages that is again identical to a
conventional SIP call, up to the establishment of an RTP exchange. The initial INVITE
message creates a header with the following sample data:
INVITE user2 -> user3
From: user2 <sip: user2@servera.com>;tag=u2-2
To: user3 <sip: user3@somewhereelse.com>
Call ID: u2-to-u3
Of significance is the new user 2 tag, u2-
2, associ
ated with the invite. A new user2 tag is
required to differentiate between the tag used with user1 and the tag used with user3.
The dialog with user3 must also indicate that there is a pending transfer and this is also
achieved
through an INVITE to hold message from user2 to user3. user2 puts user3 on hold
with the following dialog:
1 user2 sends user3 an INVITE to hold the current RT
P exchange between user2 and
user3:
INVITE (hold) user2 -> user3
From: user2 <sip: user2@servera.com>;tag=u2-2
To Next Page
Loading...
Need help?
General
