RFC 4964

The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular

📅 published September 2007, from ietf

RFC 4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular ✨

okay bestie, this is RFC 4964 🎀 It's from September 2007 and its category is Informational. The three authors are A. Allen, Ed. from Research in Motion (RIM), J. Holm from Ericsson, and T. Hallin from Motorola 💅 The title block doesn't list anything it obsoletes or updates, so this RFC isn't replacing or patching an earlier one 🦋

Status of This Memo 🌸

this memo is informational only 🫶 It is not an Internet standard of any kind, and anyone can distribute it freely.

Abstract 💜

this doc describes a private SIP header (a P-header) that the Open Mobile Alliance (OMA) uses for Push to talk over Cellular (PoC) 📱 It only applies to the OMA PoC app, so it's not a general Internet thing 🙈 The P-Answer-State header tells you what answering mode a handset is in, and that's super specific to PoC ✨

Table of Contents 🧚

   1. Introduction ....................................................3
   2. Overall Applicability ...........................................3
   3. Terminology .....................................................3
   4. Background for the Extension ....................................4
   5. Overview ........................................................5
   6. The P-Answer-State Header .......................................6
      6.1. Requirements ...............................................8
      6.2. Alternatives Considered ....................................8
      6.3. Applicability Statement for the P-Answer-State Header ......9
      6.4. Usage of the P-Answer-State Header ........................10
           6.4.1. Procedures at the UA (Terminal) ....................11
           6.4.2. Procedures at the UA (PTT Server) ..................11
           6.4.3. Procedures at the Proxy Server .....................14
   7. Formal Syntax ..................................................14
      7.1. P-Answer-State Header Syntax ..............................14
      7.2. Table of the New Header ...................................14
   8. Example Usage Session Flows ....................................15
      8.1. Pre-Arranged Group Call Using On-Demand Session ...........15
      8.2. 1-1 Call Using Pre-Established Session ....................21
   9. Security Considerations ........................................28
   10. IANA Considerations ...........................................28
      10.1. Registration of Header Fields ............................28
   11. Acknowledgements ..............................................29
   12. References ....................................................29
      12.1. Normative References .....................................29
      12.2. Informative References ...................................30

1. Introduction 🎀

okay so the Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is writing the spec for Push to talk Over Cellular (PoC), which is a service where SIP sets up half-duplex media sessions between a bunch of different people 🎙️ This doc describes a private extension that handles specific PoC needs, and it might not be relevant to the general Internet 💅

so the PoC service lets one SIP User Agent (UA), a PoC terminal, start a session with one or more SIP UAs at the same time 📣 It's usually kicked off when the person pushes a button 🔘

OMA has a whole list of super strict requirements for PoC ✨ To give users a good experience, the initial session setup (from the moment they press the button to the moment they get a signal that they can talk) must be minimized 🏃‍♀️💨 that delay is everything, bestie.

2. Overall Applicability 🦋

the SIP extension in this doc makes some assumptions about network topology and about transitive trust 🕸️ These assumptions are generally NOT APPLICABLE on the Internet as a whole 💀 This mechanism was made to meet OMA's PoC requirements, and there were three situations where it made sense: no general-purpose solution existed, there wasn't enough operational experience to know whether a general solution was even needed, or a more general solution wasn't mature yet 🌈 If you want the full scoop on the assumptions, check out the applicability statement in section 6.3 📖

3. Terminology 💜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] 📚

this doc also introduces a few terms: "PTT Server" (Push to talk Server), "Unconfirmed Indication", "Unconfirmed Response", "Confirmed Indication", and "Confirmed Response" 🫶

a "PTT Server" is a SIP network server that does the network-based jobs for the Push to talk service 🖥️ It can act as a SIP Proxy (as defined in [2]) or as a back-to-back UA (B2BUA) (as defined in [2]), depending on what it needs to do 🔄 A single SIP Push to talk session can involve one or more PTT Servers ✨

an "Unconfirmed Indication" is a sign that the final target UA hasn't been contacted yet, but an intermediate SIP node has info that hints the target UA will probably answer 🔮

an "Unconfirmed Response" is a SIP 18x or 2xx response that carries an "Unconfirmed Indication" 💌

a "Confirmed Indication" means the target UA accepted the session invitation and is ready to receive media 🎉

a "Confirmed Response" is a SIP 200 (OK) response that carries a "Confirmed Indication", and it has the usual meaning of a SIP 200 (OK) response with an answer, like a Session Description Protocol (SDP) answer 👑

4. Background for the Extension 🌸

okay so the PoC terminal could have hardware like a speakerphone or a headset 🎧 It could also have software that lets the user set it up to accept session invitations right away and play the media as soon as it arrives, without the called user having to do anything 🪄 That's called Automatic Answer mode ✨

the user can also set the terminal to alert them first and make them manually accept the invitation before any media comes through 🙋‍♀️ That's called Manual Answer mode 💅 A PoC terminal could support both modes or only one of them 🤷‍♀️ And the user can switch the Answer Mode (AM) configuration whenever they want, depending on their situation and vibe (maybe they're busy, or they're somewhere public where a speakerphone is a no-go) 📵

