RFC 3515
The Session Initiation Protocol (SIP) Refer Method
The Session Initiation Protocol (SIP) Refer Method 🎀
RFC 3515 💅 Network Working Group, Category: Standards Track, April 2003. The author is R. Sparks from dynamicsoft. The title block doesn't list any RFC that this one obsoletes or updates.
Status of this Memo ✨
okay so this one is a real Internet standards track protocol 🫶 It's for the whole Internet community, and it literally asks for discussion and suggestions for improvements. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share away 💖
Copyright Notice 🌸
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
okay this doc defines the REFER method 🎀 It's a SIP extension that asks the recipient to REFER to a resource that's provided in the request. The big payoff is that the party who sent the REFER gets notified about how the referenced request turned out. That's super useful and can power lots of apps, call transfer being the iconic one 📞✨
It also defines the refer event package and the Refer-To request header, so the whole vibe is coming together 💜
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
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 . . . . . . . . . . . . . . . . . . 231. Overview 🌈
okay so this doc defines the REFER method 💖 It's a SIP [1] extension that asks the recipient to REFER to a resource provided in the request.
This can power a bunch of apps, including Call Transfer 📞 Picture this: Alice is on a call with Bob and decides Bob needs to talk to Carol 👀 Alice tells her SIP user agent (UA) to send a SIP REFER request to Bob's UA, and the request includes Carol's SIP Contact information. If Bob has given permission, Bob's UA tries to call Carol using that contact. Then Bob's UA reports back to Alice's UA on whether it managed to reach the contact. Iconic behavior, honestly 🔥
2. The REFER Method 💅
REFER is a SIP method, defined in RFC 3261 [1] 🎀 The REFER method tells the recipient (the one identified by the Request-URI) to contact a third party using the contact information included in the request.
Unless stated otherwise, the rules for sending a REFER request and responding to one are the same as for a BYE request in [1] ✨ And the way SIP entities that don't implement REFER (or any other unknown method) behave is explicitly defined in [1], so no guessing 🙈
A REFER request implicitly sets up a subscription to the refer event 🦋 Event subscriptions are defined in [2].
A REFER request MAY be sent outside the scope of a dialog created with an INVITE 💜 REFER creates a dialog and MAY be Record-Routed. Since it can be Record-Routed, it MUST contain a single Contact header field value 🧚 REFERs sent inside an existing dialog MUST follow that dialog's Route/Record-Route logic. Non-negotiable, bestie 💀
2.1 The Refer-To Header Field 🍓
Refer-To is a request header field (request-header) as defined by [1]. It only shows up in a REFER request, and it gives you 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 🔐 Also, the Contact header field is a huge part of the Route/Record-Route mechanism. It is NOT available for indicating the target of the reference, so don't go there 🙅♀️
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.orgLong header field values are line-wrapped here just for readability 💖
2.2 Header Field Support for the REFER Method 🦋
This table adds a column to tables 2 and 3 in [1], describing which header fields show up in a REFER method ✨ See [1] for the key to the symbols. A row for the Refer-To request-header should be inferred, and it is mandatory for REFER. Refer-To doesn't apply to any other methods. The proxy column in [1] applies to the REFER method unchanged 🫶
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
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 oTable 1: Header Field Support 🍓
2.3 Message Body Inclusion 🌈
A REFER method MAY contain a body 💜 This spec assigns no meaning to that body. A receiving agent may choose to process the body according to its Content-Type 🧚
2.4 Behavior of SIP User Agents 💖
2.4.1 Forming a REFER request 🎀
REFER is a SIP request, and it's built the way [1] defines ✨ A REFER request MUST contain exactly one Refer-To header field value. No more, no less, periodt 💅
2.4.2 Processing a REFER request ✨
Okay so when a UA gets a well-formed REFER, it SHOULD ask the user for approval first 💅 (that could be an interactive popup or just checking the configured policy 🎀). If approval is granted, the UA MUST contact the resource in the Refer-To header field value, as covered in Section 2.4.3 🦋.
If the approval it asked for gets instantly denied, the UA MAY decline the request 🙈
An agent responding to a REFER method MUST return a 400 (Bad Request) if the request had zero or more than one Refer-To header field values. No exceptions, bestie 😭
An agent (proxies generating local responses included) MAY return a 100 (Trying) or any appropriate 4xx-6xx class response, as prescribed by [1] 🌸
Care should be taken when you write the logic for deciding whether to accept a REFER request. A UA that can't access non-SIP URIs SHOULD NOT accept REFER requests pointing at them 🚫
If no final response has been generated under the rules above, the UA MUST return a 202 Accepted response before the REFER transaction expires ⏰
If a REFER request is accepted (meaning a 2xx class response gets returned), the recipient MUST create a subscription and send notifications about 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 gets 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 instance), the UA would issue a brand new INVITE, following all the normal rules for sending an INVITE defined in [1] ✨
2.4.4 Using SIP Events to Report the Results of the Reference
The NOTIFY mechanism defined in [2] MUST be used to tell the agent that sent the REFER what's going on with the reference 📣 The dialog identifiers (To, From, and Call-ID) of each NOTIFY must match those of the REFER, just like 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] 💅
Creating a subscription as defined by [2] always results in an immediate NOTIFY, and it's giving plot twist. Same as with SUBSCRIBE in that doc, 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 works exactly like a subscription made with a SUBSCRIBE request. The agent that issued the REFER can end this subscription early by unsubscribing, using the mechanisms described in [2]. Ending a subscription (whether by unsubscribing explicitly or by rejecting a NOTIFY) does NOT mean the referenced request should be withdrawn or abandoned. So an agent acting on a REFER request SHOULD NOT issue a CANCEL to any referenced SIP requests, even though the REFER sender ended its subscription to the refer event before the referenced request finished 🙈
The agent that issued the REFER is allowed to 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 arrives for a subscription that doesn't already exist, it MUST be rejected with a 403 💀
Here's the tea: unlike SUBSCRIBE, the REFER transaction doesn't include a duration for the subscription, in either the request or the response. How long the state being subscribed to lives depends on how far along the referenced request gets 🧚 The agent accepting the REFER picks the duration and tells the REFER sender in the subscription's initial NOTIFY (using the Subscription-State expires header parameter). Also, agents that accept REFER but don't want to hold subscription state can end the subscription right there with that initial NOTIFY 💖
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 that status line tells you how the referred action is doing. The body MAY contain other SIP header fields that give more info about how the referenced action turned out. This body gives a complete statement of where the referred action stands. Also, the refer event package does not support state deltas 🍓
If a NOTIFY is generated while the subscription state is pending, its body should consist only of a status line with a response code of 100 🌸
A minimal but complete implementation can respond with a single NOTIFY whose body is one of these:
SIP/2.0 100 Tryingfor when the subscription is pending,
SIP/2.0 200 OKfor when the reference was successful,
SIP/2.0 503 Service Unavailablefor when the reference failed, or
SIP/2.0 603 Declinedfor when the REFER request got accepted before approval to follow the reference could be obtained, and that approval was then denied afterwards (see Section 2.4.7) 🙈
An implementation MAY include more of a SIP message in that body to share extra info. Warning header field values received in responses to the referred action are great candidates 🫶 Honestly, if the reference was to a SIP URI, the whole response to the referenced action could be returned (maybe to help with debugging). BUT doing so could have grave security repercussions (see Section 5). Implementers must carefully consider what they choose to include 🚨
Also, if the reference was to a non-SIP URI, the status in any NOTIFYs to the referrer must still be in the form of SIP Response Status-Lines. The minimal implementation above is enough to give a basic success or failure signal. For example, if a client gets a REFER to an HTTP URL and successfully accesses the resource, its NOTIFY to the referrer can have the message/sipfrag body of SIP/2.0 200 OK. If the notifier wants to return extra non-SIP, protocol-specific info about the status of the request, it may put that in the body of the sipfrag message ✨
2.4.6 Multiple REFER Requests in a Dialog
A REFER creates an implicit subscription that shares the dialog identifiers from the REFER request. If more than one REFER gets issued in the same dialog (a second attempt at transferring a call, for example), the dialog identifiers don't give enough info to link the resulting NOTIFYs to the right REFER 😵💫
So for the second and later REFER requests a UA receives in a given dialog, it MUST include an id parameter[2] in the Event header field of each NOTIFY, holding the sequence number (the number from the CSeq header field value) of the REFER that NOTIFY belongs to 🎀 The id parameter MAY also show up in NOTIFYs for 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 that the subscription has been "terminated" with a reason of "noresource". (The resource being subscribed to is the state of the referenced request, btw 💅)
If a NOTIFY gives a reason that says a re-subscribe is appropriate according to [2], the agent sending the REFER is NOT obligated to re-subscribe. Your call, queen 👑
In the case where a REFER was accepted with a 202, but approval to follow the reference was later denied, the reason and retry-after elements of the Subscription-State header field can be used to say if and when the REFER can be tried again (as described for SUBSCRIBE in [2]) ⏰
2.5 Behavior of SIP Registrars/Redirect Servers
A registrar that doesn't know about the REFER method will return a 501 response, as defined in [1]. A registrar that does know about the definition of REFER SHOULD return a 405 response 🧚
This specification puts no requirements on redirect server behavior beyond what's specified in [1]. So yes, it's possible for REFER requests to get redirected 🦋
2.6 Behavior of SIP Proxies
SIP proxies don't need any 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. Easy peasy 🍓
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 this package is described in Section 2.4.6 💖
3.3 SUBSCRIBE Bodies
SUBSCRIBE bodies have no special meaning for this event package. Nothing to see here 🙈
3.4 Subscription Duration
The duration of an implicit subscription created by a REFER request starts out being decided by the agent accepting the REFER. That agent tells 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 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 the 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 end the subscription when it reports the final result of the reference, and it signals that termination in the Subscription-State header field ⏰
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's accepted by multiple agents, it 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 for 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 🔔
Okay so an event refer NOTIFY might get generated each time new knowledge of the status of a referenced requests becomes available 👀. Like, if the REFER was to a SIP INVITE, NOTIFYs might go out with each provisional response and the final response to the INVITE. Or the subscription could be super minimal and only send two NOTIFY requests: the immediate one, and the NOTIFY carrying the final result of the reference 🎀. Either way, NOTIFYs to event refer SHOULD NOT be sent more frequently than once per second. Not spamming your bestie's phone every millisecond, periodt 💅
3.11 State Agents 🧚
Bestie, separate state agents are not defined for event refer. Nothing extra to see here ✨
4. Examples 🌸
4.1 Prototypical REFER callflow 🦋
Here's the cutest little callflow ever 🥹
Agent A Agent B
| |
| F1 REFER |
|----------------------->|
| F2 202 Accepted |
|<-----------------------|
| F3 NOTIFY |
|<-----------------------|
| F4 200 OK |
|----------------------->|
| |
| |
| |------->
| | (whatever)
| |<------
| |
| F5 NOTIFY |
|<-----------------------|
| F6 200 OK |
|----------------------->|
| |
| |So these are what the four messages between Agent A and Agent B might look like if the reference to (whatever) that Agent B makes is successful. Okay, six messages actually, but we're not gonna nitpick 🙈 The details of this flow tell us this particular REFER happens outside a session, because there is no To tag in the REFER request. If the REFER happened 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: 0Message 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: 0Message 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 TryingMessage 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: 0Message 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
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 OKMessage 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: 04.2 Multiple REFERs in a dialog 💜
Okay, so Message One above brings an implicit subscription dialog into existence ✨ Now, what if Agent A sends a second REFER inside that dialog? Let's find out 👀
Agent A Agent B
| |
| F7 REFER |
|----------------------->|
| F8 202 Accepted |
|<-----------------------|
| F9 NOTIFY |
|<-----------------------|
| F10 200 OK |
|----------------------->|
| |------->
| | (something different)
| |<------
| |
| F11 NOTIFY |
|<-----------------------|
| F12 200 OK |
|----------------------->|
| |
| |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: 0Message 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: 0Message 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 TryingMessage 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
CSeq: 1993404 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0Message 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 OKMessage 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: 05. Security Considerations 🔐
Bestie, this part is serious, so read it carefully 🚨
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 🫶 Keep that link locked down, iykyk 🔒
5.2 Authorization Considerations for REFER 🔐
okay so, like we said in Section 2.4.2, an implementation can get a REFER request with a Refer-To URI using basically any scheme at all 🫣. A user could get sent to an online service like a MUD through a telnet URI, or customer service could send a customer to an order tracking web page with an HTTP URI 📦. Section 2.4.2 lets a user agent reject a REFER request when it can't process the referenced scheme 🙅♀️. It also says the user agent has to get authorization from its user before it even tries to use the URI. A simple way to do that is prompting the user with the full URI and asking something like "Do you wish to access this resource (Y/N)". But URIs can be arbitrarily long, and sometimes they're built with bad intentions 💀. So be careful that even displaying the URI doesn't cause surprises, like partial display or crashing. Also, show the user as much info about the reference as you can so they don't get misled into a dangerous decision 👀. For example, the Refer-To header might come with a display name, and nothing makes sure that whatever the display name suggests is actually true of the URI. The display name could say "secure" or "president" while the URI says sip:agent59@telemarketing.example.com 🙃. So prompting with just the display name is not enough, bestie 🚫.
ok so, sometimes the user can approve some REFER requests ahead of time by giving the user agent a policy 📋. This makes sense for call transfer, which [4] covers 📞. A properly authenticated REFER inside an existing SIP dialog to a sip:, sips:, or tel: URI can be accepted through policy without asking the user in the moment ✅. Similarly, accepting a properly authenticated REFER to an HTTP URI might be fine if the referror is on an explicit list of approved referrors 📝. If there's no pre-provided authorization, the user must interactively give permission to reference the indicated resource 🙋♀️.
To see why a policy that blindly accepts and acts on an HTTP URI is so risky, picture a web server that only accepts requests from clients behind a small organization's firewall 🧱. In this soft-creamy-middle environment, the organization trusts all its members and has very little internal security. The web server is also frequently behind on maintenance, so it's open to attacks through maliciously built URIs (which could end up 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 action (like responding to a prompt) before acting on this URI, the risk drops to the same level as clicking a URI in a web browser or email message 🫶.
The same idea applies to URIs with any scheme. An agent that takes automated action to access a URI with a given scheme risks being used to indirectly attack another host that has some security flaw related to that scheme 🕵️♀️. That risk, and the potential harm to the other host, gets worse when the host and agent sit behind a common policy-enforcement point such as a firewall 🚨. On top of that, the agent becomes more exposed to denial of service attacks through resource exhaustion, especially if each automated action opens a new connection 📉.
User agents should be careful when handing an arbitrary URI to a third-party service, like the ones some modern operating systems provide 🖥️. This is especially true if the user agent doesn't know the scheme or the possible ramifications of the protocols it indicates. The chance of 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 💪. But careless use of that power can compromise confidentiality and privacy 🙈. Here are a couple of simple, somewhat contrived examples that show how things could go wrong.
5.3.1 Circumventing Privacy 🕶️
Suppose Alice has a user agent that accepts REFER requests to SIP INVITE URIs, and it NOTIFYs the referrer about the progress of the INVITE by copying each response to the INVITE into the body of a NOTIFY 📨.
Now suppose Carol has a reason to avoid Mallory. She's set up her system at her proxy to only accept calls from a certain set of people she trusts (including Alice), so Mallory doesn't learn when she's around or which user agent she's actually using 🤫.
Mallory can send a REFER to Alice with a Refer-To URI pointing at Carol. If Alice can reach Carol, the 200 OK that Carol sends gets returned to Mallory in a NOTIFY. That tells him not only that Carol is around, but also the IP address of the agent she's using 😭.
5.3.2 Circumventing Confidentiality 🤐
Suppose Alice, with the same user agent as above, works at a company building the greatest SIP device ever invented, the SIP FOO 🤖. The company has spent months building the device and its marketing materials, keeping the idea (and even the name of the idea) secret, because a FOO is the kind of thing anybody could build if they'd just had the idea first 💡. FOO is up and running, and anyone at the company can use it, but it isn't available outside the company firewall 🧱.
Mallory has heard a rumor that Alice's company is onto something big, and he has even gotten his hands on a URI that he suspects has something to do with it 👀. He sends a REFER to Alice with the mysterious URI. As Alice connects to FOO, Mallory gets NOTIFYs with bodies containing:
Server: FOO/v0.9.75.3.3 Limiting the Breach 🧯
For each of these cases, and in general, sending back a carefully selected subset of the information about the progress of the reference through the NOTIFYs reduces the risk 💅. The minimal implementation described in Section 2.4.5 exposes the least information about what the agent handling the REFER request has done, so it's the 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 open to abuse by copying message/sipfrag bodies out of NOTIFY requests and inserting them, in whole or in part, into future NOTIFY requests for 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 NOTIFYs it sends. There's no mechanism here that requires this agent to faithfully forward any information from the referenced party. So saving a body for later replay gives the agent no more ability to affect the mechanism at its peer than it already has without that body. Likewise, if eavesdroppers capture a message/sipfrag body, they get no more ability to affect this mechanism than they'd have without it 👻.
Future extensions might add more constraints on the agent responding to REFER, so it can use the message/sipfrag body 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 to affect the behavior of the receiving UA. Any extension like this will need to define additional mechanisms to protect itself from copy-based attacks 🛡️.
6. Historic Material 🕰️
This method was first motivated by the call-transfer application. It started as TRANSFER, then generalized to REFER, and it improved on the BYE/Also concept of the expired draft-ietf-sip-cc-01 by separating transfers from the processing of BYE 🔄. These changes make it easier to recover from failed transfers and make state management in the participating entities clearer ✨.
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 because of the transaction timeout rules that [1] defines for non-INVITE requests 😵. So a REFER must always get an immediate final response, within the lifetime of a non-INVITE transaction ⏱️.
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 was added to the method sub-registry under http://www.iana.org/assignments/sip-parameters:
REFER [RFC3515]The following information also got added to the header sub-registry under http://www.iana.org/assignments/sip-parameters:
Header Name: Refer-To
Compact Form: r
Reference: RFC 3515This specification registers an event package based on the registration procedures defined in [2]. Here's the information required for that registration:
Package Name: refer
Package or Package-Template: This is a package.
Published Specification: RFC 3515
Person to Contact: Robert Sparks, rsparks@dynamicsoft.com8. 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 on the validity or scope of any intellectual property or other rights that might be claimed to apply to the implementation or use of the technology described in this document, or on whether any license under such rights might be available. It also doesn't say it has made any effort to identify such rights. You can find information about the IETF's procedures for rights in standards-track and standards-related documentation 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 to get a general license or permission to use 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 that may cover technology required to practice this standard 🔍. Please send that information to the IETF Executive Director 💌.
11. Author's Address 📮
Robert J. Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: rsparks@dynamicsoft.com12. Full Copyright Statement ✨
Copyright (C) The Internet Society (2003). All Rights Reserved. 🎀
okay so the legal bit, bestie 💅 Anyone can copy and share this document, and that includes translations. You can also write derivative works that comment on or explain it, or that help people implement it. Publish them, copy them, share them, whatever, as long as you don't put any restrictions on them. The one condition is that the copyright notice and this whole paragraph appear on every copy and every derivative work 🫶
The one thing you can't do is change this document itself. Removing the copyright notice or the references to the Internet Society or other Internet organizations is a no-go 🙅♀️ There are two exceptions. First, you can modify it if you're developing Internet standards, but then you have to follow the copyright procedures in the Internet Standards process. Second, you can modify it to translate it into a language other than English 🌍
These permissions are perpetual, so the Internet Society and its successors or assigns can't take them back later. Forever and ever, periodt 🦋
The disclaimer is the serious part, so I'm keeping the exact wording: 💀
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. 🙌
📦 where this page comes from
- ietf: rfc3515 2003-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms