RFC 5373

Requesting Answering Modes for the Session Initiation Protocol (SIP)

📅 published November 2008, from ietf

RFC 5373 🎀 Requesting Answering Modes for the Session Initiation Protocol (SIP)

Title block first, bestie! 💖

Network Working Group, Request for Comments: 5373. This one is on the Standards Track 🛤️, dated November 2008 📅.

Written by D. Willis, Ed. from Softarmor Systems, and A. Allen from Research in Motion (RIM) 🧑‍💻. Oh, and it doesn't list anything it obsoletes or updates, because the title block has no entry for either one 🤷‍♀️.

Status of This Memo ✨

So this doc is an Internet standards track protocol for the Internet community, and it's basically begging everyone to discuss it and suggest improvements 🗣️. To find out where the protocol stands standardization-wise, check the current edition of the "Internet Official Protocol Standards" (STD1). Distribution of this memo is unlimited 🌈.

Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the day this document was published. Please read these documents carefully, because they explain your rights and restrictions for this document 📜💅.

Abstract 🦋

This doc adds two header fields and their matching option tags to SIP 📮. They're used in INVITE requests to tell the other side how the requester would like the user interface to handle answering that request. The first one, Answer-Mode, says whether the target node's UI should wait for the user to press something before accepting the request, or just accept it without waiting 👆.

The second one, Priv-Answer-Mode, is basically the same thing, except it asks for administrative-level access, which comes with extra authentication and authorization requirements 🔐. These behaviors are useful for stuff like push-to-talk and diagnostics such as loop-back 🎙️. The doc also defines how each header field gets used in a response to show how the request was handled 💬.

Table of Contents 📚

1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
2.  Syntax of Header Fields and Option Tags  . . . . . . . . . . .  5
3.  Usage of the Answer-Mode and Priv-Answer-Mode Header Fields  .  6
4.  Usage of the Answer-Mode and Priv-Answer-Mode Header
    Fields in Requests . . . . . . . . . . . . . . . . . . . . . .  6
  4.1.  The Difference Between Answer-Mode and Priv-Answer-Mode  .  7
  4.2.  The "require" Modifier . . . . . . . . . . . . . . . . . .  9
  4.3.  Procedures at User Agent Clients (UAC) . . . . . . . . . .  9
    4.3.1.  All Requests . . . . . . . . . . . . . . . . . . . . .  9
    4.3.2.  REGISTER Transactions  . . . . . . . . . . . . . . . .  9
    4.3.3.  INVITE Transactions  . . . . . . . . . . . . . . . . . 10
  4.4.  Procedures at Intermediate Proxies . . . . . . . . . . . . 12
    4.4.1.  General Proxy Behavior . . . . . . . . . . . . . . . . 12
    4.4.2.  Issues with Automatic Answering and Forking  . . . . . 12
  4.5.  Procedures at User Agent Servers (UAS) . . . . . . . . . . 13
    4.5.1.  INVITE Transactions  . . . . . . . . . . . . . . . . . 13
5.  Usage of the Answer-Mode and Priv-Answer-Mode Header
    Fields in Responses  . . . . . . . . . . . . . . . . . . . . . 14
  5.1.  Procedures at the UAS  . . . . . . . . . . . . . . . . . . 14
  5.2.  Procedures at the UAC  . . . . . . . . . . . . . . . . . . 15
6.  Examples of Usage  . . . . . . . . . . . . . . . . . . . . . . 15
  6.1.  REGISTER Request . . . . . . . . . . . . . . . . . . . . . 15
  6.2.  INVITE Request . . . . . . . . . . . . . . . . . . . . . . 16
  6.3.  200 (OK) Response  . . . . . . . . . . . . . . . . . . . . 16
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
  7.1.  Attack Sensitivity Depends on Media Characteristics  . . . 17
  7.2.  Application Design Affects Attack Opportunity  . . . . . . 19
  7.3.  Applying the Analysis  . . . . . . . . . . . . . . . . . . 19
  7.4.  Minimal Policy Requirement . . . . . . . . . . . . . . . . 21
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
  8.1.  Registration of Header Fields  . . . . . . . . . . . . . . 22
  8.2.  Registration of Header Field Parameters  . . . . . . . . . 22
  8.3.  Registration of SIP Option Tags  . . . . . . . . . . . . . 22
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
  10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
  10.2. Informative References . . . . . . . . . . . . . . . . . . 24

1. Background 🌸

The usual way a SIP session gets set up ([RFC3261]) goes like this: 1) someone sends a request for a session (a SIP INVITE) and the user on the receiving end gets notified, 2) that user accepts both the request and the session, and 3) a response (SIP 200 OK) goes back to the requester before the session is actually established 📞. Some usage scenarios don't follow this, especially around the notification and acceptance part 🙃. The node receiving the request has always been able to skip notification and acceptance, but there was no standard way for the sender to say "hey, I want this" or "I need this" 🙏. This doc defines a SIP extension header field so the sender can ask for specific treatment during notification and acceptance 💌.

Scenario one is diagnostic loopback calls 🔁. A testing service sends an INVITE to the node under test. The tested node accepts, and a dialog gets set up. But instead of a two-way media flow, the tested node loops back, or "echoes," the media it got from the testing service right back to it 🪞. Then the testing service can check the media flow for quality and timing 📊. SDP usage for this kind of flow is described in [LOOPBACK]. For this type of app, the human using the tested node doesn't have to interact with it at all for the test to run fine 🤓. Sometimes it might make sense to alert the user about the test, and sometimes it might not.

Scenario two is push-to-talk apps, which the Open Mobile Alliance has specified 📻. Here, SIP sets up a dialog that supports asynchronous delivery of a one-way media flow, kind of like an old-school two-way radio 🎧. Usually the INVITEs get automatically accepted by the called UA (User Agent), and the media plays out on a loudspeaker 🔊. The called party's UA microphone doesn't turn on until the user presses the local "talk" button to reply 🎤.

Scenario three is the Private Branch Exchange (PBX) attendant 🏢. Traditional office PBX systems often have intercom functionality 📣. A common use is letting a receptionist turn on the loudspeaker on a desk phone to announce a visitor 🧑‍🤝‍🧑. Not every caller can use the loudspeaker, only the receptionist or operator, and those callers won't always want "intercom" stuff. Sometimes they just want to make a normal call 📱.

There are probably lots more use cases for the extensions in this spec, but this doc was built to meet the requirements of these scenarios, or others with basically similar properties 🧩.

These mechanisms aren't required to act like an "answering machine" or "voice mail recorder" 📼. A device like that already knows it's supposed to answer, so it doesn't need a SIP extension for its behavior 🙋‍♀️.

A lot of the discussion about this in working group meetings and on the mailing list was about separating "answering mode" from "alerting mode" 🧠. Some early work didn't make that distinction. So we're going with these definitions:

  • Answering Mode includes behaviors in a SIP UA relating to accepting or rejecting a request that depend on interaction between the UA and the user of that UA, after the UA has received the request. We're mainly concerned with the user interaction involved in accepting the request and starting an active session. An example would be pressing the "yes" button on a mobile phone ✅.
  • Alerting Mode includes behaviors in a SIP UA relating to telling the user of the UA that a request to start a session has come in. An example would be playing the ring tone on a mobile phone 🔔.

This doc only deals with "Answering Mode." Issues about "Alerting Mode" are outside its scope 🙅‍♀️.

This doc defines two SIP extension header fields: Answer-Mode and Priv-Answer-Mode. They both take the same parameters and work in the same general way 👯‍♀️.

The difference between Answer-Mode and Priv-Answer-Mode is the level of authorization the User Agent Client (UAC) claims and the User Agent Server (UAS) verifies and polices 👮‍♀️. Requests are usually made with Answer-Mode. Requests made with Priv-Answer-Mode ask the UAS for "privileged" treatment 👑. Section 4.1 goes into more detail on this.

Priv-Answer-Mode isn't an assertion of privilege. It's a request for privileged treatment ✨. Think of the UNIX model, where a user can run a command normally, or use "sudo" to ask for administrative privilege for it 💻. Including "Priv-" is like putting "sudo" in front of a UNIX command. In other words, a separate policy table (like /etc/sudoers) gets checked to see whether the user is allowed to get the requested treatment 📋.

Section 4.1 covers this distinction in more detail too 💕.

1.1. Requirements Language 🎀

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 📖.

2. Syntax of Header Fields and Option Tags 🧾

The syntax below is ABNF as defined in [RFC5234]. It also relies on the SIP syntax defined in [RFC3261] 🔤.

Here's the syntax for the header fields this doc defines:

Answer-Mode = "Answer-Mode" HCOLON answer-mode-value
  *(SEMI answer-mode-param)

Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-value
  *(SEMI answer-mode-param)

answer-mode-value = "Manual" / "Auto" / token

answer-mode-param= "require" / generic-param

The SIP option tag that shows support for this extension is answermode 🏷️.

For implementors: SIP header field names and values are always compared in a case-insensitive manner. The pretty capitalization is just for readability. 💅

This syntax has extension hooks (token for answer-mode values and generic-param for optional parameters) that could be defined in the future 🔮. This spec only defines behavior for the values given explicitly above. For forward compatibility, implementations MUST ignore unknown values 🫶. Ignore the unknowns, periodt! 💜

3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields ✨

Okay bestie, so this doc is all about where Answer-Mode and Priv-Answer-Mode are allowed to show up. They're defined for initial (dialog-forming) SIP INVITE requests and for 200 (OK) responses to those requests. It does not define usage in any other sort of request or response, including but not limited to ACK, CANCEL, or any mid-dialog usage. Not me being bossy, that's just the rule 💅

This limit comes from what the extension is for 🎀 It changes how users interact with their devices when they're requesting a new call and when they're answering one. That interaction only happens while the dialog is being formed and during its very first use, not during later stuff like a re-INVITE. BUT (and this is important 🚨) the security stuff from the session initiation still has to apply to changes in the media description brought in by re-INVITEs or similar requests. See Section 7.1 for the full tea on that.

4. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Requests 📞

The Answer-Mode or Priv-Answer-Mode header field is used by a UAC in an INVITE request to ask the responding UAS for special handling. That handling is all about "automatic answering" for whatever dialog comes out of that INVITE. If there's no Answer-Mode or Priv-Answer-Mode header field in the request, answering is up to the UAS, same as it would be without this spec. The desired handling is set by the value of the header field, like so:

  • Manual: The UAS is asked to hold off on accepting the request until the user of the UAS has interacted with the user interface (UI) of the UAS in a way that shows they want it to accept the request.
  • Auto: The UAS is asked to accept the request automatically, without waiting for the user of the UAS to touch the UI in a way that shows they want it to accept the request.

Each value of the Answer-Mode or Priv-Answer-Mode header field can come with an optional parameter called "require". If it's there, it means the UAC would prefer that the UAS reject the request when the UAS isn't willing (maybe because of policy) to answer in the requested mode, instead of answering in some other mode. For example, this parameter could make sure a test "loopback" call doesn't bug a user who set her phone to answer manually, even if the caller asked for an automatic answer. 📱

The UAS is the one in charge of deciding how to honor that preference 👑 In general, the UAS makes an authorization decision based on the authenticated identity in the request, using things like SIP Digest Authentication [RFC3261], the SIP Identity mechanism [RFC4474], or (within restricted networks where it's suitable) the SIP mechanism for asserted identity within trusted networks [RFC3325]. When it's making that call, the UAS should also use any authorization info or policy it has available. This decision-making MUST consider the risk model of the media session that goes with the request, and the UAS MUST NOT answer without user input in cases where the user's privacy or security would be compromised as a result. 🙈 Figuring this out is a matter of system or application design, and you can't really solve it in general by having a set of functions you just switch on or off. Specific talk about media sessions and the right policy is covered in Section 7.

4.1. The Difference Between Answer-Mode and Priv-Answer-Mode 🦋

Answer-Mode and Priv-Answer-Mode are kind of twins 👯‍♀️ They both ask that the UAS handle the request as the header field's value says (automatic or manual). The difference is how each request plays with the UAS's policy. A typical UAS will have different policies for each header field. Say the user of a UAS has put it into "meeting mode" because she's busy with something important and doesn't want random interruptions. That UAS might not allow automatic answering for Answer-Mode requests while it's in "meeting mode". But it might still allow automatic answering for requests made with Priv-Answer-Mode. There'll probably be differences in authorization policy too. For example, a UAS might be set up so callers on the "friends" list can make requests with Answer-Mode but not Priv-Answer-Mode, and only callers on the "administrators" list can use Priv-Answer-Mode. This is different from always basing the behavior on who the caller is. Say caller "Bob" is on both the "friends" list and the "administrators" list. If Bob wants his request handled under the regular policy, he uses Answer-Mode. If Bob wants it handled under the stricter "privileged" policy, he uses Priv-Answer-Mode. 😮‍💨✨

A UAS SHOULD apply a stricter authorization policy to a request with Priv-Answer-Mode than it does to a request with Answer-Mode. The default policy SHOULD be to refuse requests containing Priv-Answer-Mode header fields unless the requester is authenticated and specifically authorized to make Priv-Answer-Mode requests. If a UAS doesn't enforce a policy like that, the user could end up vulnerable to abuses, as discussed in Section 7. 🚨

The use case Priv-Answer-Mode was built for is handling urgent requests from authorized callers 🚑 Like, imagine Larry is a limousine driver working with a fleet dispatcher. Larry loves a quiet car, so his communicator is set to manual answer mode for every non-privileged call, including push-to-talk calls (Answer-Mode: Auto). Every time he gets a call, Larry's communicator chimes softly to let him know. If the circumstances allow it, Larry presses the communicator to accept the call, the communicator sends a 200 (OK) response, and the caller's talk-burst plays out through the communicator's loudspeaker. This treatment applies to any incoming request that has an Answer-Mode header field with a value of "Manual" or "Auto" (or no Answer-Mode header field at all), no matter who the caller is. 🚗

Larry's dispatch operator knows this policy inside and out, and needs to tell Larry about something critical 😬 The operator tries push-to-talk calling Larry a bunch of times (with Answer-Mode: Auto in the requests), but none of the calls get accepted, because Larry has fallen asleep and isn't pressing his communicator to accept anything. 😴

So the operator hits his "urgent" button and calls Larry again. This time the INVITE request carries a Priv-Answer-Mode: Auto header field. Larry's communicator checks who the caller is (using a SIP Identity assertion or a functionally equivalent mechanism) and matches the operator's identity against the list of users allowed to do Priv-Answer-Mode. The operator is on the list, so the communicator immediately sends back a 200 (OK) response accepting the call. The operator talks, and the resulting talk-burst gets blasted out the loudspeaker on Larry's communicator, waking him right up ⏰💥

Requesting Priv-Answer-Mode is not the same thing as just bumping up an Answer-Mode request to a higher privilege based on who's asking and what their authorization level is. That's the whole point, honestly 💖 It's what lets the fleet operator make polite (Answer-Mode: Auto) requests to Larry under normal conditions, and still get different handling (Priv-Answer-Mode: Auto) for a request that's way more urgent.

In normal operations, you'd only use one of Answer-Mode or Priv-Answer-Mode in an INVITE request. If both show up, the UAS first checks whether the requester is authorized for Priv-Answer-Mode. If they are, the UAS processes the request as if only Priv-Answer-Mode had been included. If they aren't authorized for Priv-Answer-Mode, the UAS processes the request as if only Answer-Mode had been included. 🧩

4.2. The "require" Modifier 🔐

Both Answer-Mode and Priv-Answer-Mode allow a "require" modifier (example: Priv-Answer-Mode: Auto;require). This modifier does NOT get a say in the UAS's policy for deciding whether to answer manually or automatically. The UAS decides that based on other stuff in the request. The "require" modifier only gets checked after the UAS has already picked an answering mode. If the UAS's policy ended up with an answering mode that's different from the one in the request, then the "require" modifier tells the UAS to reject the call. In the example above, the UAS is being asked to answer automatically if the caller is authorized for automatic answering under the "privileged" policy, and to reject the call (instead of answering manually) if the caller isn't authorized for that mode. This is talked about in more depth in Section 4.5. 🍓

4.3. Procedures at User Agent Clients (UAC) 📋

4.3.1. All Requests 💌

A UA that supports the Answer-Mode and Priv-Answer-Mode header fields SHOULD show that support by including an option tag of "answermode" in the Supported header field of all the requests it sends.

4.3.2. REGISTER Transactions 📝

To show that it supports the answer-mode negotiation feature, a UA MAY include an extensions parameter with a value that includes "answermode". Example:

;extensions="answermode,100rel,gruu"

This goes in the Contact header field of its REGISTER requests. This way of using feature tags is described in [RFC3840].

If a UA depends on support for callee capabilities in the registrar, it MAY include a Require header field with the value "pref" in its REGISTER request. This makes the registrar reject the request if the registrar doesn't support callee capabilities and caller preferences. Example:

Require: pref

4.3.3. INVITE Transactions 💖

okay so this is where the UAC (the client side 📱) gets to actually flex on the answering mode for an INVITE. A UAC supporting this spec MAY include an Answer-Mode or Priv-Answer-Mode header field in an INVITE if it wants to influence how the responding UAS answers. Iconic behavior, honestly 💅

Note: this only matters in initial or dialog-forming INVITE requests 🎀 Answer-Mode and Priv-Answer-Mode header fields showing up in other requests get ignored, no cap. Generally, if the request wouldn't normally ping the user and get them to accept (think "ringing" and "answering" 📞), then these extensions just don't apply 🙈

To ask the UAS to answer only after it has talked to its user and gotten a yes from that user, the UAC includes an Answer-Mode or Priv-Answer-Mode header field with the value "Manual" 🌸 Like this:

Answer-Mode: Manual

Want the UAS to answer manually AND reject the INVITE if it can't or won't answer manually? Then the UAC adds the value "Manual" plus a parameter of "require" ✨ Example:

Answer-Mode: Manual;require

To ask the UAS to answer automatically without waiting for the user, the UAC uses the value "Auto" 🦋 Example:

Answer-Mode: Auto

And if it wants automatic answering AND wants a rejection when the UAS can't or won't auto-answer, the UAC uses "Auto" with a parameter of "require" 💜 Example:

Answer-Mode: Auto;require

To require that the UAS either supports this extension or rejects the request, the UAC includes a Require header field with the value "answermode" 🧚 This does NOT actually force the UAS to auto-answer, it just means the UAS has to understand the extension or reject the request. There's no SIP negotiation trick to force specific behavior 🙃 Instead, the desired behavior is spelled out in the extension itself. Example:

Require: answermode

To get retargeting proxies on the path to prefer targets that said they support this extension in their registration, a UAC includes an Accept-Contact header field with an extensions parameter set to "answermode" 💅 This Accept-Contact usage is described in [RFC3841]. It's usually paired with the "Require: answermode" header field from above. Example:

Require: answermode Accept-Contact:
          *;extensions="answermode";methods="INVITE"

To tell retargeting proxies on the path NOT to pick targets that said they don't support this extension, the UAC includes an Accept-Contact header field with an extensions parameter of "answermode" and an option field of "require" 🫶 Again, see [RFC3841] for this usage, and it's typically used together with "Require: answermode". Example:

Require: answermode Accept-Contact:
        *;extensions="answermode"; methods="INVITE";require

And if the UAC wants retargeting proxies to ONLY pick targets that support this extension, it uses an Accept-Contact extensions parameter of "answermode" with options "require" and "explicit" 👑 ([RFC3841] again, paired with "Require: answermode") Example:

Require: answermode Accept-Contact:
        *;extensions="answermode";
        methods="INVITE";require;explicit

4.4. Procedures at Intermediate Proxies

4.4.1. General Proxy Behavior

The general rule at every intermediate proxy, including the UAC's serving proxy or proxies and the UAS's serving proxy or proxies, is to ignore the Answer-Mode header field. BUT the serving proxies (the ones responsible for turning an address-of-record (AOR) into a registered contact) MAY take control of the requested answer mode. They can insert or delete an Answer-Mode or Priv-Answer-Mode header field, or change the value of one that's already there, following local policy 🌈 This could lead to behavior that doesn't match what users expect (like a diagnostic loopback call getting answered by a human 💀), so proxies MUST NOT insert, delete, or alter Answer-Mode or Priv-Answer-Mode header fields unless an external agreement between the proxy operator and the user of the UA they're serving explicitly authorizes it. These serving proxies MAY also reject a request according to local policy, and if they do, they SHOULD use the rejection codes specified below for the UAS 🎀

4.4.2. Issues with Automatic Answering and Forking

One well-known issue with forking is multiple acceptance 😭 If an INVITE is forked to several UASs and more than one replies with a 200 (OK) response, the conventional approach is to continue the dialog with the first respondent and tear down the dialog (using BYE requests) with all the other respondents.

This problem exists even without an auto-answer negotiation capability, but it's pretty clear that lots of UAs doing auto-answer will make multiple acceptance WORSE. So systems designers need to think about this. In general, auto-answer is NOT RECOMMENDED in environments that include parallel forking 🙅‍♀️

As an alternative, it might make sense to use a variation on manual-answer combined with no alerting and early media. Here, the initial message or talk-burst is sent as early media to all recipients, where it's displayed or played out. Any response utterance (pushing the transmit key and talking) from the user of a UAS after that would count as an "acceptance," and their UAS would send back a 200 (OK) response. That means the race for acceptance is limited to the UAs actually responding under user control, instead of the whole set of UAs the request was forked to 🏃‍♀️💨

Another option is dynamic conferencing instead of forking. Instead of forking the request, a conference gets started and all registered UAs get invited into it. The mixer attached to the conference then mediates the traffic flows appropriately 🎧

4.5. Procedures at User Agent Servers (UAS)

4.5.1. INVITE Transactions

For a request with an Answer-Mode value of "Manual" and no Answer-Mode parameter of "require", the UAS SHOULD defer accepting the request until the user of the UAS has confirmed they're willing to accept it. This behavior MAY be changed as needed for unattended UASs or other local characteristics or policy. For example, an auto-attendant or Public Switched Telephone Network (PSTN) gateway system that always answers automatically would just go ahead and answer, even with the "Manual" Answer-Mode value 📞✨

For a request with an Answer-Mode value of "Manual" AND an Answer-Mode parameter of "require", the UAS MUST defer accepting the request until the user of the UAS has confirmed they're willing to accept it. If the UAS can't answer the request in this "Manual" mode, or isn't willing to, it MUST reject the request. It SHOULD do that with a "403 (Forbidden)" response, and MAY include a reason phrase of "manual answer forbidden" 🚫💅

For a request with an Answer-Mode value of "Auto", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request without any further user input 🤖 The UAS MAY, according to local policy or user preferences, treat this request the same way it would treat a request with an Answer-Mode value of "Manual" or with no Answer-Mode header field at all. If the calling party is NOT authenticated and authorized for automatic answer, the UAS MAY either handle the request as "manual" or reject it. If the UAS rejects it, it SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden". There may be an interaction with [RFC3261] section 23.2, which in some cases requires user validation of certificates used for S/MIME. Since that puts the same interrupt burden on the user as manually answering would, a UAS hitting this user-validation requirement for a request that needs automatic answering SHOULD reject the request with a "403 (Forbidden)" response, and MAY include a reason phrase of "certificate validation requires user input not compatible with automatic answer." 🔐

For a request with an Answer-Mode value of "Auto" and an Answer-Mode parameter of "require", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request. The UAS MUST NOT allow "manual" answer of this request, but MAY reject it. If, for whatever reason, the UAS decides not to accept the request automatically, the UAS MUST reject it. It SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden" 🙅‍♀️

Priv-Answer-Mode works the same way, except the authorization policy may be different (and usually stricter) 🔒

5. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Responses

The Answer-Mode or Priv-Answer-Mode header field can be added by a UAS to a response to show how it handled the request in terms of automatic answering 🎀 The UAC might use this info to tell the user or adjust how the user interface behaves. The handling is shown by the value of the header field, like so:

Manual: the UAS responded after the user of the UAS interacted with the user interface (UI) in a way that showed they wanted the UAS to accept the request ✅

Auto: the UAS responded automatically, without waiting for the user of the UAS to interact with the UI in a way that showed they wanted it to accept the request 🤖

The Answer-Mode and Priv-Answer-Mode header fields, when used in responses, are only valid in a 200 (OK) response to an INVITE request 💖

5.1. Procedures at the UAS ✨

Okay so, a UAS that supports this spec can pop an Answer-Mode or Priv-Answer-Mode header field into the 200 (OK) response to an INVITE request whenever it wants to tell the UAC if the call was answered manually or automatically 📞💖.

It's totally reasonable for a UAS to assume that if the UAC put an Answer-Mode header field in the request, it probably wants to see one in the response too 🫶. The full reasoning for including or leaving out this header field is outside the scope of this spec, and it's super sensitive to the privacy concerns of whoever is using the UAS 🙈. For example, telling the calling party that a call was answered manually could reveal an "actual human" at the responding UAS. Like, the conversation that follows would usually reveal that anyway, but there might be cases where this info needs protecting 🔒.

So, UASs supporting this spec SHOULD include appropriately configurable policy mechanisms for making this call, and the default configuration SHOULD be to exclude this header field from responses 👑.

5.2. Procedures at the UAC 🎀

A UAC MAY use the value of the Answer-Mode or Priv-Answer-Mode header field, if it's there, to adapt the user interface and/or tell the user how the request was handled 💅. For example, the user of a push-to-talk system might speak differently if she knows the called party answered "in person" vs. having the call blare out of an unattended speaker phone 📢💀.

6. Examples of Usage 🧚

Here's the vibe: Bob registers a contact that supports negotiating answering mode 🦋. Then Alice calls Bob with an INVITE request, asking for automatic answering and explicitly asking that the request not get routed to contacts that haven't indicated support for this extension 🙅‍♀️. She also requires that the request be rejected if Bob's UA doesn't support negotiating answering mode. Bob replies with a 200 (OK) response saying the call was answered automatically ✅.

Heads up 👀: the Content-Length header field shown in the examples has a placeholder "..." instead of a valid Content-Length. Also, the SDP bodies that would be expected in the INVITE requests and 200 (OK) responses aren't shown.

6.1. REGISTER Request 📱

In this example, Bob's UA is registering and saying it supports the answermode extension 💜.

REGISTER sip:example.com SIP/2.0
From: Bob<sip:bob@example.com>
To: Bob <sip:bob@example.com>
CallID: hh89as0d-asd88jkk@cell-phone.example.com
CSeq: 1 REGISTER
Contact: sip:cell-phone.example.com;
  ;audio
  ;+sip.extensions="answermode"
  ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
  ;schemes="sip"

6.2. INVITE Request 📨

In this example, Alice is calling Bob and asking Bob's UA to answer automatically 🤖. However, Alice is willing for Bob to answer manually if Bob's policy is to prefer manual answer, so Alice doesn't include a ";require" modifier on "Answer-Mode: Auto" 🌸.

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>
Call-ID:3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Require: answermode
Accept-contact:*;require;explicit;extensions="answermode"
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...

6.3. 200 (OK) Response 🎉

Here, Bob accepted the call and his UA answered automatically, which it shows in the 200 (OK) response 🥳.

SIP/2.0 200 OK
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
From: Alice <sip:alice@example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>;tag=8321234356
Call-ID: 3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...

7. Security Considerations 🚨

Heads up 🫶: this is the serious section, so read it slowly.

This spec gives a UAC the power to ask for potentially risky user interface behavior when a UAS accepts an INVITE request 😬. Specifically, the UAC can ask the UAS to accept the request without any input from the user of the UAS (Answer-Mode: Auto).

There are several attacks possible here. The most obvious one is turning a phone into a remote listening device without its user knowing 👂💀. Other potential attacks include reverse charge fraud, unsolicited push-to-talk communications (spam over push-to-talk (SPTT)), playout of obnoxious noises (the "whoopee cushion" attack), battery-rundown denial of service, "forced busy" denial of service, running up the victim's data transport bill, and phishing via session insertion (where an ongoing session is replaced by another without the victim's awareness) 😤.