the OMA PoC Architecture [3] uses PTT Servers inside the network that can act as a conference focus [10], a real-time transport protocol (RTP) translator, or a network policy enforcement server 🏗️ One possible speedup for the delay in telling the caller they can speak is for the PTT server to buffer media packets, so it can send an early "Unconfirmed Indication" back to the caller and let them start talking before the called PoC terminal has answered 🚀 An event package and mechanisms that let a SIP UA tell a PTT Server its current answer mode (so buffering can happen) are defined in [11] 📦 Also, when multiple domains are involved, more than one PTT Server could be in the signaling path for the session 🌐 The PTT Server that does the buffering might not be the one that knows the current answer mode of the SIP UA that's the final destination for the SIP INVITE request 🤯 A mechanism in [12] lets a terminal acting as a SIP UA (or a PTT Server acting as a SIP UA) tell the final destination SIP User Agent Server (UAS) which mode it would prefer to answer in 💖 Still, a mechanism is required for a PTT Server to relay the "Unconfirmed Indication" in a response back toward the originating SIP User Agent Client (UAC) 🔥

5. Overview ✨

okay so the whole point of this extension is to make push to talk feel fast 🎀 The network can give a snappier PTT experience if an intermediate SIP user agent (a PTT Server) sends a SIP 200 (OK) response before the called UA does, and then buffers the media from the calling UA and replays it to the called UA once it answers. Push to talk calls are half-duplex, and the media bursts are short, usually around 10-30 seconds, so that extra end-to-end latency is totally tolerable and the vibe is way better 💅

BUT the PTT Server can only do this when there's a high probability that the called SIP UA is in Automatic Answer mode 👀 PTT Servers near the called UA probably have up-to-date info about its answering mode. Since the cellular network has restricted bandwidth, those servers can pass an indication of the called SIP UA's answering mode upstream faster than the called UA can deliver an automatically generated SIP 200 (OK) response. Iconic 🔥

This document proposes a new SIP header field, the P-Answer-State header field, to support an "Unconfirmed Indication" 🦋 It can optionally be included in a response to a SIP INVITE request, or in a sipfrag of a response included in a SIP NOTIFY request that was sent because of a SIP REFER request asking for a SIP INVITE request to be sent. The header is how a PTT Server acting as a SIP proxy or back-to-back UA says, "hey, I have info suggesting the terminating UA will probably answer automatically." That gives the inviting SIP UA an "Unconfirmed Indication" so it can start transmitting media before it gets a final response from the final destination of the SIP INVITE request 🧚 No Supported or Require headers are needed, because the sender of the P-Answer-State header field doesn't depend on the receiver understanding the extension. If the extension isn't understood, the recipient just ignores the header field. The extension is described below 💜

So here's the flow. When a PTT Server forwards a SIP INVITE request and knows the called UA is likely to be in Automatic Answer mode, it also generates a SIP 183 provisional response with a P-Answer-State header field whose parameter is "Unconfirmed". That tells upstream PTT Servers they can buffer the caller's media 🌸

A PTT Server that wants to buffer the caller's media sees that provisional response with "Unconfirmed", absorbs it, and generates a SIP 200 (OK) response for the caller's SIP UA with an appropriate answer ✨

When the called UA finally generates its SIP 200 (OK) response, the PTT Server that generated the "Unconfirmed" provisional response adds a P-Answer-State header field with the parameter "Confirmed" to that 200 (OK). The buffering PTT Server absorbs that 200 (OK) because it already sent one, and then it starts playing out the buffered media 🎉

6. The P-Answer-State Header 💅

The purpose of the P-Answer-State header field is to let a PTT Server acting as a SIP proxy or back-to-back UA say it has info hinting that the terminating UA named in the Request-URI of the request will likely answer automatically 🧚 That lets the PTT Server give the inviting SIP UA an "Unconfirmed Indication", so it can transmit media before a final response comes back from the final destination of the SIP INVITE request.

Here's the lowdown on provisional responses. If a provisional response has the P-Answer-State header field with the value "Unconfirmed" and does not contain an answer, a receiving PTT Server can send a SIP 200 (OK) response with an answer and a P-Answer-State header field whose value is "Unconfirmed", as long as it's willing to do media buffering 🫶 If the response with "Unconfirmed" does contain an answer, the PTT Server that put the header and answer in that response is also saying it's willing to buffer the media until a final "Confirmed Indication" arrives 🔥

The P-Answer-State header field can show up in a provisional or final response to a SIP INVITE request, or in the sipfrag of a SIP NOTIFY request that was sent because of a SIP REFER request to send a SIP INVITE request. If the "Unconfirmed" value is in a provisional response that contains an answer, the PTT Server is leaving the decision about where to buffer up to the PTT Servers upstream. It will forward a "Confirmed indication" upstream in a SIP 200 (OK) response once the final response arrives from the destination UA 👑

