RFC3515 The Session Initiation Protocol (SIP) Refer Method The REFER method 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. 1 The REFER Method The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2]. A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record- Route logic of that dialog. 1.1 The Refer-To Header Field Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) The Refer-To header field MAY be encrypted as part of end-to-end encryption. The Contact header field is an important part of the Route/Record- Route mechanism and is not available to be used to indicate the target of the reference. 1.2 Message Body Inclusion A REFER method MAY contain a body. This specification assigns no meaning to such a body. A receiving agent may choose to process the body according to its Content-Type. 2 Behavior 2.1 SIP User Agents 2.1.1 Forming a REFER request REFER is a SIP request and is constructed as defined in [1]. A REFER request MUST contain exactly one Refer-To header field value. 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. 2.1.2 Processing a REFER request A 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]. 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. 2.1.3 Accessing the Referred-to Resource The resource identified by the Refer-To URI is contacted using the normal mechanisms for that URI type. 2.1.4 Using SIP Events to Report the Results of the Reference Each NOTIFY MUST contain an Event header with a value of refer and possibly an id parameter, and MUST contain a body of type "message/sipfrag". The agent that issued the REFER MUST be prepared to receive a NOTIFY before the REFER transaction completes. The REFER request create the subscription as a SUBSCRIBE request. And use unsubscribe to terminate this subscription. But for the notifier, terminating the subscription SHOULD NOT to cease the action triggered by the REFER request. The agent issuing the REFER may extend its subscription using re-SUBSCRIBE. REFER is the only mechanism that can create a subscription to event refer. If a SUBSCRIBE request for event refer is received for a subscription that does not already exist, it MUST be rejected with a 403. The lifetime of the state being subscribed to is determined by the progress of the referenced request. The duration of the subscription is chosen by the agent accepting the REFER and is communicated to the agent sending the REFER in the subscription's initial NOTIFY (using the Subscription-State expires header parameter). Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY. 2.1.5 The Body of the NOTIFY Each NOTIFY MUST contain a body of type "message/sipfrag" [3]. The body of a NOTIFY MUST begin with a SIP Response Status-Line as defined in [1]. The response class in this status line indicates the status of the referred action. The body MAY contain other SIP header fields to provide information about the outcome of the referenced action. This body provides a complete statement of the status of the referred action. The refer event package does not support state deltas. A minimal, but complete, implementation can respond with a single NOTIFY containing either the body: SIP/2.0 100 Trying if the subscription is pending, the body: SIP/2.0 200 OK if the reference was successful, the body: SIP/2.0 503 Service Unavailable if the reference failed, or the body: SIP/2.0 603 Declined if the REFER request was accepted before approval to follow the reference could be obtained and that approval was subsequently denied (see Section 2.4.7). Implementers must carefully consider what they choose to include. Warning header field values received in responses to the referred action are good candidates. If the reference was to a SIP URI, the entire response to the referenced action could be returned (perhaps to assist with debugging). If the reference was to a non-SIP URI, the minimal implementation discussed above is sufficient to provide a basic indication of success or failure. 2.1.6 Multiple REFER Requests in a Dialog For UA, the Cseq number from REFER request is taken as the Id parameter to distinguish the refer events in the same dialog. The NOTIFY to the first REFER MAY include an id parameter in the Event header. But to the second and subsequent REFER, the NOTIFY MUST inlclude Id parameter in Event Header. The SUBSCRIBE (re-SUBSCRIBE or un-SUBSCRIBE) MUST contain this Id parameter. 2.1.7 Using the Subscription-State Header Field with Event Refer The final NOTIFY sent in response to a REFER MUST indicate the subscription has been "terminated" with a reason of "noresource". (The resource being subscribed to is the state of the referenced request). If a NOTIFY indicates a reason that indicates a re-subscribe is appropriate according to [2], the agent sending the REFER is NOT obligated to re-subscribe. In the case where a REFER was accepted with a 202, but approval to follow the reference was subsequently denied, the reason and retry- after elements of the Subscription-State header field can be used to indicate if and when the REFER can be re-attempted (as described for SUBSCRIBE in [2]). 2.2 Behavior of SIP Registrars/Redirect Servers A registrar that is unaware of the definition of the REFER method will return a 501 (Not Implemented) response as defined in [1]. A registrar aware of the definition of REFER SHOULD return a 405 (Method Not Allowed) response. This specification places no requirements on redirect server behavior beyond those specified in [1]. Thus, it is possible for REFER requests to be redirected. 2.3 Behavior of SIP Proxies Same as OPTIONS request. 3. Package Details: Event refer 3.1 Event Package Name refer 3.2 Event Package parameter The Id parameter in Event Header is the Cseq number of the REFER request. 3.3 SUBSCRIBE Bodies No special meaning. 3.4 Subscription Duration The duration is determinated by the "expire" parameter of Subscription-State header in the first NOTIFY sent in the subscription. Reasonable choices for this initial duration depend on the type of request indicated in the Refer-To URI. The duration SHOULD be chosen to be longer than the time the referenced request will be given to complete. For example, if the Refer-To URI is a SIP INVITE URI, the subscription interval should be longer than the Expire value in the INVITE. Additional time MAY be included to account for time needed to authorize the subscription. 3.5 NOTIFY Bodies Discussed before. 3.6 Notifier processing of SUBSCRIBE requests Discussed before. 3.7 Notifier Generation of NOTIFY Requests Discussed before. 3.8 Subscriber Processing of NOTIFY Requests Discussed before. 3.9 Handling of Forked Requests The UA SHOULD create subscription for each accepting agent, manage the state associated with each subscription separately. It does NOT merge the state. 3.10 Rate of Notifications An event refer NOTIFY might be generated each time new knowledge of the status of a referenced requests becomes available. For instance, if the REFER was to a SIP INVITE, NOTIFYs might be generated with each provisional response and the final response to the INVITE. Alternatively, the subscription might only result in two NOTIFY requests, the immediate NOTIFY and the NOTIFY carrying the final result of the reference. NOTIFYs to event refer SHOULD NOT be sent more frequently than once per second.