Since SIP implementations don't commonly implement end-to-end message protections, this spec is completely dependent on transitive security across SIP proxies 🔗. Any misbehaving proxy can insert, delete, and/or alter the contents of the Answer-Mode and Priv-Answer-Mode header fields, and generally can do it without either the UAC or UAS noticing 👻. So it's critical that any proxies in the path be not only trusted, but worthy of that trust 🙏. While proxies don't generally insert, delete, or alter the Answer-Mode and Priv-Answer-Mode header fields on purpose, this spec does note a use case for that kind of manipulation: proxies acting on behalf of the user of a UAC or UAS that has limited support for the authentication or policy enforcement needed to securely use these extensions 🧐. Proxies that perform such extension-sensitive manipulation MUST therefore provide complete policy enforcement, as per the minimal policy discussed in Section 7.4.

The existing SIP work already provides strong capabilities for request authentication, preventing man-in-the-middle attacks, protecting the privacy and integrity of media flows, and so on (although as noted above, these usually rely on transitive trust across proxies) 🛡️. The behaviors added by the extensions in this document raise additional possibilities for attacks against media flows that existing SIP work doesn't completely address, and therefore require analysis in this document 🔍.

Media attacks can be loosely categorized as:

  • Insertion: Media is inserted into and played out by the victim UA without consent of the UA's user 📢.
  • Interception: The victim UA's media acquisition facility (such as a microphone or camera) is activated, producing a media stream, without the consent of the UA's user 🎙️.