NOTE: It's not intended that multiple PTT Servers buffer serially 🙈 If a PTT Server includes an answer along with the P-Answer-State header field with the value "Unconfirmed" in a provisional response, a receiving PTT Server can decide whether to buffer the media or forward it and let the downstream PTT Server that sent the "Unconfirmed Indication" do the buffering. The idea is that if a PTT Server buffers media, it keeps doing so until a final "Confirmed Indication" is received, so serial buffering by multiple PTT Servers doesn't happen.

The P-Answer-State header only goes in a provisional response when the sending node knows there's a PTT Server acting as a B2BUA that understands this extension somewhere in the signaling path between itself and the originating UAC 🦋 That PTT Server, sitting between the sending node and the originating UAC, will only pass the header field along in a SIP 200 (OK) response, or in the sipfrag (as defined in [4]) of a SIP NOTIFY request (as defined in [5]) sent because of a SIP REFER request (as defined in [6]). This only happens with specific network topologies, which is another reason this header field isn't relevant to the general Internet 🌈 The originating UAC will only ever receive the P-Answer-state header field in a SIP 200 (OK) response or in the sipfrag of a SIP NOTIFY request.

Now, provisional responses that contain the P-Answer-State header field can be sent reliably using the mechanism defined in [13], but that's not required 💖 It's a performance optimization, and if a provisional response is sent unreliably and never arrives, the only result is that buffering doesn't happen. Reliable sending has a catch, though 😭 If the provisional response fails to arrive, the time the sender takes to time out waiting for a SIP PRACK request is likely long enough that, by the time the provisional response is resent, the "Confirmed Response" could already have been received. When provisional responses containing an answer are sent reliably, the 200 (OK) response for the SIP INVITE request can't be sent until the SIP PRACK request is received. So sending provisional responses reliably could potentially delay the "Confirmed Response" 🙈

6.1. Requirements

The OMA PoC service has initial setup performance requirements that a PTT Server acting as a B2BUA can meet by spooling media from the inviting PoC subscriber until one or more invited PoC subscribers have accepted the session 🍓 Here are the specific requirements:

REQ-1: An intermediate server MAY spool media from the inviting SIP UA until one or more invited PoC SIP UASs has accepted the invitation.
REQ-2: An intermediate server that is capable of spooling media MAY accept a SIP INVITE request from an inviting SIP UAC even if no invited SIP UAS has accepted the SIP INVITE request, if it has a hint that the invited SIP UAS is likely to accept the request without requiring user intervention.
REQ-3: An intermediate server or proxy that is incapable of spooling media or does not wish to, but has a hint that the invited SIP UAS is likely to automatically accept the session invitation, MUST be able to indicate back to another intermediate server that can spool media that it has some hint that the invited UAS is likely to automatically accept the session invitation. 🔥
REQ-4: An intermediate server that is willing to spool media from the inviting SIP UAC until one or more invited SIP UASs have accepted the SIP INVITE request SHOULD indicate that it is spooling media to the inviting SIP UAC. ✨

6.2. Alternatives Considered

To meet REQ-3, a PTT Server needs to get an indication back that the invited SIP UA is likely to accept the SIP INVITE request without requiring user intervention 🧚 In that case, the PTT Server that has a hint the invited SIP UAC is likely to accept the request can include an answer state indication in the SIP 183 (Session Progress) response or the SIP 200 (OK) response.

A bunch of alternatives were considered for getting the invited PoC SIP UAS's answer mode settings to another PTT Server or to the inviting SIP UAC 🤔

First up, someone proposed a unique reason-phrase in the SIP 183 response and SIP 200 (OK) response. That got rejected, because reason phrases are meant for human readers and aren't supposed to be parsed by servers for special syntactic and semantic meaning 💀

Next, someone suggested using a Reason header [14] in the SIP 183 response and SIP 200 (OK) response. Also rejected 🙅 It would've been inconsistent with how the Reason header is meant to be used, its usage isn't defined for these response codes, and it would have meant creating and registering a new protocol identifier.

Another idea was a feature-tag in the returned Contact header, as defined in [15]. Rejected too, because it wasn't really a different feature. It's an attribute of the session, and it can be applied to lots of different features 🌸

Someone also proposed a new SDP attribute. The SDP parameter option got rejected because the answer state applies to the session, not to a media stream 🎀

So the P-Answer-State header was chosen to give extra info about the state of SIP session progress and acceptance. Even though the UAC can see that its offer has been answered and accepted, the header lets it know whether the invited PoC subscriber accepted the SIP INVITE request or just an intermediary did 👑

6.3. Applicability Statement for the P-Answer-State Header 🌸

okay so when is P-Answer-State actually useful? ngl this is the part where the spec gets really specific 🧐 It's applicable in these situations:

networks with UAs doing half-duplex communication, where the invited user can't verbally say "yep, got it" to confirm the session got answered, the way people do on a normal full-duplex call 🎙️
where the invited UA can automatically accept the session without any user doing anything 🤖
the network also has intermediate network SIP servers that are trusted 🫶
those intermediate SIP servers know the current answer mode setting of the terminating UAS 👀
those intermediate SIP servers know the media types and codecs the terminating UAS is likely to accept 🎶
those intermediate SIP servers can buffer the media so the inviting user doesn't wait as long before sending media ⏱️
the intermediate network SIP servers assume knowledge of the network topology, and that similar intermediate network SIP servers exist in the signaling path 🗺️

