This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.

This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer.In addition to the REFER method, this document defines the the refer event package and the Refer-To request header. This can be used to enable many applications, including Call Transfer. For instance, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP user agent (UA) to send a SIP REFER request to Bob's UA providing Carol's SIP Contact information. Assuming Bob has given it permission, Bob's UA will attempt to call Carol using that contact. Bob's UA will then report whether it succeeded in reaching the contact to Alice's UA. SparksStandards The Refer-To Header FieldRefer-To is a request header field (request-header) as defined by [1]. It only appears in a REFER request. It provides a URL to reference.Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param)The following should be interpreted as if it appeared in Table 3 Processing a REFER requestA UA accepting a well-formed REFER request SHOULD request approval from the user to proceed (this request could be satisfied with an interactive query or through accessing configured policy). If approval is granted, the UA MUST contact the resource identified by the URI in the Refer-To header field value as discussed in Section 2.4.3.If the approval sought above for a well-formed REFER request is immediately denied, the UA MAY decline the request.An agent responding to a REFER method MUST return a 400 (Bad Request) if the request contained zero or more than one Refer-To header field values.An agent (including proxies generating local responses) MAY return a 100 (Trying) or any appropriate 4xx-6xx class response as prescribed by [1].Care should be taken when implementing the logic that determines whether or not to accept the REFER request. A UA not capable of accessing non-SIP URIs SHOULD NOT accept REFER requests to them.If no final response has been generated according to the rules above, the UA MUST return a 202 Accepted response before the REFER transaction expires.If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4. Accessing the Referred-to ResourceThe resource identified by the Refer-To URI is contacted using the normal mechanisms for that URI type. Each NOTIFY MUST contain an Event header field with a value of refer and possibly an id parameter (see Section 2.4.6).Each NOTIFY MUST contain a body of type "message/sipfrag" [3].The creation of a subscription as defined by [2] always results in an immediate NOTIFY. Analogous to the case for SUBSCRIBE described in that document, the agent that issue...

No abstract

No abstract

No abstract