7.1. Attack Sensitivity Depends on Media Characteristics 🎭

The danger of abuse changes a lot depending on the media characteristics of the session being set up. Since the expressive range of media sessions that SIP can establish is unbounded, we might find it more effective to model loose categories of media modality rather than spelling out every possible scenario 🧩. Security analysis can then be applied per modality.

The media modalities of interest appear to be:

  • UAC-sourced (Inbound) Unidirectional Media Insertion: Sensitive media flows from the UAC and is rendered by the UAS, annoying the user of the UAS or disrupting the function of the UAS 😖. We refer to this as the "whoopee-cushion" attack because of its utility in replicating the rude-noise-making seat cushion 🍑. The danger of this attack is quite literally amplified by a loudspeaker apparatus attached to the victim UAS 🔊. Media that has minimal secondary implication (such as sending a move in a chess game to a computer that isn't running a chess game) is related, but of far less significance ♟️. This sort of attack can also have other consequences, such as discharging the victim's battery or increasing charges for data transport to be paid by the victim 🔋💸.
  • UAS-sourced (Outbound) Unidirectional Media Interception: Sensitive media flows from the UAS and is rendered by the UAC, violating the privacy of the user of the UAS 🕵️‍♀️. We refer to this as the "bug-my-phone" attack because that would appear to be the primary attack motivator 🐛.
  • Bidirectional Media Insertion or Interception: Bidirectional media is the common case when SIP is used in a voice-over-IP scenario or "traditional phone call" ☎️. Once a media flow is established, both ends send and receive media without further engagement. The media information is presumed to be sensitive: if intercepted, it damages the victim's privacy, and if inserted, it annoys or interferes with the recipient 😤. Attacks of this sort might produce either the "whoopee-cushion" or "bug-my-phone" scenarios, potentially even simultaneously 🌀.

It seems reasonable to consider the "bug-my-phone" attack as being in a different class (potentially far more severe) than the "whoopee-cushion" attack 😳. This distinction suggests that security policy could be established in a different and presumably less restrictive fashion for inbound media flows than for outbound media flows. The set of callers from which a user would be willing to automatically accept inbound media is reasonably much broader than the set of callers to which a user would be willing to automatically grant outbound media access, although this may not be true in all environments, especially those where reception of unwanted media has unwanted financial consequences 💰.

For example, assume a UA is designed so it can be used to receive push-to-talk calls to a loudspeaker, and it can also be used as a "baby monitor" (it has an open mic and streams received audio to listeners) 👶. The policy for activating the push-to-talk loudspeaker would probably need to be reasonably broad (perhaps "all the user's buddies") 🥰. However, the policy for the baby monitor would need to be very narrow (perhaps "only the baby's mother") or even completely closed 🔐. The minimal policy defined in Section 7.4 explicitly forbids the "baby monitor" functionality 🚫🌈

7.2. Application Design Affects Attack Opportunity 🎀

okay so in the most common use cases, the security stuff is kinda mitigated by how the app is designed 💅. in traditional telephony, the called party gets alerted (the phone rings 📞), no media session gets set up until they accept (they pick up!), and the media path usually goes to one single-user handset 📱. so this app (even tho it's bidirectional) is relatively secure against both media insertion and media interception attacks of the sort these extensions enable 🔐. but policy-free automatic-answering devices (like answering machines) and amplifiers (speakerphones and call-screening devices) weaken that defense 😬.

in push-to-talk apps 🎙️, media can be sent from the UAC to the UAS without user oversight, but no media gets sent from the called UAS without user input (the "push" of "push-to-talk") 👆. so there's no "bug-my-phone" attack opportunity 🙅‍♀️. also, screening the UAC by kicking out any UAC identities that aren't on some sort of "white list" (often a buddy list) cuts down the threat of "whoopee cushion" attacks 🍑 (except from your buddies, obviously 🫶).

similar approaches work for most apps. insertion can be controlled (but not eliminated) by combining identity mechanisms with simple authorization policy, and interception can be effectively eliminated by combining strong identity mechanisms with aggressive authorization policy and/or user interaction 🔥.

7.3. Applying the Analysis 🧠

okay so the extensions in this document give a UAC a way to request that a UAS skip two of the five defensive mechanisms listed below: user alerting and user acceptance 🙈. so, to avoid creating undue risk of insertion attacks or increased risk of interception attacks, we're basically forced to rely on the remaining defensive mechanisms 🛡️. this document defines a minimum threshold for satisfactory security. more restrictive policies could totally be used, but any policy less restrictive than the approach described below is very likely to cause significant security issues 💀.

from the earlier risk, attack, and vulnerability talk, we can pull out five defensive mechanisms available at the application level ✨:

  1. Identity -- Know who the request came from.
  2. Alerting -- Let the called user know what's happening. Some applications might use inbound media as an alert.
  3. Acceptance -- Require called user to make run-time decision. Asking the user to make a run-time decision without alerting the user to the need to make a decision is generally infeasible. This will have implications for possible alerting options that are outside the scope of this document.
  4. Limit the Input/Output (I/O) -- Turn off loudspeakers or microphone. This could be used to convert a bidirectional media session (very risky, possible "bug my phone") into a unidirectional, inbound-only (less risky, possible "spam" or "rundown", etc.) session while waiting for user acceptance.
  5. Policy -- Rules about other factors, such as black- and whitelisting based on identity, disallowing acceptance without alerting, etc.

SIP and related work already has a bunch of mechanisms for figuring out who sent a request (including SIP Digest Authentication [RFC3261], the SIP Identity mechanism [RFC4474], and the SIP mechanism for asserted identity within private networks [RFC3325], in networks where it's suitable) 🕵️‍♀️. so we assume an appropriately selected mechanism is available for UAs implementing the extensions in this document 💖. basically, UAs implementing these extensions MUST be equipped with and MUST exercise a request-identity mechanism 🔒. the analysis below assumes the identity of each request's sender is either known or known to be unknown, so it can be used in related policy considerations 📋. skipping this identity requirement either opens the door to a wide range of attacks or requires operational policy so tight that these extensions become useless 😭.

we already set up a class distinction between inbound and outbound media flows 🔀, and we can model bidirectional flows as "worst case" sums of the risks of the other two classes 🧮. given that, it makes sense to have separate directionality policy classes for ✨:

  1. Inbound media flows.
  2. Outbound media flows.

for each directionality policy class, we can split the set of request identities into three classes 🍰:

  1. Identities explicitly authorized for the class.
  2. Identities explicitly denied for the class.
  3. Identities for which we have no explicit policy and need the user to make a decision.

not every combination of policies in this breakdown is generally useful 🙅‍♀️. specifically, a policy of "inbound media denied, outbound media allowed" equals a "bug my phone" attack 📵, and it's disallowed by the minimal policy of Section 7.4, which as written excludes all cases of "Outbound media explicitly authorized" 🚫.

7.4. Minimal Policy Requirement 🚫

okay this is the big one, bestie 👑. User agents implementing this specification SHOULD NOT establish a session providing inbound media without explicit user acceptance where the requesting user is unknown, or is known and has not been granted authorization for such a session 🙅‍♀️. this requirement exists to prevent "SPAM broadcast" attacks, where unexpected and unwanted media gets played out at a UAS .

User agents implementing this specification MUST NOT establish a session providing outbound or bidirectional media sourced from the user agent without explicit user acceptance 🚨. loopback media used for connectivity testing is not constrained by this requirement 🧪. this requirement is intended to make sure this extension can't be used to turn a UAS into a remote-controlled microphone (or "bug") without its user knowing 🎤. since SIP lets a session start out with inbound-only media and then transition (via re-INVITE or UPDATE) to an outbound or bidirectional session, enforcing this policy requires dialog-stateful inspection in the SIP UAS 🔍. in other words, if a session was initiated with automatic answering, the UAS MUST NOT transition to a mode that sends outbound media without explicit acceptance by the user of the UAS 😤.

8. IANA Considerations 📚

8.1. Registration of Header Fields 💌

this document defines the new SIP header fields Answer-Mode and Priv-Answer-Mode ✨.

the following rows have been added to the "Header Fields" section of the SIP parameter registry 📝:

           +------------------+--------------+-----------+
           | Header Name      | Compact Form | Reference |
           +------------------+--------------+-----------+
           | Answer-Mode      |              | [RFC5373] |
           | Priv-Answer-Mode |              | [RFC5373] |
           +------------------+--------------+-----------+

8.2. Registration of Header Field Parameters 🎀

this document defines parameters for the header fields from the previous section. the header fields Answer-Mode and Priv-Answer-Mode can take the values Manual or Auto 💅.

the following rows have been added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry 📝:

+------------------+----------------+-------------------+-----------+
| Header Field     | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| Answer-Mode      | require        | No                | [RFC5373] |
| Priv-Answer-Mode | require        | No                | [RFC5373] |
+------------------+----------------+-------------------+-----------+

8.3. Registration of SIP Option Tags 🏷️

this document defines the SIP option tag answermode 🦋.

the following row has been added to the "Option Tags" section of the SIP Parameter Registry 📝:

+------------+------------------------------------------+-----------+
| Name       | Description                              | Reference |
+------------+------------------------------------------+-----------+
| answermode | This option tag is for support of the    | [RFC5373] |
|            | Answer-Mode and Priv-Answer-Mode         |           |
|            | extensions used to negotiate automatic   |           |
|            | or manual answering of a request.        |           |
+------------+------------------------------------------+-----------+

9. Acknowledgements 🫶

this document pulls its requirements and a big chunk of its methodology from the work of the Open Mobile Alliance, specifically a document by Andrew Allen, Jan Holm, and Tom Hallin 🌸.

the editor also wants to shout out David Oran and others who argued on the SIPPING mailing list and at the OMA ad-hoc meeting at IETF 62 🙌. they argued that the underlying ideas of that document were broadly applicable to the SIP community, and that the concepts of alerting and answering should be clearly separated 👑. the security review by Sandy Murphy and the gen-art review by Suresh Krishnan were also super helpful in making this document better 💜.

10. References 📖

10.1. Normative References 💖

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3261] 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.
  • [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
  • [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
  • [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

10.2. Informative References 🌈

  • [LOOPBACK] Hedayat, K., "An Extension to the Session Description Protocol (SDP) for Media Loopback", Work in Progress, August 2008.
  • [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.

Authors' Addresses ✨

Dean Willis (editor)
Softarmor Systems
3100 Independence Pkwy #311-164
Plano, Texas  75075
USA

EMail: dean.willis@softarmor.com


Andrew Allen
Research in Motion (RIM)
300 Knightsbridge Parkway, Suite 360
Lincolnshire, Illinois  60069
USA

EMail: aallen@rim.com
📦 where this page comes from