Such configurations are generally not applicable to the Internet as a whole, because those trust relationships just don't exist out there 🌍

And the security part, bestie, it's a lot 😭 Security issues have only been considered for networks that are trusted and use hop-by-hop security mechanisms with transitive trust. Security issues with using this mechanism on the general Internet have not been evaluated. So yeah, that's a whole unknown 💀

6.4. Usage of the P-Answer-State Header 💅

okay, the main event! A UAS, B2BUA, or proxy MAY include a P-Answer-State header field in any SIP 18x or 2xx response that does NOT contain an offer, as long as it's replying to an offer carried in a SIP INVITE request (see [7]). Usually it shows up in a SIP 183 Session Progress or a SIP 200 (OK) response 🎀 A UA that gets a SIP REFER request asking it to send a SIP INVITE request MAY also put a P-Answer-State header field in the sipfrag of a response it includes in a SIP NOTIFY request, which it sends because of the implicit subscription that the SIP REFER created 🔔

Now the parameters, which are the tea ☕ When P-Answer-State has the parameter "Unconfirmed", the UAS or proxy is basically saying "I've got hints that the final destination UAS for the SIP INVITE is likely to auto-accept the session, BUT it's not confirmed." It's possible the final UAS will alert the user and need manual acceptance, or just not accept the session request at all 🫣 When it has the parameter "Confirmed", the UAS or proxy is saying the destination UAS has accepted the session and is ready to receive media ✅ "Confirmed" has the usual meaning of a SIP 200 (OK) response with an answer. It's only there for completeness 💜 A "Confirmed" parameter only shows up in a SIP 200 (OK) response, or in the sipfrag of a 200 (OK) inside the body of a SIP NOTIFY request.

Here's the rule-book, iykyk 📜 A received SIP 18x response without a P-Answer-State header field SHOULD NOT be treated as an "Unconfirmed Response" 🙅‍♀️ A SIP 18x response that has a P-Answer-State header field with the parameter "Confirmed" MUST NOT be treated as a "Confirmed Response", because that's an invalid condition 🚫 And a SIP 200 (OK) response without a P-Answer-State header field MUST be treated as a "Confirmed Response" 💖

6.4.1. Procedures at the UA (Terminal) 📱

A UAC (terminal) that receives an "Unconfirmed Response" containing an answer MAY send media as specified in [7]. BUT, and this is a big but, there's no guarantee the final recipient will actually get that media 😬

How a UAC figures out whether the media reached the final destination, after it got a SIP 2xx response with an "Unconfirmed Indication", is application specific and out of scope for this doc 🤷‍♀️ If the app is a conference, the mechanism in [7] could be used to tell that the invited user joined 🎤 Otherwise, a SIP BYE request could show up, or the media could be put on hold if the final destination UAS doesn't accept the session 📴

A UAC (terminal) that gets, in response to a SIP REFER request, a SIP NOTIFY request containing an "Unconfirmed Response" in a sipfrag in the body of that NOTIFY, related to a dialog where there was a successful offer-answer exchange according to [5], MAY send media. Still no guarantee, though! The media might not reach the final recipient named in the Refer-To header of the original SIP REFER request 🙈 The dialog could be related because the SIP REFER was sent on the same dialog, or because the SIP REFER had a Target-Dialog header (as defined in [16]) that identified the dialog 🧩

A UAC (terminal) that gets an "Unconfirmed Response" with NO answer MAY buffer media until it gets another "Unconfirmed Response" containing an answer, or a "Confirmed Response" 🧺

There are no P-Answer-State procedures for a terminal acting in the UAS role. Just vibes 🌈

6.4.2. Procedures at the UA (PTT Server) 📻

A PTT Server that gets a SIP INVITE at the UAS part of its back-to-back UA MAY include, in any SIP 18x or 2xx response that does not contain an offer, a P-Answer-State header field with the parameter "Unconfirmed". It can do this if it hasn't yet gotten a "Confirmed Response" from the final destination UA, AND it has info hinting the final destination UA is likely to auto-accept the session 🔍

A PTT Server that gets a SIP 18x response to a SIP INVITE containing a P-Answer-State header field with "Unconfirmed" at the UAC part of its back-to-back UA MAY include that P-Answer-State header field with "Unconfirmed" in a SIP 2xx response that the UAS part sends because of receiving that response 🔁 Otherwise, a PTT Server that gets a SIP 18x or 2xx response to a SIP INVITE containing a P-Answer-State header field at the UAC part of its back-to-back UA SHOULD include the P-Answer-State header field unmodified in the SIP 18x or 2xx response that the UAS part sends because of receiving it 🪞 If the response the UAS part sends is a SIP 18x response, then the P-Answer-State header field in it MUST contain a parameter of "Unconfirmed" 🫡

The UAS part of a PTT Server's back-to-back UA MAY include an answer in the "Unconfirmed Response" it sends, even if the "Unconfirmed Response" the UAC part received didn't have one 🎁

