From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3515.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc3515.txt (limited to 'doc/rfc/rfc3515.txt') 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: + +Refer-To: + +Refer-To: + +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: +From: ;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: ;tag=4992881234 +From: ;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: ;tag=193402342 +From: ;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: ;tag=193402342 +From: ;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: ;tag=193402342 +From: ;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: ;tag=193402342 +From: ;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: ;tag=4992881234 +From: ;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: ;tag=4992881234 +From: ;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: ;tag=193402342 +From: ;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: ;tag=193402342 +From: ;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: ;tag=193402342 +From: ;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: ;tag=193402342 +From: ;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] + -- cgit v1.2.3