TD 92685EN
28 June 2012 / Ver. A
Troubleshooting Guide
Ascom i62 VoWiFi Handset
42
6. Troubleshooting
2 user3 responds with a 200 OK
3 user2 acknowledges with ACK
4 user2 indicates that it now neither wishes to send nor receive media from user3
by
marking the RTP stream as inactive through the SDP session attribute "a=inactive".
5 The RTP exchange stops and user3 is now on hold
The situation as it currently stands is summarized in figure 15:
Figure 15. SIP Attended
Transfer
In step 3 above, the 200 OK from user3 is also of signif
icance as the OK message header now
holds the call id and the From and To SIP URIs are now tagged with values so that all
subsequent messages can now be associated with the previous INVITE message.
Transferee to Target Transfer
The next step is for user2 to refer user1 to user3 so that an RTP excha
n
ge can ultimately
take place between user1 and user3.
When the transferor user2 gets an indicati
on that the target is ringing, it sends the
transferee a Refer request (RFC 3515) with a Replaces header in the Refer-to header. The
Refer-to header instructs the transferee user1 to issue a triggered SIP INVITE request to the
target user3, to transfer Call-ID u2-to-u3 from user2 to user1. The REFER message includes
the following information for achieving the referral, for example:
REFER user2 -> user1
From: user2 <sip: user2@servera.com>
;tag=u2-2
To: user1 <sips:user1@servera.com>;tag u1
Call ID: u1-to-u2
Refer-to <sips:user3@somewhereelse.com?Rep
l
aces=u2-to-u3;
to tag=u3; from tag=u2-2; Require=replaces>
Referred-by <sip: user2@serverb.com>
To: user3 <sip: user3@somewhereelse.com>; tag=u3
Call ID: u2-to-u3
To Next Page
Loading...
Need help?
General
