2009/1/28 Iñaki Baz Castillo <[email protected]>: > Hi, that's not necessary at all as it's already documented in the same > RFC 3515 (REFER method): > > http://tools.ietf.org/html/rfc3515#section-4.1
And it's also fully explained and documented in RFC 5359 "Session Initiation Protocol Service Examples": http://tools.ietf.org/html/rfc5359#section-2.18 2.18. Click to Dial Bob's PC Bob Carol | REFER Refer-To:Carol F1 | |------------------->| | | 202 Accepted F2 | | |<-------------------| | | | INVITE F3 | | |------------------->| | | 180 Ringing F4 | | |<-------------------| | | 200 OK F5 | | |<-------------------| | | ACK F6 | | |------------------->| | | RTP | | |<==================>| | | | In this example, while browsing the web on his PC, Bob clicks on Carol's SIP URI, intending to establish a session with Carol. Bob's web browser passes the SIP URI to the SIP client on Bob's PC. The PC client is configured with the URI of Bob's SIP phone. A REFER is sent to the SIP phone, which results in the establishment of the session between Bob and Carol. Note that Bob's PC requests that no REFER dialog be established by the use of the Refer-Sub: false header field [RFC4488]. This flow is preferable to the 3pcc flow because the end-to-end SIP signaling is not interrupted by the 3pcc controller, and because Bob's experience of the call will not be marred by the lack of ringback tone or possible clipping. Suitable authorization of the REFER and explicit authorization of the triggered INVITE by Bob are necessary. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