If a PTT Server gets a "Confirmed Response" at the UAC part of its back-to-back UA, then the UAS part MAY include a P-Answer-State header field with the parameter "Confirmed" in the forwarded response 🥳 If the UAS part already sent an "Unconfirmed Response" as part of this dialog, the UAS part SHOULD include a P-Answer-State header field with "Confirmed" in the forwarded "Confirmed Response" 💫

If the UAS part of a PTT Server's back-to-back UA includes an answer in a response along with a P-Answer-State header field with "Unconfirmed", then it needs to be ready to receive media as specified in [7] 🎧 It MAY also buffer any media it receives, until the UAC part gets a "Confirmed Response" from the final destination UA, or until its buffer is full 🪣

A UAS part of a PTT Server's back-to-back UA that gets a SIP REFER request to send a SIP INVITE to another UA (as specified in [6]) MAY generate a sipfrag of a SIP 200 (OK) response containing a P-Answer-State header field with "Unconfirmed". It can do this before the UAC part gets a response to that SIP INVITE, IF it has info hinting the final destination UA is likely to auto-accept the session 🏃‍♀️

If the UAC part of a PTT Server's back-to-back UA sent a SIP INVITE because it got a SIP REFER request, and it gets a SIP 18x or 2xx response containing a P-Answer-State header field at the UAC part, then the UAS part SHOULD include that P-Answer-State header field in the sipfrag of the response in a SIP NOTIFY request. The P-Answer-State header field in the sipfrag keeps the parameters from the original P-Answer-State unmodified 📋 This is the SIP NOTIFY request the UAS part sends in response to the original SIP REFER request, based on receiving that SIP 18x or 2xx response 📨 If the sipfrag response in that NOTIFY is a SIP 18x response, then the P-Answer-State header field in the sipfrag MUST contain a parameter of "Unconfirmed" 🙌 If the UAC part gets a "Confirmed Response" that doesn't have a P-Answer-State header field, the UAS part MAY include a P-Answer-State header field with "Confirmed" in the sipfrag of the response in the SIP NOTIFY it sends in response to the SIP REFER 🌟

Now the tricky case, where a PTT Server's UAS part already sent a SIP NOTIFY because of the SIP REFER request:

the SIP NOTIFY request has a P-Answer-State header field with the parameter "Unconfirmed" in the sipfrag of a response, and
the PTT Server later gets a "Confirmed Response" to the SIP INVITE at the UAC part of its back-to-back UA.

In that situation, such a PTT Server SHOULD include a P-Answer-State header field with "Confirmed" in the sipfrag of the response in the next SIP NOTIFY request its UAS part sends because it got that "Confirmed Response" 🔔💖

If the SIP REFER request is related to an existing dialog that was set up by a SIP INVITE with a successful offer-answer exchange, the UAS part of its back-to-back UA MUST be ready to receive media as specified in [7] 📡 It MAY also buffer any media it receives until the UAC part of its back-to-back UA gets a "Confirmed Response" from the final destination UA, or until its buffer is full 🫧 The dialog could be related because the SIP REFER was sent on the same dialog, or because the SIP REFER had a Target-Dialog header (as defined in [16]) that identified the dialog 🧠

Last but DEFINITELY not least 🫶 A PTT Server that buffers media SHOULD be prepared for the possibility of never getting a "Confirmed Response," and SHOULD release the session if a "Confirmed Response" isn't received before the buffer overflows 💀 Like, don't hoard the media forever, bestie 😭✨

6.4.3. Procedures at the Proxy Server ✨

okay so SIP proxy servers don't need to understand what the P-Answer-State header field means 🫶 under the regular SIP rules for unknown headers, a proxy just forwards them along, no drama.

a PTT Server acting as a proxy MAY slap a P-Answer-State header field with the parameter Unconfirmed onto a SIP 18x response it originates (done the [2]-compliant way, obvs) if it has info hinting that the final destination UA for the SIP INVITE request is likely to auto-accept the session 🔮 it's giving "I can tell you're gonna pick up" energy 📞

and a PTT Server acting as a proxy MAY also add a P-Answer-State header field with the parameter Confirmed to a "Confirmed Response" 💅 main character energy for sure 👑

7. Formal Syntax 📝

the mechanisms in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in [8] 💖 a bunch of BNF definitions are inherited from SIP and aren't repeated here, so implementers need to be familiar with the notation and contents of SIP [2] and [8] to get what's going on 🤓

7.1. P-Answer-State Header Syntax 🎀

here's how the P-Answer-State header is written:

P-Answer-State = "P-Answer-State" HCOLON answer-type
                 *(SEMI generic-param)
answer-type = "Confirmed" / "Unconfirmed" / token

7.2. Table of the New Header 🌸

