idnits 2.17.1 draft-allen-sipping-poc-p-answer-state-header-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1423. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 644 has weird spacing: '... where proxy...' == Line 646 has weird spacing: '...18x,2xx ar ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6255 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1261 ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4234 (ref. '8') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (ref. '9') (Obsoleted by RFC 5246) == Outdated reference: A later version (-07) exists of draft-ietf-sip-answermode-01 -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '17') (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '21') (Obsoleted by RFC 5727) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group A. Allen, Ed. 3 Internet-Draft Research in Motion (RIM) 4 Intended status: Experimental J. Holm 5 Expires: September 5, 2007 Ericsson 6 T. Hallin 7 Motorola 8 March 4, 2007 10 The P-Answer-State Header Extension to the Session Initiation Protocol 11 for the Open Mobile Alliance Push-to-talk over Cellular 12 draft-allen-sipping-poc-p-answer-state-header-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 5, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes a private Session Initiation Protocol(SIP) 46 header (P-header) used by the Open Mobile Alliance (OMA), for Push- 47 to-talk over Cellular (PoC) along with its applicability, which is 48 limited to the OMA PoC application. The P-Answer-State header is 49 used for indicating the answering mode of the handset which is 50 particular to the PoC application. 52 Table of Contents 54 1. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Background for the Extension . . . . . . . . . . . . . . . . . 4 62 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. The P-Answer-State Header . . . . . . . . . . . . . . . . . . 6 65 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Alternatives Considered . . . . . . . . . . . . . . . . . 8 67 6.3. Applicability Statement for the P-Answer-State Header . . 9 68 6.4. Usage of the P-Answer-State Header . . . . . . . . . . . . 10 69 6.4.1. Procedures at the UA (Terminal) . . . . . . . . . . . 11 70 6.4.2. Procedures at the UA (PTT Server) . . . . . . . . . . 11 71 6.4.3. Procedures at the Proxy Server . . . . . . . . . . . . 13 73 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7.1. P-Answer-State Header Syntax . . . . . . . . . . . . . . . 14 75 7.2. Table of the New Header . . . . . . . . . . . . . . . . . 14 77 8. Example Usage Session Flows . . . . . . . . . . . . . . . . . 14 78 8.1. Pre-arranged Group Call Using On-demand Session . . . . . 15 79 8.2. 1-1 Call Using Pre-established Session . . . . . . . . . . 20 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 10.1. Registration of Header Fields . . . . . . . . . . . . . . 27 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 93 Intellectual Property and Copyright Statements . . . . . . . . . . 31 95 1. Overall Applicability 97 The SIP extension specified in this document makes certain 98 assumptions regarding network topology and the existence of 99 transitive trust. These assumptions are generally NOT APPLICABLE in 100 the Internet as a whole. The mechanism specified here was designed 101 to satisfy the requirements specified by the Open Mobile Alliance for 102 Push-to-talk over Cellular for which either no general-purpose 103 solution was found, where insufficient operational experience was 104 available to understand if a general solution is needed, or where a 105 more general solution is not yet mature. For more details about the 106 assumptions made about this extension, consult the Applicability 107 subsection 6.3. 109 2. Introduction 111 The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is 112 specifying the Push-to-talk Over Cellular (PoC) service where SIP is 113 the protocol used to establish half duplex media sessions across 114 different participants. This document describes a private extension 115 to address specific requirements of the PoC service and may not be 116 applicable to the general Internet. 118 The PoC service allows a SIP User Agent (UA) (PoC terminal) to 119 establish a session to one or more SIP UAs simultaneously, usually 120 initiated by the initiating user pushing a button. 122 OMA has defined a collection of very stringent requirements in 123 support of the PoC service. In order to provide the user with a 124 satisfactory experience the initial session establishment from the 125 time the user presses the button to the time they get an indication 126 to speak must be minimized. 128 3. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [1]. 134 The terms "PTT Server" (Push-to-talk Server), "Unconfirmed 135 Indication", "Unconfirmed Response", "Confirmed Indication" and 136 "Confirmed Response" are introduced in this document. 138 A "PTT Server" as referred to here is a SIP network server that 139 performs the network based functions for the Push to Talk service. 140 The PTT Server can act as a SIP Proxy as defined in [2] or a back-to- 141 back UA (B2BUA) as defined in [2] based on the functions it needs to 142 perform. There can be one or more PTT Servers involved in a SIP Push 143 to Talk session. 145 An "Unconfirmed Indication" as referred to here is an indication that 146 the final target UA for the request has yet to be contacted and an 147 intermediate SIP node is indicating that it has information that 148 hints that the request is likely to be answered by the target UA. 150 An "Unconfirmed Response" is a SIP 18x or 2xx response containing an 151 "Unconfirmed Indication". 153 A "Confirmed Indication" as referred to here is an indication that 154 the target UA has accepted the session invitation and is ready to 155 receive media. 157 A "Confirmed Response" is a SIP 200 (OK) response containing a 158 "Confirmed Indication" and has the usual semantics of a SIP 200 (OK) 159 response containing an answer (such as a Session Description Protocol 160 (SDP) answer). 162 4. Background for the Extension 164 The PoC terminal could support such hardware capabilities as a 165 speaker phone and/or headset and software that provide the capability 166 for the user to configure the PoC terminal to accept the session 167 invitations immediately and play out the media as soon as it is 168 received without requiring the intervention of the called user. This 169 mode of operation is known as Automatic Answer mode. The user can 170 alternatively configure the PoC terminal to first alert the user and 171 require the user to manually accept the session invitation before 172 media is accepted. This mode of operation is known as Manual Answer 173 mode. The PoC terminal could support both or only one of these modes 174 of operation. The user can change the Answer Mode (AM) configuration 175 of the PoC terminal frequently based on their current circumstances 176 and preference,(perhaps because the user is busy, or in a public area 177 where she cannot use a speaker phone, etc). 179 The OMA PoC Architecture [3] utilizes PTT Servers within the network 180 that can perform such roles as a conference focus [10], a real-time 181 transport protocol (RTP) translator or a network policy enforcement 182 server. A possible optimization to minimize the delay in the 183 providing of the caller with an indication to speak is for the PTT 184 server to perform buffering of media packets in order to provide an 185 early or "Unconfirmed Indication" back to the caller and allow the 186 caller to start speaking before the called PoC terminal has answered. 187 An event package and mechanisms for a SIP UA to indicate its current 188 answer mode to a PTT Server in order to enable buffering are defined 189 in [11]. In addition, particularly when multiple domains are 190 involved in the session, more than one PTT server could be involved 191 in the signaling path for the session. Also the PTT Server that 192 performs the buffering might not be the PTT Server that has knowledge 193 of the current answer mode of the SIP UA that is the final 194 destination for the SIP INVITE request. A mechanism to allow a 195 terminal that acts as a SIP UA or a PTT server that acts as a SIP UA 196 to indicate a preference to the final destination SIP User Agent 197 Server (UAS) to answer in a particular mode is defined in [12]. 198 However a mechanism is required for a PTT Server to relay the 199 "Unconfirmed Indication" in a response back towards the originating 200 SIP User Agent Client (UAC). 202 5. Overview 204 The purpose of this extension is to support an optimization that 205 makes it possible for the network to provide a faster push-to-talk 206 experience, through an intermediate SIP agent (PTT Server) providing 207 a SIP 200 (OK) response before the called UA does, and a PTT Server 208 buffering the media generated by the calling UA for replay to the 209 called UA when it answers. Because of the half duplex nature of the 210 call where media bursts are short typically in the order of 10-30 211 seconds the additional end to end latency can be tolerated and this 212 considerably improves the user experience. However the PTT Server 213 only can do this when there is a high probability the called SIP UA 214 is in Automatic Answer mode. It is likely that PTT Servers near the 215 called UA have up-to-date knowledge of the answering mode of the 216 called UA, and due to the restricted bandwidth nature of the cellular 217 network, they can pass upstream an indication of the called SIP UA's 218 answering mode faster than the called UA can deliver an automatically 219 generated SIP 200 (OK) response. 221 This document proposes a new SIP header field the P-Answer-State 222 header field to support an "Unconfirmed Indication". The new SIP 223 header field can be optionally included in a response to a SIP INVITE 224 request or in a sipfrag of a response included in a SIP NOTIFY 225 request sent as a result of a SIP REFER request that requests a SIP 226 INVITE request to be sent. The header field is used to provide an 227 indication from a PTT Server acting as a SIP proxy or back-to-back UA 228 that it has information that hints that the terminating UA will 229 likely answer automatically. This provides an "Unconfirmed 230 Indication" back towards the inviting SIP UA to transmit media prior 231 to receiving a final response from the final destination of the SIP 232 INVITE request. No supported or require headers are needed because 233 the sender of the P-Answer-State header field does not depend on the 234 receiver to understand the extension and if the extension is not 235 understood the header field is simply ignored by the recipient. The 236 extension is described below. 238 Thus, when a PTT Server forwards a SIP INVITE request and knows that 239 the called UA is likely to be in Automatic Answer mode, it also 240 generates a SIP 183 provisional response with a P-Answer-State header 241 field with a parameter of "Unconfirmed" to signal to upstream PTT 242 Servers that they can buffer the caller's media. 244 A PTT Server that wishes to buffer the caller's media, upon seeing 245 the provisional response with a P-Answer-State header field with a 246 parameter of "Unconfirmed" absorbs it and generates a SIP 200 (OK) 247 response for the caller's SIP UA with an appropriate answer. 249 When the called UA generates a SIP 200 (OK) response, the PTT Server 250 that generated the provisional response with a P-Answer-State header 251 field with a parameter "Unconfirmed" adds to the SIP 200 (OK) 252 response a P-Answer-State header field with a parameter of 253 "Confirmed". The SIP 200 (OK) response is absorbed by the PTT Server 254 that is buffering the caller's media, as it has already generated a 255 SIP 200 (OK) response. The buffering PTT Server then starts playing 256 out the buffered media. 258 6. The P-Answer-State Header 260 The purpose of the P-Answer-State header field is to provide an 261 indication from a PTT Server acting as a SIP proxy or back-to-back UA 262 that is has information that hints that the terminating UA identified 263 in the Request-URI of the request will likely answer automatically. 264 Thus enabling the PTT Server to provide an "Unconfirmed Indication" 265 back towards the inviting SIP UA permitting it to transmit media 266 prior to receiving a final response from the final destination of the 267 SIP INVITE request. If a provisional response contains the P-Answer- 268 State header field with the value "Unconfirmed" and does not contain 269 an answer then a receiving PTT Server can send a SIP 200 (OK) 270 response containing an answer and a P-Answer-State header field with 271 the value "Unconfirmed" if the PTT Server is willing to perform media 272 buffering. If the response containing the P-Answer-State header 273 field with the value "Unconfirmed" also contains an answer the PTT 274 Server that included the P-Answer-State header field and answer in 275 the response is also indicating that it is willing to buffer the 276 media until a final "Confirmed Indication" is received. 278 The P-Answer-State header field can be included in a provisional or 279 final response to a SIP INVITE request or in the sipfrag of a SIP 280 NOTIFY request sent as a result of a SIP REFER request to send a SIP 281 INVITE request. If the P-Answer-State header field with value 282 "Unconfirmed" is included in a provisional response that contains an 283 answer the PTT Server is leaving the decision where to do buffering 284 to other PTT Servers upstream and will forward upstream a "Confirmed 285 indication" in a SIP 200 (OK) response when the final response is 286 received from the destination UA. 288 NOTE It is not intended that multiple PTT servers perform buffering 289 serially. If a PTT server includes an answer along with P-Answer- 290 State header field with the value "Unconfirmed" in a provisional 291 response then a receiving PTT Server can determine whether it buffers 292 the media or whether to forward the media and allow the downstrean 293 PTT Server that sent the "Unconfirmed Indication" to buffer the 294 media. It is intended that if a PTT Server buffers media it does so 295 until a final "Confirmed Indication" is received and therefore serial 296 buffering by multiple PTT Servers does not take place 298 The P-Answer-State header is only included in a provisional response 299 when the node that sends the response has knowledge that there is a 300 PTT Server that acts as a B2BUA that understands this extension in 301 the signaling path between itself and the originating UAC that will 302 only pass the header field on in either a SIP 200 (OK) response or in 303 the sipfrag as defined in [4] of a SIP NOTIFY request as defined in 304 [5] sent as a result of a SIP REFER request as defined in [6]. Such 305 a situation only occurs with specific network topologies which is 306 another reason why use of this header field is not relevant to the 307 general internet. The originating UAC will only receive the 308 P-Answer-state header field in a SIP 200 (OK) response or in the 309 sipfrag of a SIP NOTIFY request. 311 Provisional responses containing the P-Answer-State header field can 312 be sent reliably using the mechanism defined in [13] but this is not 313 required. This is a performance optimization and the impact of a 314 provisional response sent unreliably failing to arrive is simply that 315 buffering does not take place. However, if the provisional responses 316 are sent reliably and the provisional response fails to arrive the 317 time taken for the provisional response sender to timeout on the 318 receipt of a SIP PRACK request is likely to be such that by the time 319 the provisional response has been resent the "Confirmed Response" 320 could have already been received. Because when provisional responses 321 that contain an answer are sent reliably, the 200 (OK) response for 322 the SIP INVITE request cannot be sent before the SIP PRACK request is 323 received, sending provisional responses reliably could potentially 324 delay the sending of the "Confirmed Response". 326 6.1. Requirements 328 The OMA PoC service has initial setup performance requirements that 329 can be met by a PTT Server acting as a B2BUA spooling media from the 330 inviting PoC subscriber until one or more invited PoC subscribers 331 have accepted the session. The specific requirements are 333 REQ-1: An intermediate server MAY spool media from the inviting SIP 334 UA until one or more invited PoC SIP UAs has accepted the 335 invitation. 337 REQ-2: An intermediate server that is capable of spooling media MAY 338 accept a SIP INVITE request from an inviting SIP UAC even if no 339 invited SIP UAS has accepted the SIP INVITE request if it has a 340 hint that the invited SIP UAC is likely to accept the request 341 without requiring user intervention. 343 REQ-3: An intermediate server or proxy that is incapable of spooling 344 media or does not wish to, but has a hint that the invited SIP UAC 345 is likely to automatically accept the session invitation MUST be 346 able to indicate back to another intermediate server that can 347 spool media that it has some hint that the invited UAC is likely 348 to automatically accept the session invitation. 350 REQ-4: An intermediate server that is willing to spool media from 351 the inviting SIP UA until one or more invited SIP UAs have 352 accepted the SIP INVITE request SHOULD indicate that it is 353 spooling media to the inviting SIP UAC. 355 6.2. Alternatives Considered 357 In order to meet REQ-3, a PTT Server needs to receive an indication 358 back that the invited SIP UA is likely to accept the SIP INVITE 359 request without requiring user intervention. In this case, the PTT 360 Server that has a hint that the invited SIP UAC is likely to accept 361 the request can include an answer state indication in the SIP 183 362 (Session Progress) response or SIP 200 (OK) response. 364 A number of alternatives were considered for the PTT Server to inform 365 another PTT Server or the inviting SIP UAC of the invited PoC SIP UAs 366 answer mode settings. 368 One proposal was to create a unique reason-phrase in the SIP 183 369 response and SIP 200 (OK) response. This was rejected because the 370 reason phrases are normally intended for human readers and not meant 371 to be parsed by servers for special syntactic and semantic meaning. 373 Another proposal was to use a Reason header [14] in the SIP 183 374 response and SIP 200 (OK) response. This was rejected because this 375 would be inconsistent with the intended use of the reason header and 376 its usage is not defined for these response codes and would have 377 required creating and registering a new protocol identifier. 379 Another proposal was to use a feature-tag in the returned Contact 380 header as defined in [15]. This was rejected because it was not a 381 different feature, but is an attribute of the session and can be 382 applied to many different features. 384 Another proposal was to use a new SDP attribute. The choice of an 385 SDP parameter was rejected because the answer state applies to the 386 session and not to a media stream. 388 The P-Answer-State header was chosen to give additional information 389 about the state of the SIP session progress and acceptance. Even 390 though the UAC sees that its offer has been answered and accepted, 391 the header lets the UAC know whether the invited PoC subscriber has 392 accepted the SIP INVITE request or just an intermediary has done the 393 acceptance. 395 6.3. Applicability Statement for the P-Answer-State Header 397 The P-Answer-State header is applicable in the following 398 circumstances: 400 o In networks where there are UAs that engage in half-duplex 401 communication where there is not the possibility for the invited 402 user to verbally acknowledge the answering of the session as is 403 normal in full duplex communication; 405 o Where the invited UA can automatically accept the session 406 without user intervention; 408 o The network also contains intermediate network SIP servers that 409 are trusted; 411 o The intermediate network SIP servers have knowledge of the 412 current answer mode setting of the terminating UAS; and, 414 o The intermediate network SIP servers have knowledge of the media 415 types and codecs likely to be accepted by the terminating UAS; 416 and, 418 o The intermediate network SIP servers can provide buffering of 419 the media in order to reduce the time for the inviting user to 420 send media. 422 o The intermediate network SIP servers assume knowledge of the 423 network topology and the existence of similar intermediate network 424 SIP servers in the signaling path. 426 Such configurations are generally not applicable to the internet as a 427 whole where such trust relationships do not exist. 429 In addition security issues have only been considered for networks 430 which are trusted and use hop by hop security mechanisms with 431 transitive trust and security issues with usage of this mechanism in 432 the general internet have not been evaluated. 434 6.4. Usage of the P-Answer-State Header 436 A UAS B2BUA or proxy MAY include a P-Answer-State header field in any 437 SIP 18x or 2xx response that does not contain an offer, sent in 438 response to an offer contained in a SIP INVITE request as specified 439 in [7]. Typically the P-Answer-State header field is included in 440 either a SIP 183 Session Progress or a SIP 200 (OK) response. A UA 441 that receives a SIP REFER request to send a SIP INVITE request MAY 442 also include a P-Answer-State header field in the sipfrag of a 443 response included in a SIP NOTIFY request it sends as a result of the 444 implicit subscription created by the SIP REFER request. 446 When the P-Answer-State header field contains the parameter 447 "Unconfirmed" the UAC or proxy is indicating that it has information 448 that hints that the final destination UAS for the SIP INVITE request 449 is likely to automatically accept the session but that this is 450 unconfirmed and it is possible that the final destination UAS will 451 first alert the user and require manual acceptance of the session or 452 not accept the session request. When the P-Answer-State header field 453 contains the parameter "Confirmed" the UAC or proxy is indicating 454 that the destination UAS has accepted the session and is ready to 455 receive media. The parameter value of "Confirmed" has the usual 456 semantics of a SIP 200 (OK) response containing an answer and is 457 included for completeness. A parameter value of "Confirmed" is only 458 included in a SIP 200 (OK) response or in the sipfrag of a 200 (OK) 459 contained in the body of a SIP NOTIFY request. 461 A received SIP 18x response without a P-Answer-State header field 462 SHOULD NOT be treated as an "Unconfirmed Response". A SIP 18x 463 response containing a P-Answer-State header field containing the 464 parameter "Confirmed" MUST NOT be treated as a "Confirmed Response" 465 because this in an invalid condition. 467 A SIP 200 (OK) response without a P-Answer-State Header field MUST be 468 treated as a "Confirmed Response". 470 6.4.1. Procedures at the UA (Terminal) 472 A UAC (terminal) that receives an "Unconfirmed Response" containing 473 an answer MAY send media as specified in [7], however there is no 474 guarantee that the media will be received by the final recipient. 476 How a UAC confirms whether the media was or was not received by the 477 final destination when it has received a SIP 2xx response containing 478 an "Unconfirmed Indication" is application specific and outside of 479 the scope of this document. If the application is a conference then 480 the mechanism specified in [7] could be used to determine that the 481 invited user joined. Alternatively a SIP BYE request could be 482 received or the media could be placed on hold if the final 483 destination UAS does not accept the session. 485 A UAC (terminal) that receives in response to a SIP REFER request, a 486 SIP NOTIFY request containing an "Unconfirmed Response" in a sipfrag 487 in the body of the SIP NOTIFY request related to a dialog for which 488 there has been a successful offer-answer exchange according to [5] 489 MAY send media, however there is no guarantee that the media will be 490 received by the final recipient that was indicated in the Refer-To 491 header in the original SIP REFER request. The dialog could be 492 related either because the SIP REFER request was sent on the same 493 dialog or because the SIP REFER request contained a Target-Dialog 494 header as defined in [16] that identified the dialog. 496 A UAC (terminal) that receives an "Unconfirmed Response" that does 497 not contain an answer MAY buffer media until it receives another 498 "Unconfirmed Response" containing an answer or a "Confirmed 499 Response". 501 There are no P-Answer-State procedures for a terminal acting in the 502 UAS role. 504 6.4.2. Procedures at the UA (PTT Server) 506 A PTT Server that receives a SIP INVITE request at the UAS part of 507 its back-to-back UA MAY include in any SIP 18x or 2xx response that 508 does not contain an offer, a P-Answer-State header field with the 509 parameter "Unconfirmed" in the response if it has not yet received a 510 "Confirmed Response" from the final destination UA and it has 511 information that hints that that the final destination UA for the SIP 512 INVITE request is likely to automatically accept the session. 514 A PTT Server that receives a SIP 18x response to a SIP INVITE request 515 containing a P-Answer-State header field with the parameter 516 "Unconfirmed" at the UAC part of its back-to-back UA MAY include the 517 P-Answer-State header field with the parameter "Unconfirmed" in a SIP 518 2xx response the UAS part of its back-to-back UA sends as a result of 519 receiving that response. Otherwise a PTT Server that receives a SIP 520 18x or 2xx response to a SIP INVITE request containing a P-Answer- 521 State header field at the UAC part of its back-to-back UA SHOULD 522 include the P-Answer-State header field unmodified in the SIP 18x or 523 2xx response the UAS part of its back-to-back UA sends as a result of 524 receiving that response. If the response sent by the UAS part of its 525 back-to-back UA is a SIP 18x response then the P-Answer-State header 526 field included in the response MUST contain a parameter of 527 "Unconfirmed". 529 The UAS part of the back-to-back UA of a PTT Server MAY include an 530 answer in the "Unconfirmed Response" it sends even if the 531 "Unconfirmed Response" received by the UAC part of the back-to-back 532 UA did not contain an answer. 534 If a PTT Server that receives at the UAC part of its back-to-back UA 535 a "Confirmed Response" then the UAS part of its back-to-back UA MAY 536 include in the forwarded response a P-Answer-State header field with 537 the parameter "Confirmed". If the UAS part of its back-to-back UA 538 previously sent an "Unconfirmed Response" as part of this dialog the 539 UAS part of its back-to-back UA SHOULD include in the forwarded 540 "Confirmed Response" a P-Answer-State header field with the parameter 541 "Confirmed". 543 If the UAS part of the back-to-back UA of a PTT Server, includes an 544 answer in a response along with a P-Answer-State header field with 545 the parameter "Unconfirmed" then the UAS part of its back-to-back UA 546 needs to be ready to receive media as specified in [7] and MAY buffer 547 any media it receives until it receives a "Confirmed Response" from 548 the final destination UA or until its buffer is full. 550 A UAS part of the back-to-back UA of a PTT Server that receives a SIP 551 REFER request to send a SIP INVITE request to another UA as specified 552 in [6], MAY generate a sipfrag of a SIP 200 (OK) response containing 553 a P-Answer-State header field with the parameter "Unconfirmed" prior 554 to the UAC part of its back-to-back UA receiving a response to the 555 SIP INVITE request, if it has information that hints that the final 556 destination UA for the SIP INVITE request is likely to automatically 557 accept the session. 559 If the UAC part of a back-to-back UA of a PTT Server sent a SIP 560 INVITE request as a result of receiving a SIP REFER Request, receives 561 a SIP 18x or 2xx response containing a P-Answer-State header field at 562 the UAC part of its back-to-back UA, then the UAS part of its back- 563 to-back UA SHOULD include the P-Answer-State header field and its 564 parameters from that response unmodified in the sipfrag of the 565 response contained in a SIP NOTIFY request that the UAS part of its 566 back-to-back UA sends in response to the SIP REFER request. If the 567 sipfrag of the response sent in the SIP NOTIFY request is a SIP 18x 568 response then the P-Answer-State header field included in the sipfrag 569 of the response MUST contain a parameter of "Unconfirmed". If the 570 UAC part of its back-to-back UA receives a "Confirmed Response" that 571 does not contain a P-Answer-State header field then the UAS part of 572 its back-to-back UA MAY include a P-Answer-State header field with 573 the parameter "Confirmed" in the sipfrag of the response contained in 574 a SIP NOTIFY request sent in response to the SIP REFER request. 576 A PTT Server that's UAS part of its back-to-back UA previously sent a 577 SIP NOTIFY request containing a P-Answer-State header field with the 578 parameter "Unconfirmed" in the sipfrag of a response included in the 579 SIP NOTIFY request, that subsequently receives at the UAC part of its 580 back-to-back UA a "Confirmed Response" to the SIP INVITE request sent 581 as a result of the SIP REFER request SHOULD include a P-Answer-State 582 header field with the parameter "Confirmed" in the sipfrag of the 583 response included in the subsequent SIP NOTIFY request that the UAS 584 part of its back-to-back UA sends as a result of receiving the 585 "Confirmed Response". 587 If the SIP REFER request related to an existing dialog established by 588 a SIP INVITE request for which there has been a successful offer- 589 answer exchange the UAS part of its back-to-back UA MUST be ready to 590 receive media as specified in [7] and MAY buffer any media it 591 receives until the UAC part of its back-to-back UA receives a 592 "Confirmed Response" from the final destination UA or until its 593 buffer is full. The dialog could be related either because the SIP 594 REFER request was sent on the same dialog or because the SIP REFER 595 request contained a Target-Dialog header as defined in [16] that 596 identified the dialog. 598 A PTT Server that buffers media SHOULD be prepared for the 599 possibility of not receiving a "Confirmed Response" and SHOULD 600 release the session if a "Confirmed Response" is not received before 601 the buffer overflows. 603 6.4.3. Procedures at the Proxy Server 605 SIP proxy servers do not need to understand the semantics of the 606 P-Answer-State header field. As part of the regular SIP rules for 607 unknown headers, a proxy will forward unknown headers. 609 A PTT Server that acts as a proxy MAY include a P-Answer-State header 610 field with the parameter "Unconfirmed" in a SIP 18x response that it 611 originates compliant with [2] if it has information that hints that 612 that the final destination UA for the SIP INVITE request is likely to 613 automatically accept the session. 615 A PTT Server that acts as a proxy MAY add a P-Answer-State header 616 field with the parameter "Confirmed" to a "Confirmed Response". 618 7. Formal Syntax 620 The mechanisms specified in this document is described in both prose 621 and an augmented Backus-Naur Form (BNF) defined in [8]. Further, 622 several BNF definitions are inherited from SIP and are not repeated 623 here. Implementers need to be familiar with the notation and 624 contents of SIP [2] and [8] to understand this document. 626 7.1. P-Answer-State Header Syntax 628 The syntax of the P-Answer-State header is described as follows: 630 P-Answer-State = "P-Answer-State" HCOLON answer-type 631 *(SEMI generic-param) 632 answer-type = "Confirmed" / "Unconfirmed" / token 634 7.2. Table of the New Header 636 Table 1 provides the additional table entries for the P-Answer-State 637 header needed to extend Table 2 in SIP [2], section 7.1 of the SIP- 638 specific event notification [5] tables 1 and 2 in the SIP INFO method 639 [17], tables 1 and 2 in Reliability of provisional responses in SIP 640 [13], tables 1 and 2 in the SIP UPDATE method [18], tables 1 and 2 in 641 the SIP extension for Instant Messaging [19], table 1 in the SIP 642 REFER method [6], and table 2 in the SIP PUBLISH method [20]: 644 Header field where proxy ACK BYE CAN INV OPT REG SUB 645 _______________________________________________________________ 646 P-Answer-State 18x,2xx ar - - - o - - - 648 Header field NOT PRA INF UPD MSG REF PUB 649 _______________________________________________________________ 650 P-Answer-State R - - - - - - - 652 Figure 1 654 8. Example Usage Session Flows 656 For simplicity some details such as intermediate proxies and SIP 100 657 Trying responses are not shown in the following example flows. 659 8.1. Pre-arranged Group Call Using On-demand Session 661 The following flow shows Alice making a Pre-arranged Group Call using 662 a Conference URI which has Bob on the member list. The session 663 initiation uses the On-demand Session establishment mechanism where a 664 SIP INVITE request containing an SDP offer is sent by Alices's 665 terminal when Alice pushes her push to talk button. 667 In this example Alice's PTT Server acts a Call Stateful SIP Proxy and 668 Bob's PTT Server which is aware that the current Answer Mode setting 669 of Bob's terminal is set to Auto Answer acts as a B2BUA. 671 For simplicity the invitations by the Conference Focus to the other 672 members of the group are not shown in this example. 674 Alice's Alices's Conference Bob's Bob's 675 Terminal PTT Server focus PTT Server Terminal 676 | | | | | 677 |--(1)INVITE-->| | | | 678 | |--(2)INVITE-->| | | 679 | | |--(3)INVITE->| | 680 | | | |--(4)INVITE-->| 681 | | |<--(5)183----| | 682 | |<---(6)200----| | | 683 |<---(7)200----| | | | 684 |----(8)ACK--->| | | | 685 | |---(9)ACK---->| | | 686 | | | | | 687 |=====Early Media Session====>| | | 688 | | MEDIA | | 689 | | BUFFERING | | 690 | | | |<---(10)200---| 691 | | | |---(11)ACK--->| 692 | | |<--(12)200---| | 693 | | |--(13)ACK--->| | 694 | | | | | 695 | | |========Media Session======>| 696 | | | | | 697 | | | | | 699 Figure 2 701 1 INVITE Alice -> Alices's PTT Server 703 INVITE sip:FriendsOfAlice@example.org SIP/2.0 704 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 705 Max-Forwards: 70 706 To: "Alice's Friends" 707 From: "Alice" ;tag=1928301774 708 Call-ID: a84b4c76e66710 709 CSeq: 314159 INVITE 710 Contact: 711 Content-Type: application/sdp 712 Content-Length: 142 714 (SDP not shown) 716 2 INVITE Alice's PTT Server -> Conference Focus 718 INVITE sip:FriendsOfAlice@example.org SIP/2.0 719 Via: SIP/2.0/UDP 720 AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 721 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 722 Record-Route: 723 Max-Forwards: 69 724 To: "Alice's Friends" 725 From: "Alice" ;tag=1928301774 726 Call-ID: a84b4c76e66710 727 CSeq: 314159 INVITE 728 Contact: 729 Content-Type: application/sdp 730 Content-Length: 142 732 (SDP not shown) 734 The Conference Focus explodes the Conference URI and Invites Bob 736 3 INVITE Conference Focus -> Bob's PTT Server 738 INVITE sip:bob@example.com SIP/2.0 739 Via: SIP/2.0/UDP 740 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 741 Max-Forwards: 70 742 To: "Bob" 743 From: "Alice's Friends" 744 ;tag=2178309898 745 Call-ID: e60a4c784b6716 746 CSeq: 301166605 INVITE 747 Contact: 748 Content-Type: application/sdp 749 Content-Length: 142 751 (SDP not shown) 753 4 INVITE Bob's PTT Server -> Bob 754 INVITE sip:bob@example.com SIP/2.0 755 Via: SIP/2.0/UDP 756 BobsPTTServer.example.com;branch=z9hG4bKa27bc93 757 Max-Forwards: 70 758 To: "Bob" 759 From: "Alice's Friends" 760 ;tag=781299330 761 Call-ID: 6eb4c66a847710 762 CSeq: 478209 INVITE 763 Contact: 764 Content-Type: application/sdp 765 Content-Length: 142 767 (SDP not shown) 769 5 183 (Session Progress) Bob's PTT Server -> Conference Focus 771 SIP/2.0 183 Session Progress 772 Via: SIP/2.0/UDP 773 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 774 To: "Bob" ;tag=a6c85cf 775 From: "Alice's Friends" 776 ;tag=2178309898 777 Call-ID: e60a4c784b6716 778 Contact: 779 CSeq: 301166605 INVITE 780 P-Answer-State: Unconfirmed 781 Content-Length: 0 783 6 200 (OK) Conference Focus -> Alice's PTT Server 785 SIP/2.0 200 OK 786 Via: SIP/2.0/UDP 787 AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 788 Via: SIP/2.0/UDP 789 pc33.example.org;branch=z9hG4bKnashds8 790 Record-Route: 791 To: "Alice's Friends" 792 ;tag=c70ef99 793 From: "Alice" 794 ;tag=1928301774 795 Call-ID: a84b4c76e66710 796 CSeq: 314159 INVITE 797 Contact: 798 P-Answer-State: Unconfirmed 799 Content-Type: application/sdp 800 Content-Length: 131 801 (SDP not shown) 803 7 200 (OK) Alice's PTT Server -> Alice 805 SIP/2.0 200 OK 806 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 807 Record-Route: 808 To: "Alice's Friends" ;tag=c70ef99 809 From: "Alice" ;tag=1928301774 810 Call-ID: a84b4c76e66710 811 CSeq: 314159 INVITE 812 Contact: 813 P-Answer-State: Unconfirmed 814 Content-Type: application/sdp 815 Content-Length: 131 817 (SDP not shown) 819 8 ACK Alice -> Alice's PTT Server 821 ACK sip:AlicesConferenceFocus.example.org SIP/2.0 822 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 823 Route: 824 Max-Forwards: 70 825 To: "Alice's Friends" ;tag=c70ef99 826 From: "Alice" ;tag=1928301774 827 Call-ID: a84b4c76e66710 828 CSeq: 314159 ACK 829 Content-Length: 0 831 9 ACK Alice's PTT Server -> Conference Focus 833 ACK sip:AlicesConferenceFocus.example.org SIP/2.0 834 Via: SIP/2.0/UDP 835 AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 836 Via: SIP/2.0/UDP 837 pc33.example.org;branch=z9hG4bKnashds9 838 Max-Forwards: 69 839 To: "Alice's Friends" ;tag=c70ef99 840 From: "Alice" ;tag=1928301774 841 Call-ID: a84b4c76e66710 842 CSeq: 314159 ACK 843 Content-Length: 0 845 The early half duplex media session between Alice and the Conference 846 Focus is now established and the Conference Focus buffers the media 847 it receives from Alice. 849 10 200 (OK) Bob -> Bob's PTT Server 851 SIP/2.0 200 OK 852 Via: SIP/2.0/UDP 853 BobsPTTServer.example.com;branch=z9hG4bKa27bc93 854 To: "Bob" ;tag=d28119a 855 From: "Alice's Friends" 856 ;tag=781299330 857 Call-ID: 6eb4c66a847710 858 CSeq: 478209 INVITE 859 Contact: 860 Content-Type: application/sdp 861 Content-Length: 131 863 (SDP not shown) 865 11 ACK Bob's PTT Server -> Bob 867 ACK sip:bob@192.0.2.4 SIP/2.0 868 Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93 869 Max-Forwards: 70 870 To: "Bob" ;tag=d28119a 871 From: "Alice's Friends" 872 ;tag=781299330 873 Call-ID: 6eb4c66a847710 874 CSeq: 478209 ACK 875 Content-Length: 0 877 12 200 (OK) Bob's PTT Server -> Conference Focus 879 SIP/2.0 200 OK 880 Via: SIP/2.0/UDP 881 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 882 To: "Bob" ;tag=a6670811 883 From: "Alice's Friends" 884 ;tag=2178309898 885 Call-ID: e60a4c784b6716 886 Contact: 887 CSeq: 301166605 INVITE 888 P-Answer-State: Confirmed 889 Content-Type: application/sdp 890 Content-Length: 131 892 (SDP not shown) 894 13 ACK Conference Focus -> Bob's PTT Server 896 ACK sip:BobsPTTServer.example.com SIP/2.0 897 Via: SIP/2.0/UDP 898 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 899 Max-Forwards: 70 900 To: "Bob" 901 ;tag=a6670811 902 From: "Alice's Friends" 903 ;tag=2178309898 904 Call-ID: e60a4c784b6716 905 CSeq: 301166605 ACK 906 Content-Length: 0 908 The media session between Alice and Bob is now established and the 909 Conference Focus forwards the buffered media to Bob. 911 8.2. 1-1 Call Using Pre-established Session 913 The following flow shows Alice making a 1-1 Call to Bob using a pre- 914 established session. A pre-established session is where a dialog is 915 established with Alices's PTT Server using a SIP INVITE SDP offer 916 answer exchange to pre-negotiate the codecs and other media 917 Parameters to be used for media sessions ahead of Alice initiating a 918 Communication. When Alice initiates a communication to Bob a SIP 919 REFER request is used to request Alice's PTT Server to send a SIP 920 INVITE request to Bob. In this example Bob's Terminal does not use 921 the Pre-established Session mechanism. 923 In this example Alice's PTT Server acts a B2BUA and also performs the 924 Conference Focus function. Bob's PTT Server which is aware that the 925 current Answer Mode setting of Bob's terminal is set to Auto Answer 926 acts as a B2BUA. 928 Alice's Alice's Bob's Bob's 929 Terminal PTT Server / PTT Server Terminal 930 Conference Focus 931 | | | | 932 |-----(1)INVITE-- ----->| | | 933 |<-----(2)200-----------| | | 934 |-------(3)ACK--------->| | | 935 | | | | 936 | | | | 937 | | | | 938 |----(4)REFER---------->| | | 939 |<-----(5)202-----------| | | 940 | |----(6)INVITE---->| | 941 | | |--(7)INVITE---->| 942 | | | | 943 | |<----(8)183-------| | 944 |<---(9)NOTIFY----------| | | 945 |-----(10)200---------->| | | 946 | | | | 947 |=Early Media Session==>| | | 948 | MEDIA | | 949 | BUFFERING | | 950 | | |<---(11)200-----| 951 | | |---(12)ACK----->| 952 | |<----(13)200------| | 953 | |-----(14)ACK----->| | 954 | |===========Media Session==========>| 955 | | | | 956 |<---(15)NOTIFY---------| | | 957 |-----(16)200---------->| | | 958 | | | | 960 Figure 3 962 1 INVITE Alice -> Alices's PTT Server 964 INVITE sip:AlicesConferenceFactoryURI.example.org SIP/2.0 965 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 966 Max-Forwards: 70 967 To: 968 From: "Alice" ;tag=1928301774 969 Call-ID: a84b4c76e66710 970 CSeq: 314159 INVITE 971 Contact: 972 Content-Type: application/sdp 973 Content-Length: 142 975 (SDP not shown) 976 2 200 (OK) Alice's PTT Server -> Alice 978 SIP/2.0 200 OK 979 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 980 To: ;tag=c70ef99 981 From: "Alice" ;tag=1928301774 982 Call-ID: a84b4c76e66710 983 CSeq: 314159 INVITE 984 Contact: 986 Content-Type: application/sdp 987 Content-Length: 131 989 (SDP not shown) 991 3 ACK Alice -> Alice's PTT Server 993 ACK sip:AlicesPre-establishedSession@AlicesPTTServer.example.org 994 SIP/2.0 995 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 996 Max-Forwards: 70 997 To: ;tag=c70ef99 998 From: "Alice" ;tag=1928301774 999 Call-ID: a84b4c76e66710 1000 CSeq: 314159 ACK 1001 Content-Length: 0 1003 Alices's terminal has established a Pre-established Session with 1004 Alice's PTT Server. All the media parameters are pre-negotiated for 1005 use at communication time. 1007 Alice initiates a Communication to Bob 1009 4 REFER Alice -> Alices's PTT Server 1011 REFER sip:AlicesPre-establishedSession@AlicesPTTServer.example.org 1012 SIP/2.0 1013 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 1014 Max-Forwards: 70 1015 To: ;tag=c70ef99 1016 From: "Alice" ;tag=1928301774 1017 Call-ID: a84b4c76e66710 1018 CSeq: 314160 REFER 1019 Refer-To: "Bob" 1020 Contact: 1022 5 202 (ACCEPTED) Alice's PTT Server -> Alice 1023 SIP/2.0 202 ACCEPTED 1024 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 1025 To: ;tag=c70ef99 1026 From: "Alice" ;tag=1928301774 1027 Call-ID: a84b4c76e66710 1028 CSeq: 314160 REFER 1029 Contact: 1032 6 INVITE Conference Focus -> Bob's PTT Server 1034 INVITE sip:bob@example.com SIP/2.0 1035 Via: SIP/2.0/UDP 1036 AlicesConferenceFocus.example.org;branch=z9hG4bk4721d8 1037 Max-Forwards: 70 1038 To: "Bob" 1039 From: "Alice" ;tag=2178309898 1040 Call-ID: e60a4c784b6716 1041 CSeq: 301166605 INVITE 1042 Contact: 1043 Content-Type: application/sdp 1044 Content-Length: 142 1046 (SDP not shown) 1048 7 INVITE Bob's PTT Server -> Bob 1050 INVITE sip:bob@example.com SIP/2.0 1051 Via: SIP/2.0/UDP 1052 BobsPTTServer.example.com;branch=z9hG4bKa27bc93 1053 Max-Forwards: 70 1054 To: "Bob" 1055 From: "Alice" ;tag=781299330 1056 Call-ID: 6eb4c66a847710 1057 CSeq: 478209 INVITE 1058 Contact: 1059 Content-Type: application/sdp 1060 Content-Length: 142 1062 (SDP not shown) 1064 8 183 (Session Progress) Bob's PTT Server -> Conference Focus 1066 SIP/2.0 183 Session Progress 1067 Via: SIP/2.0/UDP 1068 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 1069 To: "Bob" ;tag=a6c85cf 1070 From: "Alice" ;tag=2178309898 1071 Call-ID: e60a4c784b6716 1072 Contact: 1073 CSeq: 301166605 INVITE 1074 P-Answer-State: Unconfirmed 1075 Content-Length: 0 1077 9 NOTIFY Alices's PTT Server -> Alice 1079 NOTIFY sip:alice@pc33.example.org SIP/2.0 1080 Via: SIP/2.0/UDP 1081 AlicesPre-establishedSession@AlicesPTTServer.example.org; 1082 branch=z9hG4bKnashds8 1083 Max-Forwards: 70 1084 To: ;tag=c70ef99 1085 From: "Alice" ;tag=1928301774 1086 Call-ID: a84b4c76e66710 1087 CSeq: 314161 NOTIFY 1088 Contact: 1089 1090 Event: refer 1091 Subscription-State: Active;Expires=60 1092 Content-Type: message/sipfrag;version=2.0 1093 Content-Length: 99 1095 SIP/2.0 183 Session Progress 1096 To: "Bob" ;tag=d28119a 1097 P-Answer-State: Unconfirmed 1099 10 200 (OK) Alice -> Alice's PTT Server 1101 SIP/2.0 200 OK 1102 Via: SIP/2.0/UDP 1103 AlicesPre-establishedSession@AlicesPTTServer.example.org; 1104 branch=z9hG4bKnashds8 1105 To: ;tag=c70ef99 1106 From: "Alice" ;tag=1928301774 1107 Call-ID: a84b4c76e66710 1108 CSeq: 314161 NOTIFY 1110 The early half duplex media session between Alice and the Conference 1111 Focus is now established and the Conference Focus buffers the media 1112 it receives from Alice. 1114 11 200 (OK) Bob -> Bob's PTT Server 1116 SIP/2.0 200 OK 1117 Via: SIP/2.0/UDP 1118 BobsPTTServer.example.com;branch=z9hG4bK927bc93 1120 To: "Bob" ;tag=d28119a 1121 From: "Alice's Friends" 1122 ;tag=781299330 1123 Call-ID: 6eb4c66a847710 1124 CSeq: 478209 INVITE 1125 Contact: 1126 Content-Type: application/sdp 1127 Content-Length: 131 1129 (SDP not shown) 1131 12 ACK Bob's PTT Server -> Bob 1133 ACK sip:bob@192.0.2.4 SIP/2.0 1134 Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93 1135 Max-Forwards: 70 1136 To: "Bob" ;tag=d28119a 1137 From: "Alice" ;tag=781299330 1138 Call-ID: 6eb4c66a847710 1139 CSeq: 478209 ACK 1140 Content-Length: 0 1142 F13 200 (OK) Bob's PTT Server -> Conference Focus 1144 SIP/2.0 200 OK 1145 Via: SIP/2.0/UDP 1146 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 1147 To: "Bob" ;tag=a6670811 1148 From: "Alice's Friends" 1149 ;tag=2178309898 1150 Call-ID: e60a4c784b6716 1151 Contact: 1152 CSeq: 301166605 INVITE 1153 P-Answer-State: Confirmed 1154 Content-Type: application/sdp 1155 Content-Length: 131 1157 (SDP not shown) 1159 14 ACK Conference Focus -> Bob's PTT Server 1161 ACK sip:BobsPTTServer.example.com SIP/2.0 1162 Via: SIP/2.0/UDP 1163 AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 1164 Max-Forwards: 70 1165 To: "Bob" ;tag=a6670811 1166 From: "Alice" ;tag=1928301774 1167 Call-ID: e60a4c784b6716 1168 CSeq: 301166605 ACK 1169 Content-Length: 0 1171 The media session between Alice and Bob is now established and the 1172 Conference Focus forwards the buffered media to Bob. 1174 15 NOTIFY Alices's PTT Server -> Alice 1176 NOTIFY sip:alice@pc33.example.org SIP/2.0 1177 Via: SIP/2.0/UDP 1178 AlicesPre-establishedSession@AlicesPTTServer.example.org; 1179 branch=z9hG4bKnashds8 1180 Max-Forwards: 70 1181 To: ;tag=c70ef99 1182 From: "Alice" ;tag=1928301774 1183 Call-ID: a84b4c76e66710 1184 CSeq: 314162 NOTIFY 1185 Contact: 1187 Event: refer 1188 Subscription-State: Active;Expires=60 1189 Content-Type: message/sipfrag;version=2.0 1190 Content-Length: 83 1192 SIP/2.0 200 OK 1193 To: "Bob" ;tag=d28119a 1194 P-Answer-State: Confirmed 1196 16 200 (OK) Alice -> Alice's PTTServer 1198 SIP/2.0 200 OK 1199 Via: SIP/2.0/UDP 1200 AlicesPre-establishedSession@AlicesPTTServer.example.org; 1201 branch=z9hG4bKnashds8 1202 To: ;tag=c70ef99 1203 From: "Alice" ;tag=1928301774 1204 Call-ID: a84b4c76e66710 1205 CSeq: 314162 NOTIFY 1207 9. Security Considerations 1209 The information returned in the P-Answer-State header is not viewed 1210 as particularly sensitive. Rather, it is informational in nature, 1211 providing an indication to the UAC that delivery of any media sent as 1212 a result of an answer in this response is not guaranteed. An 1213 eavesdropper cannot gain any useful information by obtaining the 1214 contents of this header. 1216 End-to-end protection is not appropriate because the P-Answer-State 1217 header is used and added by proxies and intermediate UAs. As a 1218 result, a "malicious" proxy between the UAs or attackers on the 1219 signaling path could add or remove the header or modify the contents 1220 of the header value. This attack either denies the caller the 1221 knowledge that the callee has yet to be contacted or falsely 1222 indicates that the callee has yet to be contacted when they have 1223 already answered. The falsely indicating that the callee has yet to 1224 be contacted when they have already answered attack could result in 1225 the caller deciding not transmit media because they do not wish to 1226 have their media stored by an intermediary even though in reality the 1227 callee has answered. The denying the callee the additional knowledge 1228 that the callee has yet to be contacted attack does not appear to be 1229 a significant concern since this is the same as the situation when a 1230 B2BUA sends a 200 (OK) before the callee has answered without the use 1231 of this extension. 1233 It is therefore necessary to protect the messages between proxies and 1234 implementation SHOULD use a transport that provides integrity and 1235 confidentially between the signaling hops. The Transport Layer 1236 Security (TLS) [9] based signaling in SIP can be used to provide this 1237 protection. 1239 Security issues have only been considered for networks which are 1240 trusted and use hop by hop security mechanisms with transitive trust 1241 and security issues with usage of this mechanism in the general 1242 internet have not been evaluated. 1244 10. IANA Considerations 1246 10.1. Registration of Header Fields 1248 This document defines a private SIP extension header field (beginning 1249 with the prefix "P-" ) based on the registration procedures defined 1250 in RFC 3427 [21]. 1252 The following rows shall be added to the "Header Fields" section of 1253 the SIP parameter registry: 1255 +----------------+--------------+-----------+ 1256 | Header Name | Compact Form | Reference | 1257 +----------------+--------------+-----------+ 1258 | P-Answer-State | | [RFCXXXX] | 1259 +----------------+--------------+-----------+ 1261 Editor Note: [RFCXXXX] should be replaced with the designation of 1262 this document. 1264 11. Acknowledgements 1266 The authors would like to thank Jon Peterson, Cullen Jennings, Jeroen 1267 van Bemmel, Paul Kyzivat, Dale Worley, Dean Willis, Rohan Mahay, 1268 Christian Schmidt, Mike Hammer, and Miguel Garcia-Martin for their 1269 comments that contributed to the progression of this work. The 1270 authors would also like to thank the OMA POC Working Group members 1271 for their support of this document and in particular Tom Hiller for 1272 presenting the concept of the P-Answer-State header to SIPPING at 1273 IETF#62. 1275 12. References 1277 12.1. Normative References 1279 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1280 Levels", BCP 14, RFC 2119, March 1997. 1282 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1283 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1284 Session Initiation Protocol", RFC 3261, June 2002. 1286 [3] OMA, "Push to talk over Cellular - Architecture", OMA-AD- 1287 PoC V1_0_1, 20061128 A, November 2006. 1289 [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1290 November 2002. 1292 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1293 Notification", RFC 3265, June 2002. 1295 [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1296 Method", RFC 3515, April 2003. 1298 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1299 Session Description Protocol (SDP)", RFC 3264, June 2002. 1301 [8] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1302 Specifications: ABNF", RFC 4234, October 2005. 1304 [9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1305 Protocol Version 1.1", RFC 4346, April 2006. 1307 12.2. Informative References 1309 [10] Rosenberg, J., "A Framework for Conferencing with the Session 1310 Initiation Protocol (SIP)", RFC 4353, February 2006. 1312 [11] Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event 1313 Package and Data Format for Various Settings in Support for the 1314 Push-to-Talk over Cellular (PoC) Service", RFC 4354, 1315 January 2006. 1317 [12] Willis, D. and A. Allen, "Requesting Answering Modes for the 1318 Session Initiation Protocol (SIP)", 1319 draft-ietf-sip-answermode-01 (work in progress), May 2006. 1321 [13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1322 Responses in Session Initiation Protocol (SIP)", RFC 3262, 1323 June 2002. 1325 [14] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header 1326 Field for the Session Initiation Protocol (SIP)", RFC 3326, 1327 December 2002. 1329 [15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1330 User Agent Capabilities in the Session Initiation Protocol 1331 (SIP)", RFC 3840, August 2004. 1333 [16] Rosenberg, J., "Request Authorization through Dialog 1334 Identification in the Session Initiation Protocol (SIP)", 1335 RFC 4538, June 2006. 1337 [17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 1339 [18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1340 Method", RFC 3311, October 2002. 1342 [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1343 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1344 Instant Messaging", RFC 3428, December 2002. 1346 [20] Niemi, A., "Session Initiation Protocol (SIP) Extension for 1347 Event State Publication", RFC 3903, October 2004. 1349 [21] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 1350 Rosen, "Change Process for the Session Initiation Protocol 1351 (SIP)", BCP 67, RFC 3427, December 2002. 1353 Authors' Addresses 1355 Andrew Allen (editor) 1356 Research in Motion (RIM) 1357 102 Decker Court, Suite 100 1358 Irving, Texas 75062 1359 USA 1361 Phone: unlisted 1362 Fax: unlisted 1363 Email: aallen@rim.com 1365 Jan Holm 1366 Ericsson 1367 Gotalandsvagen 220 1368 Stockholm 612526 1369 Sweden 1371 Phone: unlisted 1372 Fax: unlisted 1373 Email: Jan.Holm@ericsson.com 1375 Tom Hallin 1376 Motorola 1377 1501 W Shure Drive 1378 Arlington Heights 60004 1379 USA 1381 Phone: unlisted 1382 Fax: unlisted 1383 Email: thallin@motorola.com 1385 Full Copyright Statement 1387 Copyright (C) The IETF Trust (2007). 1389 This document is subject to the rights, licenses and restrictions 1390 contained in BCP 78, and except as set forth therein, the authors 1391 retain all their rights. 1393 This document and the information contained herein are provided on an 1394 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1395 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1396 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1397 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1398 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1399 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1401 Intellectual Property 1403 The IETF takes no position regarding the validity or scope of any 1404 Intellectual Property Rights or other rights that might be claimed to 1405 pertain to the implementation or use of the technology described in 1406 this document or the extent to which any license under such rights 1407 might or might not be available; nor does it represent that it has 1408 made any independent effort to identify any such rights. Information 1409 on the procedures with respect to rights in RFC documents can be 1410 found in BCP 78 and BCP 79. 1412 Copies of IPR disclosures made to the IETF Secretariat and any 1413 assurances of licenses to be made available, or the result of an 1414 attempt made to obtain a general license or permission for the use of 1415 such proprietary rights by implementers or users of this 1416 specification can be obtained from the IETF on-line IPR repository at 1417 http://www.ietf.org/ipr. 1419 The IETF invites any interested party to bring to its attention any 1420 copyrights, patents or patent applications, or other proprietary 1421 rights that may cover technology that may be required to implement 1422 this standard. Please address the information to the IETF at 1423 ietf-ipr@ietf.org. 1425 Acknowledgment 1427 Funding for the RFC Editor function is provided by the IETF 1428 Administrative Support Activity (IASA).