summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3515.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3515.txt')
-rw-r--r--doc/rfc/rfc3515.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc3515.txt b/doc/rfc/rfc3515.txt
new file mode 100644
index 0000000..ca1756d
--- /dev/null
+++ b/doc/rfc/rfc3515.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group R. Sparks
+Request for Comments: 3515 dynamicsoft
+Category: Standards Track April 2003
+
+
+ The Session Initiation Protocol (SIP) Refer Method
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ 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.
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1 The Refer-To Header Field . . . . . . . . . . . . . . . 3
+ 2.2 Header Field Support for the REFER Method . . . . . . . 4
+ 2.3 Message Body Inclusion. . . . . . . . . . . . . . . . . 5
+ 2.4 Behavior of SIP User Agents . . . . . . . . . . . . . . 6
+ 2.4.1 Forming a REFER request . . . . . . . . . . . . . 6
+ 2.4.2 Processing a REFER request. . . . . . . . . . . . 6
+ 2.4.3 Accessing the Referred-to Resource. . . . . . . . 6
+ 2.4.4 Using SIP Events to Report the Results
+ of the Reference. . . . . . . . . . . . . . . . . 7
+ 2.4.5 The Body of the NOTIFY. . . . . . . . . . . . . . 8
+ 2.4.6 Multiple REFER Requests in a Dialog . . . . . . . 9
+ 2.4.7 Using the Subscription-State Header
+ Field with Event Refer. . . . . . . . . . . . . . 9
+
+
+
+Sparks Standards Track [Page 1]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ 2.5 Behavior of SIP Registrars/Redirect Servers . . . . . . 9
+ 2.6 Behavior of SIP Proxies . . . . . . . . . . . . . . . . 10
+ 3. Package Details: Event refer . . . . . . . . . . . . . . . . 10
+ 3.1 Event Package Name. . . . . . . . . . . . . . . . . . . 10
+ 3.2 Event Package Parameters. . . . . . . . . . . . . . . . 10
+ 3.3 SUBSCRIBE Bodies. . . . . . . . . . . . . . . . . . . . 10
+ 3.4 Subscription Duration . . . . . . . . . . . . . . . . . 10
+ 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . 11
+ 3.6 Notifier processing of SUBSCRIBE requests . . . . . . . 11
+ 3.7 Notifier Generation of NOTIFY Requests. . . . . . . . . 11
+ 3.8 Subscriber Processing of NOTIFY Requests. . . . . . . . 11
+ 3.9 Handling of Forked Requests . . . . . . . . . . . . . . 11
+ 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . 11
+ 3.11 State Agents. . . . . . . . . . . . . . . . . . . . . . 11
+ 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.1 Prototypical REFER callflow . . . . . . . . . . . . . . 12
+ 4.2 Multiple REFERs in a dialog . . . . . . . . . . . . . . 14
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 16
+ 5.1 Constructing a Refer-To URI . . . . . . . . . . . . . . 16
+ 5.2 Authorization Considerations for REFER. . . . . . . . . 17
+ 5.3 Considerations for the use of message/sipfrag . . . . . 18
+ 5.3.1 Circumventing Privacy . . . . . . . . . . . . . . 18
+ 5.3.2 Circumventing Confidentiality . . . . . . . . . . 19
+ 5.3.3 Limiting the Breach . . . . . . . . . . . . . . . 19
+ 5.3.4 Cut, Paste and Replay Considerations. . . . . . . 19
+ 6. Historic Material . . . . . . . . . . . . . . . . . . . . . 20
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9.1 Normative References. . . . . . . . . . . . . . . . . . 21
+ 9.2 Informative References. . . . . . . . . . . . . . . . . 21
+ 10. Intellectual Property Statement. . . . . . . . . . . . . . . 21
+ 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
+ 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
+
+1. Overview
+
+ This document defines the REFER method. This SIP [1] extension
+ requests that the recipient REFER to a resource provided in the
+ request.
+
+ 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.
+
+
+
+Sparks Standards Track [Page 2]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+2. The REFER Method
+
+ REFER is a SIP method as defined by RFC 3261 [1]. 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.
+
+ Unless stated otherwise, the protocol for emitting and responding to
+ a REFER request are identical to those for a BYE request in [1]. The
+ behavior of SIP entities not implementing the REFER (or any other
+ unknown) method is explicitly defined in [1].
+
+ 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.
+
+2.1 The Refer-To Header Field
+
+ Refer-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 of
+ RFC 3261.
+
+ Header field where proxy ACK BYE CAN INV OPT REG
+ ___________________________________________________________________
+ Refer-To R - - - - - -
+
+ 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.
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 3]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+Examples
+
+Refer-To: sip:alice@atlanta.example.com
+
+Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
+ biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>
+
+Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
+ to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>
+
+Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
+
+Refer-To: http://www.ietf.org
+
+ Long headers field values are line-wrapped here for clarity only.
+
+2.2 Header Field Support for the REFER Method
+
+ This table adds a column to tables 2 and 3 in [1], describing header
+ field presence in a REFER method. See [1] for a key for the symbols
+ used. A row for the Refer-To request-header should be inferred,
+ mandatory for REFER. Refer-To is not applicable for any other
+ methods. The proxy column in [1] applies to the REFER method
+ unmodified.
+
+ Header Where REFER
+ Accept R o
+ Accept 2xx -
+ Accept 415 c
+ Accept-Encoding R o
+ Accept-Encoding 2xx -
+ Accept-Encoding 415 c
+ Accept-Language R o
+ Accept-Language 2xx -
+ Accept-Language 415 c
+ Alert-Info -
+ Allow Rr o
+ Allow 405 m
+ Authentication-Info 2xx o
+ Authorization R o
+ Call-ID c m
+ Call-Info -
+ Contact R m
+ Contact 1xx -
+ Contact 2xx m
+ Contact 3-6xx o
+ Content-Disposition o
+ Content-Encoding o
+
+
+
+Sparks Standards Track [Page 4]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ Content-Language o
+ Content-Length o
+ Content-Type *
+ CSeq c m
+ Date o
+ Error-Info 3-6xx o
+ Expires R o
+ From c m
+ In-Reply-To -
+ Max-Forwards R m
+ Min-Expires -
+ MIME-Version o
+ Organization o
+ Priority R -
+ Proxy-Authenticate 401 o
+ Proxy-Authenticate 407 m
+ Proxy-Authorization R o
+ Proxy-Require R o
+ Record-Route R o
+ Record-Route 2xx,18x o
+ Reply-To -
+ Require c
+ Retry-After 404,413,480,486 o
+ Retry-After 500,503 o
+ Retry-After 600,603 o
+ Route R c
+ Server r o
+ Subject R -
+ Supported R,2xx o
+ Timestamp o
+ To c(1) m
+ Unsupported 420 o
+ User-Agent o
+ Via c(2) m
+ Warning r o
+ WWW-Authenticate 401 m
+ WWW-Authenticate 407 o
+
+ Table 1: Header Field Support
+
+2.3 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.
+
+
+
+
+
+
+Sparks Standards Track [Page 5]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+2.4 Behavior of SIP User Agents
+
+2.4.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.
+
+2.4.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].
+
+ 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.
+
+2.4.3 Accessing the Referred-to Resource
+
+ The resource identified by the Refer-To URI is contacted using the
+ normal mechanisms for that URI type. For example, if the URI is a
+ SIP URI indicating INVITE (using a method=INVITE URI parameter for
+ example), the UA would issue a new INVITE using all of the normal
+ rules for sending an INVITE defined in [1].
+
+
+
+
+Sparks Standards Track [Page 6]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+2.4.4 Using SIP Events to Report the Results of the Reference
+
+ The NOTIFY mechanism defined in [2] MUST be used to inform the agent
+ sending the REFER of the status of the reference. The dialog
+ identifiers (To, From, and Call-ID) of each NOTIFY must match those
+ of the REFER as they would if the REFER had been a SUBSCRIBE request.
+
+ 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 issued the REFER MUST be prepared to
+ receive a NOTIFY before the REFER transaction completes.
+
+ The implicit subscription created by a REFER is the same as a
+ subscription created with a SUBSCRIBE request. The agent issuing the
+ REFER can terminate this subscription prematurely by unsubscribing
+ using the mechanisms described in [2]. Terminating a subscription,
+ either by explicitly unsubscribing or rejecting NOTIFY, is not an
+ indication that the referenced request should be withdrawn or
+ abandoned. In particular, an agent acting on a REFER request SHOULD
+ NOT issue a CANCEL to any referenced SIP requests because the agent
+ sending the REFER terminated its subscription to the refer event
+ before the referenced request completes.
+
+ The agent issuing the REFER may extend its subscription using the
+ subscription refresh mechanisms described in [2].
+
+ 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.
+
+ Notice that unlike SUBSCRIBE, the REFER transaction does not contain
+ a duration for the subscription in either the request or the
+ response. 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.
+
+
+
+
+
+Sparks Standards Track [Page 7]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+2.4.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.
+
+ If a NOTIFY is generated when the subscription state is pending, its
+ body should consist only of a status line containing a response code
+ of 100.
+
+ 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).
+
+ An implementation MAY include more of a SIP message in that body to
+ convey more information. Warning header field values received in
+ responses to the referred action are good candidates. In fact, if
+ the reference was to a SIP URI, the entire response to the referenced
+ action could be returned (perhaps to assist with debugging).
+ However, doing so could have grave security repercussions (see
+ Section 5). Implementers must carefully consider what they choose to
+ include.
+
+ Note that if the reference was to a non-SIP URI, status in any
+ NOTIFYs to the referrer must still be in the form of SIP Response
+ Status-Lines. The minimal implementation discussed above is
+
+
+
+Sparks Standards Track [Page 8]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ sufficient to provide a basic indication of success or failure. For
+ example, if a client receives a REFER to a HTTP URL, and is
+ successful in accessing the resource, its NOTIFY to the referrer can
+ contain the message/sipfrag body of "SIP/2.0 200 OK". If the
+ notifier wishes to return additional non-SIP protocol specific
+ information about the status of the request, it may place it in the
+ body of the sipfrag message.
+
+2.4.6 Multiple REFER Requests in a Dialog
+
+ A REFER creates an implicit subscription sharing the dialog
+ identifiers in the REFER request. If more than one REFER is issued
+ in the same dialog (a second attempt at transferring a call for
+ example), the dialog identifiers do not provide enough information to
+ associate the resulting NOTIFYs with the proper REFER.
+
+ Thus, for the second and subsequent REFER requests a UA receives in a
+ given dialog, it MUST include an id parameter[2] in the Event header
+ field of each NOTIFY containing the sequence number (the number from
+ the CSeq header field value) of the REFER this NOTIFY is associated
+ with. This id parameter MAY be included in NOTIFYs to the first
+ REFER a UA receives in a given dialog. A SUBSCRIBE sent to refresh
+ or terminate this subscription MUST contain this id parameter.
+
+2.4.7 Using the Subscription-State Header Field with Event Refer
+
+ Each NOTIFY must contain a Subscription-State header field as defined
+ in [2]. 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.5 Behavior of SIP Registrars/Redirect Servers
+
+ A registrar that is unaware of the definition of the REFER method
+ will return a 501 response as defined in [1]. A registrar aware of
+ the definition of REFER SHOULD return a 405 response.
+
+
+
+
+Sparks Standards Track [Page 9]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ 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.6 Behavior of SIP Proxies
+
+ SIP proxies do not require modification to support the REFER method.
+ Specifically, as required by [1], a proxy should process a REFER
+ request the same way it processes an OPTIONS request.
+
+3. Package Details: Event refer
+
+ This document defines an event package as defined in [2].
+
+3.1 Event Package Name
+
+ The name of this event package is "refer".
+
+3.2 Event Package Parameters
+
+ This package uses the "id" parameter defined in [2]. Its use in
+ package is described in Section 2.4.6.
+
+3.3 SUBSCRIBE Bodies
+
+ SUBSCRIBE bodies have no special meaning for this event package.
+
+3.4 Subscription Duration
+
+ The duration of an implicit subscription created by a REFER request
+ is initially determined by the agent accepting the REFER and
+ communicated to the subscribing agent in the Subscription-State
+ header field's expire parameter 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. The
+ subscribing agent MAY extend the subscription by refreshing it, or
+ terminate it by unsubscribing. As described in Section 2.4.7, the
+ agent accepting the REFER will terminate the subscription when it
+ reports the final result of the reference, indicating that
+ termination in the Subscription-State header field.
+
+
+
+
+
+
+Sparks Standards Track [Page 10]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+3.5 NOTIFY Bodies
+
+ The bodies of NOTIFY requests for event refer are discussed in
+ Section 2.4.5.
+
+3.6 Notifier processing of SUBSCRIBE requests
+
+ Notifier processing of SUBSCRIBE requests is discussed in Section
+ 2.4.4.
+
+3.7 Notifier Generation of NOTIFY Requests
+
+ Notifier generation of NOTIFY requests is discussed in Section 2.4.4.
+
+3.8 Subscriber Processing of NOTIFY Requests
+
+ Subscriber processing of NOTIFY requests is discussed in Section
+ 2.4.4.
+
+3.9 Handling of Forked Requests
+
+ A REFER sent within the scope of an existing dialog will not fork. A
+ REFER sent outside the context of a dialog MAY fork, and if it is
+ accepted by multiple agents, MAY create multiple subscriptions.
+ These subscriptions are created and managed as per "Handling of
+ Forked Requests" in [2] as if the REFER had been a SUBSCRIBE. The
+ agent sending the REFER manages the state associated with each
+ subscription separately. It does NOT merge the state from the
+ separate subscriptions. The state is the status of the referenced
+ request at each of the accepting agents.
+
+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.
+
+3.11 State Agents
+
+ Separate state agents are not defined for event refer.
+
+
+
+
+
+
+Sparks Standards Track [Page 11]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+4. Examples
+
+4.1 Prototypical REFER callflow
+
+ Agent A Agent B
+ | |
+ | F1 REFER |
+ |----------------------->|
+ | F2 202 Accepted |
+ |<-----------------------|
+ | F3 NOTIFY |
+ |<-----------------------|
+ | F4 200 OK |
+ |----------------------->|
+ | |
+ | |
+ | |------->
+ | | (whatever)
+ | |<------
+ | |
+ | F5 NOTIFY |
+ |<-----------------------|
+ | F6 200 OK |
+ |----------------------->|
+ | |
+ | |
+
+ Here are examples of what the four messages between Agent A and Agent
+ B might look like if the reference to (whatever) that Agent B makes
+ is successful. The details of this flow indicate this particular
+ REFER occurs outside a session (there is no To tag in the REFER
+ request). If the REFER occurs inside a session, there would be a
+ non-empty To tag in the request.
+
+Message One (F1)
+
+REFER sip:b@atlanta.example.com SIP/2.0
+Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
+To: <sip:b@atlanta.example.com>
+From: <sip:a@atlanta.example.com>;tag=193402342
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 93809823 REFER
+Max-Forwards: 70
+Refer-To: (whatever URI)
+Contact: sip:a@atlanta.example.com
+Content-Length: 0
+
+
+
+
+
+Sparks Standards Track [Page 12]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+Message Two (F2)
+
+SIP/2.0 202 Accepted
+Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
+To: <sip:b@atlanta.example.com>;tag=4992881234
+From: <sip:a@atlanta.example.com>;tag=193402342
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 93809823 REFER
+Contact: sip:b@atlanta.example.com
+Content-Length: 0
+
+Message Three (F3)
+
+NOTIFY sip:a@atlanta.example.com SIP/2.0
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993402 NOTIFY
+Max-Forwards: 70
+Event: refer
+Subscription-State: active;expires=(depends on Refer-To URI)
+Contact: sip:b@atlanta.example.com
+Content-Type: message/sipfrag;version=2.0
+Content-Length: 20
+
+SIP/2.0 100 Trying
+
+Message Four (F4)
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993402 NOTIFY
+Contact: sip:a@atlanta.example.com
+Content-Length: 0
+
+Message Five (F5)
+
+NOTIFY sip:a@atlanta.example.com SIP/2.0
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993403 NOTIFY
+Max-Forwards: 70
+
+
+
+Sparks Standards Track [Page 13]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+Event: refer
+Subscription-State: terminated;reason=noresource
+Contact: sip:b@atlanta.example.com
+Content-Type: message/sipfrag;version=2.0
+Content-Length: 16
+
+SIP/2.0 200 OK
+
+Message Six (F6)
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993403 NOTIFY
+Contact: sip:a@atlanta.example.com
+Content-Length: 0
+
+4.2 Multiple REFERs in a dialog
+
+ Message One above brings an implicit subscription dialog into
+ existence. Suppose Agent A issued a second REFER inside that dialog:
+
+ Agent A Agent B
+ | |
+ | F7 REFER |
+ |----------------------->|
+ | F8 202 Accepted |
+ |<-----------------------|
+ | F9 NOTIFY |
+ |<-----------------------|
+ | F10 200 OK |
+ |----------------------->|
+ | |------->
+ | | (something different)
+ | |<------
+ | |
+ | F11 NOTIFY |
+ |<-----------------------|
+ | F12 200 OK |
+ |----------------------->|
+ | |
+ | |
+
+
+
+
+
+
+
+Sparks Standards Track [Page 14]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+Message Seven (F7)
+
+REFER sip:b@atlanta.example.com SIP/2.0
+Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
+To: <sip:b@atlanta.example.com>;tag=4992881234
+From: <sip:a@atlanta.example.com>;tag=193402342
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 93809824 REFER
+Max-Forwards: 70
+Refer-To: (some different URI)
+Contact: sip:a@atlanta.example.com
+Content-Length: 0
+
+Message Eight (F8)
+
+SIP/2.0 202 Accepted
+Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
+To: <sip:b@atlanta.example.com>;tag=4992881234
+From: <sip:a@atlanta.example.com>;tag=193402342
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 93809824 REFER
+Contact: sip:b@atlanta.example.com
+Content-Length: 0
+
+Message Nine (F9)
+
+NOTIFY sip:a@atlanta.example.com SIP/2.0
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993404 NOTIFY
+Max-Forwards: 70
+Event: refer;id=93809824
+Subscription-State: active;expires=(depends on Refer-To URI)
+Contact: sip:b@atlanta.example.com
+Content-Type: message/sipfrag;version=2.0
+Content-Length: 20
+
+SIP/2.0 100 Trying
+
+Message Ten (F10)
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+
+
+
+Sparks Standards Track [Page 15]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+CSeq: 1993404 NOTIFY
+Contact: sip:a@atlanta.example.com
+Content-Length: 0
+
+Message Eleven (F11)
+
+NOTIFY sip:a@atlanta.example.com SIP/2.0
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993405 NOTIFY
+Max-Forwards: 70
+Event: refer;id=93809824
+Subscription-State: terminated;reason=noresource
+Contact: sip:b@atlanta.example.com
+Content-Type: message/sipfrag;version=2.0
+Content-Length: 16
+
+SIP/2.0 200 OK
+
+Message Twelve (F12)
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
+To: <sip:a@atlanta.example.com>;tag=193402342
+From: <sip:b@atlanta.example.com>;tag=4992881234
+Call-ID: 898234234@agenta.atlanta.example.com
+CSeq: 1993405 NOTIFY
+Contact: sip:a@atlanta.example.com
+Content-Length: 0
+
+5. Security Considerations
+
+ The security considerations described in Section 26 of [1] apply to
+ the REFER transaction. In particular, the implementation
+ requirements and considerations in Section 26.3 address securing a
+ generic SIP transaction. Special consideration is warranted for the
+ authorization polices applied to REFER requests and for the use of
+ message/sipfrag to convey the results of the referenced request.
+
+5.1 Constructing a Refer-To URI
+
+ This mechanism relies on providing contact information for the
+ referred-to resource to the party being referred. Care should be
+ taken to provide a suitably restricted URI if the referred-to
+ resource should be protected.
+
+
+
+
+Sparks Standards Track [Page 16]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+5.2 Authorization Considerations for REFER
+
+ As described in Section 2.4.2, an implementation can receive a REFER
+ requests with a Refer-To URI containing an arbitrary scheme. For
+ instance, a user could be referred to an online service such as a MUD
+ using a telnet URI. Customer service could refer a customer to an
+ order tracking web page using an HTTP URI. Section 2.4.2 allows a
+ user agent to reject a REFER request when it can not process the
+ referenced scheme. It also requires the user agent to obtain
+ authorization from its user before attempting to use the URI.
+ Generally, this could be achieved by prompting the user with the full
+ URI and a question such as "Do you wish to access this resource
+ (Y/N)". Of course, URIs can be arbitrarily long and are occasionally
+ constructed with malicious intent, so care should be taken to avoid
+ surprise even in the display of the URI itself (such as partial
+ display or crashing). Further, care should be taken to expose as
+ much information about the reference as possible to the user to
+ mitigate the risk of being misled into a dangerous decision. For
+ instance, the Refer-To header may contain a display name along with
+ the URI. Nothing ensures that any property implied by that display
+ name is shared by the URI. For instance, the display name may
+ contain "secure" or "president" and when the URI indicates
+ sip:agent59@telemarketing.example.com. Thus, prompting the user with
+ the display name alone is insufficient.
+
+ In some cases, the user can provide authorization for some REFER
+ requests ahead of time by providing policy to the user agent. This
+ is appropriate, for instance, for call transfer as discussed in [4].
+ Here, a properly authenticated REFER request within an existing SIP
+ dialog to a sip:, sips:, or tel: URI may be accepted through policy
+ without interactively obtaining the user's authorization. Similarly,
+ it may be appropriate to accept a properly authenticated REFER to an
+ HTTP URI if the referror is on an explicit list of approved
+ referrors. In the absence of such pre-provided authorization, the
+ user must interactively provide authorization to reference the
+ indicated resource.
+
+ To see the danger of a policy that blindly accepts and acts on an
+ HTTP URI, for example, consider a web server configured to accept
+ requests only from clients behind a small organization's firewall.
+ As it sits in this soft-creamy-middle environment where the small
+ organization trusts all its members and has little internal security,
+ the web server is frequently behind on maintenance, leaving it
+ vulnerable to attack through maliciously constructed URIs (resulting
+ perhaps in running arbitrary code provided in the URI). If a SIP UA
+ inside this firewall blindly accepted a reference to an arbitrary
+ HTTP URI, an attacker outside the firewall could compromise the web
+ server. On the other hand, if the UA's user has to take positive
+
+
+
+Sparks Standards Track [Page 17]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ action (such as responding to a prompt) before acting on this URI,
+ the risk is reduced to the same level as the user clicking on the URI
+ in a web-browser or email message.
+
+ The conclusion in the above paragraph generalizes to URIs with an
+ arbitrary scheme. An agent that takes automated action to access a
+ URI with a given scheme risks being used to indirectly attack another
+ host that is vulnerable to some security flaw related to that scheme.
+ This risk and the potential for harm to that other host is heightened
+ when the host and agent reside behind a common policy-enforcement
+ point such as a firewall. Furthermore, this agent increases its
+ exposure to denial of service attacks through resource exhaustion,
+ especially if each automated action involves opening a new
+ connection.
+
+ User agents should take care when handing an arbitrary URI to a
+ third-party service such as that provided by some modern operating
+ systems, particularly if the user agent is not aware of the scheme
+ and the possible ramifications using the protocols it indicates. The
+ opportunity for violating the principal of least surprise is very
+ high.
+
+5.3 Considerations for the use of message/sipfrag
+
+ Using message/sipfrag bodies to return the progress and results of a
+ REFER request is extremely powerful. Careless use of that capability
+ can compromise confidentiality and privacy. Here are a couple of
+ simple, somewhat contrived, examples to demonstrate the potential for
+ harm.
+
+5.3.1 Circumventing Privacy
+
+ Suppose Alice has a user agent that accepts REFER requests to SIP
+ INVITE URIs, and NOTIFYs the referrer of the progress of the INVITE
+ by copying each response to the INVITE into the body of a NOTIFY.
+
+ Suppose further that Carol has a reason to avoid Mallory and has
+ configured her system at her proxy to only accept calls from a
+ certain set of people she trusts (including Alice), so that Mallory
+ doesn't learn when she's around, or what user agent she's actually
+ using.
+
+ Mallory can send a REFER to Alice, with a Refer-To URI indicating
+ Carol. If Alice can reach Carol, the 200 OK Carol sends gets
+ returned to Mallory in a NOTIFY, letting him know not only that Carol
+ is around, but also the IP address of the agent she's using.
+
+
+
+
+
+Sparks Standards Track [Page 18]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+5.3.2 Circumventing Confidentiality
+
+ Suppose Alice, with the same user agent as above, is working at a
+ company that is working on the greatest SIP device ever invented -
+ the SIP FOO. The company has been working for months building the
+ device and the marketing materials, carefully keeping the idea, even
+ the name of the idea secret (since a FOO is one of those things that
+ anybody could do if they'd just had the idea first). FOO is up and
+ running, and anyone at the company can use it, but it's not available
+ outside the company firewall.
+
+ Mallory has heard rumor that Alice's company is onto something big,
+ and has even managed to get his hands on a URI that he suspects might
+ have something to do with it. He sends a REFER to ALICE with the
+ mysterious URI and as Alice connects to the FOO, Mallory gets NOTIFYs
+ with bodies containing
+
+ Server: FOO/v0.9.7
+
+5.3.3 Limiting the Breach
+
+ For each of these cases, and in general, returning a carefully
+ selected subset of the information available about the progress of
+ the reference through the NOTIFYs mitigates risk. The minimal
+ implementation described in Section 2.4.5 exposes the least
+ information about what the agent operating on the REFER request has
+ done, and is least likely to be a useful tool for malicious users.
+
+5.3.4 Cut, Paste and Replay Considerations
+
+ The mechanism defined in this specification is not directly
+ susceptible to abuse through copying the message/sipfrag bodies from
+ NOTIFY requests and inserting them, in whole or in part, in future
+ NOTIFY requests associated with the same or a different REFER. Under
+ this specification the agent replying to the REFER request is in
+ complete control of the content of the bodies of the NOTIFY it sends.
+ There is no mechanism defined here requiring this agent to faithfully
+ forward any information from the referenced party. Thus, saving a
+ body for later replay gives the agent no more ability to affect the
+ mechanism defined in this document at its peer than it has without
+ that body. Similarly, capture of a message/sipfrag body by
+ eavesdroppers will give them no more ability to affect this mechanism
+ than they would have without it.
+
+ Future extensions may place additional constraints on the agent
+ responding to REFER to allow using the message/sipfrag body part in a
+ NOTIFY to make statements like "I contacted the party you referred me
+ to, and here's cryptographic proof". These statements might be used
+
+
+
+Sparks Standards Track [Page 19]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ to affect the behavior of the receiving UA. This kind of extension
+ will need to define additional mechanism to protect itself from copy
+ based attacks.
+
+6. Historic Material
+
+ This method was initially motivated by the call-transfer application.
+ Starting as TRANSFER, and later generalizing to REFER, this method
+ improved on the BYE/Also concept of the expired draft-ietf-sip-cc-01
+ by disassociating transfers from the processing of BYE. These
+ changes facilitate recovery of failed transfers and clarify state
+ management in the participating entities.
+
+ Early versions of this work required the agent responding to REFER to
+ wait until the referred action completed before sending a final
+ response to the REFER. That final response reflected the success or
+ failure of the referred action. This was infeasible due to the
+ transaction timeout rules defined for non-INVITE requests in [1]. A
+ REFER must always receive an immediate (within the lifetime of a
+ non-INVITE transaction) final response.
+
+7. IANA Considerations
+
+ This document defines a new SIP method name (REFER), a new SIP header
+ field name with a compact form (Refer-To and r respectively), and an
+ event package (refer).
+
+ The following has been added to the method sub-registry under
+ http://www.iana.org/assignments/sip-parameters.
+
+ REFER [RFC3515]
+
+ The following information also has been be added to the header sub-
+ registry under http://www.iana.org/assignments/sip-parameters.
+
+ Header Name: Refer-To
+
+ Compact Form: r
+
+ Reference: RFC 3515
+
+ This specification registers an event package, based on the
+ registration procedures defined in [2]. The following is the
+ information required for such a registration:
+
+ Package Name: refer
+
+ Package or Package-Template: This is a package.
+
+
+
+Sparks Standards Track [Page 20]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+ Published Specification: RFC 3515
+
+ Person to Contact: Robert Sparks, rsparks@dynamicsoft.com
+
+8. Acknowledgments
+
+ This document is a collaborative product of the SIP working group.
+
+9. References
+
+9.1 Normative References
+
+ [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
+ Notification", RFC 3265, June 2002.
+
+ [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
+ November 2002.
+
+9.2 Informative References
+
+ [4] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
+ Control - Transfer", Work in Progress.
+
+10. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Sparks Standards Track [Page 21]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+11. Author's Address
+
+ Robert J. Sparks
+ dynamicsoft
+ 5100 Tennyson Parkway
+ Suite 1200
+ Plano, TX 75024
+
+ EMail: rsparks@dynamicsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 22]
+
+RFC 3515 The SIP Refer Method April 2003
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 23]
+