Table 1 gives the extra table entries for the P-Answer-State header. These extend Table 2 in SIP [2], section 7.1 of the SIP-specific event notification [5], Tables 1 and 2 in the SIP INFO method [17], Tables 1 and 2 in Reliability of provisional responses in SIP [13], Tables 1 and 2 in the SIP UPDATE method [18], Tables 1 and 2 in the SIP extension for Instant Messaging [19], Table 1 in the SIP REFER method [6], and Table 2 in the SIP PUBLISH method [20] 🧚

      Header field          where  proxy  ACK BYE CAN INV OPT REG SUB
      _______________________________________________________________
      P-Answer-State      18x,2xx    ar    -   -   -   o   -   -   -

      Header field                        NOT PRA INF UPD MSG REF PUB
      _______________________________________________________________
      P-Answer-State          R            -   -   -   -   -   -   -

Table 1: Additional Table Entries for the P-Answer-State Header

8. Example Usage Session Flows 🧚

for simplicity, some details like intermediate proxies and SIP 100 Trying responses don't show up in these example flows 🙈

8.1. Pre-Arranged Group Call Using On-Demand Session 📞

okay so this flow shows Alice making a pre-arranged group call using a Conference URI with Bob on the member list 💜 the session starts with the on-demand session establishment mechanism, where a SIP INVITE request containing an SDP offer gets sent by Alice's terminal the moment Alice pushes her push to talk button 🔥

in this example, Alice's PTT Server acts a Call Stateful SIP Proxy, and Bob's PTT Server (which knows the current Answer Mode setting of Bob's terminal is Auto Answer) acts as a B2BUA ✨

for simplicity, the invitations from the Conference Focus to the other group members aren't shown here 🫶

   Alice's        Alice's       Conference     Bob's          Bob's
   Terminal      PTT Server       Focus      PTT Server    Terminal
      |              |              |             |              |
      |--(1)INVITE-->|              |             |              |
      |              |--(2)INVITE-->|             |              |
      |              |              |--(3)INVITE->|              |
      |              |              |             |--(4)INVITE-->|
      |              |              |<--(5)183----|              |
      |              |<---(6)200----|             |              |
      |<---(7)200----|              |             |              |
      |----(8)ACK--->|              |             |              |
      |              |---(9)ACK---->|             |              |
      |              |              |             |              |
      |=====Early Media Session====>|             |              |
      |              |            MEDIA           |              |
      |              |           BUFFERING        |              |
      |              |              |             |<---(10)200---|
      |              |              |             |---(11)ACK--->|
      |              |              |<--(12)200---|              |
      |              |              |--(13)ACK--->|              |
      |              |              |             |              |
      |              |              |========Media Session======>|
      |              |              |             |              |
      |              |              |             |              |

Figure 1: Pre-Arranged Group Call Using On-Demand Session

1 INVITE Alice -> Alice's PTT Server

INVITE sip:FriendsOfAlice@example.org SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)

2 INVITE Alice's PTT Server -> Conference Focus

INVITE sip:FriendsOfAlice@example.org SIP/2.0
Via: SIP/2.0/UDP
     AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)

The Conference Focus explodes the Conference URI and Invites Bob 💥

3 INVITE Conference Focus -> Bob's PTT Server

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)

4 INVITE Bob's PTT Server -> Bob

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
     BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPTTServer.example.com>
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)

5 183 (Session Progress) Bob's PTT Server -> Conference Focus

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6c85cf
From: "Alice's Friends"
<sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0

6 200 (OK) Conference Focus -> Alice's PTT Server

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP
     pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
To: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice"
     <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)

7 200 (OK) Alice's PTT Server -> Alice

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org>
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)

8 ACK Alice -> Alice's PTT Server

ACK sip:AlicesConferenceFocus.example.org SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9
Route: <sip:AlicesPTTServer.example.org>
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0

9 ACK Alice's PTT Server -> Conference Focus

ACK sip:AlicesConferenceFocus.example.org SIP/2.0
Via: SIP/2.0/UDP
     AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP
     pc33.example.org;branch=z9hG4bKnashds9
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0

the early half-duplex media session between Alice and the Conference Focus is now up 🎧 and the Conference Focus buffers the media it gets from Alice 🫧

10 200 (OK) Bob -> Bob's PTT Server

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     BobsPTTServer.example.com;branch=z9hG4bKa27bc93
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131

(SDP not shown)

11 ACK Bob's PTT Server -> Bob

ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0

12 200 (OK) Bob's PTT Server -> Conference Focus

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131

(SDP not shown)

13 ACK Conference Focus -> Bob's PTT Server

ACK sip:BobsPTTServer.example.com SIP/2.0
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob"
     <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0

the media session between Alice and Bob is now established 🌈 and the Conference Focus forwards the buffered media to Bob 🦋

8.2. 1-1 Call Using Pre-Established Session

okay so this flow is literally about Alice calling Bob 1-1 using a pre-established session 📞✨. A pre-established session is where Alice's terminal sets up a dialog with her PTT Server through a SIP INVITE SDP offer-answer exchange, so the codecs and other media parameters are already agreed on before she even starts a communication 🧚. Then, when she wants to talk to Bob, a SIP REFER request asks her PTT Server to send a SIP INVITE to Bob 💅. Bob's terminal does not use the pre-established session mechanism in this example, so no shortcuts for him 🙈.

Alice's PTT Server is doing a lot here. It acts as a B2BUA and also performs the Conference Focus function 👑. Bob's PTT Server acts as a B2BUA too, and it knows that Bob's terminal has its Answer Mode set to Auto Answer 🫶.

   Alice's                Alice's               Bob's          Bob's
   Terminal             PTT Server /          PTT Server     Terminal
                     Conference Focus
      |                       |                  |                |
      |-----(1)INVITE-- ----->|                  |                |
      |<-----(2)200-----------|                  |                |
      |-------(3)ACK--------->|                  |                |
      |                       |                  |                |
      |                       |                  |                |
      |                       |                  |                |
      |----(4)REFER---------->|                  |                |
      |<-----(5)202-----------|                  |                |
      |                       |----(6)INVITE---->|                |
      |                       |                  |--(7)INVITE---->|
      |                       |                  |                |
      |                       |<----(8)183-------|                |
      |<---(9)NOTIFY----------|                  |                |
      |-----(10)200---------->|                  |                |
      |                       |                  |                |
      |=Early Media Session==>|                  |                |
      |                     MEDIA                |                |
      |                   BUFFERING              |                |
      |                       |                  |<---(11)200-----|
      |                       |                  |---(12)ACK----->|
      |                       |<----(13)200------|                |
      |                       |-----(14)ACK----->|                |
      |                       |===========Media Session==========>|
      |                       |                  |                |
      |<---(15)NOTIFY---------|                  |                |
      |-----(16)200---------->|                  |                |
      |                       |                  |                |

Figure 2: 1-1 Call Using Pre-Established Session

1 INVITE Alice -> Alice's PTT Server 💖

INVITE sip:AlicesConferenceFactoryURI.example.org SIP/2.0 Via:
SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org> From: "Alice"
<sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq:
314159 INVITE Contact: <sip:alice@pc33.example.org> Content-Type:
application/sdp Content-Length: 142

(SDP not shown)

2 200 (OK) Alice's PTT Server -> Alice ✨

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
Content-Type: application/sdp
Content-Length: 131

(SDP not shown)

3 ACK Alice -> Alice's PTT Server 🎀

ACK sip:AlicesPre-establishedSession@AlicesPTTServer.example.org
     SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0

Alice's terminal has established a Pre-established Session with Alice's PTT Server. All the media parameters are pre-negotiated for use at communication time 🦋.

Now Alice initiates a communication to Bob 🌸.

4 REFER Alice -> Alice's PTT Server 🔥

REFER sip:AlicesPre-establishedSession@AlicesPTTServer.example.org
     SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Refer-To: "Bob" <sip:bob@example.com>
Contact: <sip:alice@pc33.example.org>

5 202 (ACCEPTED) Alice's PTT Server -> Alice 🌈

SIP/2.0 202 ACCEPTED
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>

6 INVITE Conference Focus -> Bob's PTT Server 💜

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bk4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:Alice@example.org>;tag=2178309898
Referred-By: <sip:Alice@example.org>
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.example.org>
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)

7 INVITE Bob's PTT Server -> Bob 🍓

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP
     BobsPTTServer.example.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:Alice@example.org>;tag=781299330
Referred-By: <sip:Alice@example.org>
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPTTServer.example.com>
Content-Type: application/sdp
Content-Length: 142

(SDP not shown)

8 183 (Session Progress) Bob's PTT Server -> Conference Focus ⭐

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:Alice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0

9 NOTIFY Alice's PTT Server -> Alice 🦋

NOTIFY sip:alice@pc33.example.org SIP/2.0
Via: SIP/2.0/UDP
     AlicesPre-establishedSession@AlicesPTTServer.example.org;
     branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
Contact:
     <sip:AlicesPre-establishedSession@AlicesPTTServer.example.org>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 99

SIP/2.0 183 Session Progress
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Unconfirmed

10 200 (OK) Alice -> Alice's PTT Server 🫶

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     AlicesPre-establishedSession@AlicesPTTServer.example.org;
     branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY

The early half-duplex media session between Alice and the Conference Focus is now established, and the Conference Focus buffers the media it receives from Alice. 🔥

11 200 (OK) Bob -> Bob's PTT Server 💅

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     BobsPTTServer.example.com;branch=z9hG4bK927bc93
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131

(SDP not shown)

12 ACK Bob's PTT Server -> Bob 🌸

ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=d28119a
From: "Alice" <sip:Alice@example.org>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0

F13 200 (OK) Bob's PTT Server -> Conference Focus 🧚

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice's Friends"
     <sip:FriendsOfAlice@example.org>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPTTServer.example.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131

(SDP not shown)

14 ACK Conference Focus -> Bob's PTT Server 👑

ACK sip:BobsPTTServer.example.com SIP/2.0
Via: SIP/2.0/UDP
     AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>;tag=a6670811
From: "Alice" <sip:Alice@example.org>;tag=1928301774
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0

The media session between Alice and Bob is now established, and the Conference Focus forwards the buffered media to Bob. 🎀

15 NOTIFY Alice's PTT Server -> Alice 💖

NOTIFY sip:alice@pc33.example.org SIP/2.0
Via: SIP/2.0/UDP
     AlicesPre-establishedSession@AlicesPTTServer.example.org;
     branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
Contact: <sip:AlicesPre-establishedSession@
AlicesPTTServer.example.org>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 83

SIP/2.0 200 OK
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Confirmed

16 200 (OK) Alice -> Alice's PTTServer ✨

SIP/2.0 200 OK
Via: SIP/2.0/UDP
     AlicesPre-establishedSession@AlicesPTTServer.example.org;
     branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
From: "Alice" <sip:alice@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY

9. Security Considerations ✨

okay bestie, security time 🔐😭 the P-Answer-State header is not really a secret-y thing. it's just informational 🧚 it tells the UAC that any media it sends because of an answer in this response is not guaranteed to get delivered 📬 and an eavesdropper literally cannot learn anything useful by reading the header's contents 🙈

but the header gets added and used by proxies and intermediate UAs, so end-to-end protection is not the right fit here 💅 that means a "malicious" proxy between the UAs, or an attacker sitting on the signaling path, could add or remove the header or change its value 💀 this can go two ways:

it denies the caller the knowledge that the callee has not been contacted yet
it falsely says the callee has not been contacted yet, even though they already answered

the second one is the scary one 😭 the caller might decide not to send media, because they don't want an intermediary storing their media, even though the callee actually picked up. the first one is way less of a worry 🌸 it doesn't seem to be a big deal, since it's the same thing that happens when a B2BUA sends a 200 (OK) before the callee has answered, even without this extension.

so it's really important to protect the messages between proxies 🛡️ implementations SHOULD use a transport that provides integrity and confidentiality between the signaling hops 🫶 Transport Layer Security (TLS) [9] based signaling in SIP can be used to get that protection, iykyk 🔒

one more thing 👑 security issues were only considered for networks that are trusted and use hop-by-hop security mechanisms with transitive trust. how this mechanism would behave on the general Internet has not been evaluated. so keep that in mind, babe 🚨

10. IANA Considerations 🎀

10.1. Registration of Header Fields

this document defines a private SIP extension header field (one that starts with the prefix "P-") 🦋 it follows the registration procedures in RFC 3427 [21] 📋

the following row has been added to the "Header Fields" section of the SIP parameter registry 💜

            +----------------+--------------+-----------+
            | Header Name    | Compact Form | Reference |
            +----------------+--------------+-----------+
            | P-Answer-State |              | [RFC4964] |
            +----------------+--------------+-----------+

11. Acknowledgements 🫶

the authors want to thank Jon Peterson, Cullen Jennings, Jeroen van Bemmel, Paul Kyzivat, Dale Worley, Dean Willis, Rohan Mahay, Christian Schmidt, Mike Hammer, and Miguel Garcia-Martin for their comments, which helped move this work forward 🌈 they also want to thank the OMA POC Working Group members for their support 💖 and especially Tom Hiller, who presented the concept of the P-Answer-State header to SIPPING at IETF 62 ✨ iconic behavior, honestly 👑

12. References 📚

12.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   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.

   [3]   OMA, "Push to talk over Cellular - Architecture",
         OMA-AD-PoC-V1_0_1-20061128-A, November 2006.

   [4]   Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
         November 2002.

   [5]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [6]   Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [7]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [8]   Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

   [9]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

12.2. Informative References

   [10]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol (SIP)", RFC 4353, February 2006.

   [11]  Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event
         Package and Data Format for Various Settings in Support for the
         Push-to-Talk over Cellular (PoC) Service", RFC 4354, January
         2006.

   [12]  Willis, D., Ed., and A. Allen, "Requesting Answering Modes for
         the Session Initiation Protocol (SIP)", Work in Progress, June
         2007.

   [13]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262, June
         2002.

   [14]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
         Field for the Session Initiation Protocol (SIP)", RFC 3326,
         December 2002.

   [15]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
         User Agent Capabilities in the Session Initiation Protocol
         (SIP)", RFC 3840, August 2004.

   [16]  Rosenberg, J., "Request Authorization through Dialog
         Identification in the Session Initiation Protocol (SIP)", RFC
         4538, June 2006.

   [17]  Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [18]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

   [19]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [20]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [21]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
         Rosen, "Change Process for the Session Initiation Protocol
         (SIP)", BCP 67, RFC 3427, December 2002.

Authors' Addresses 🏡

   Andrew Allen (editor)
   Research in Motion (RIM)
   102 Decker Court, Suite 100
   Irving, Texas  75062
   USA

   EMail: aallen@rim.com


   Jan Holm
   Ericsson
   Tellusborgsvagen 83-87
   Stockholm  12526
   Sweden

   EMail: Jan.Holm@ericsson.com


   Tom Hallin
   Motorola
   1501 W Shure Drive
   Arlington Heights, IL  60004
   USA

   EMail: thallin@motorola.com

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🔖

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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. It also does not represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💜✨

📦 where this page comes from

ietf: rfc4964 2007-09
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms