idnits 2.17.1 draft-lavers-sipcore-immersive-capability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 70 == Unused Reference: 'RFC3261' is defined on line 325, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE G. Lavers 3 Internet-Draft P. Jones 4 Intended status: Standards Track G. Salgueiro 5 Expires: September 6, 2012 Cisco Systems 6 March 5, 2012 8 Indicating the Immersive User Agent Capability 9 in the Session Initiation Protocol (SIP) 10 draft-lavers-sipcore-immersive-capability-00 12 Abstract 14 This document defines and registers with IANA the new 'immersive' 15 media feature tag for use with the Session Initiation Protocol (SIP). 16 This media feature tag can be used to route calls to a device that 17 can provide an immersive communication experience, such as a 18 Telepresence system. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 6, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Session Establishment . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 Videoconferencing systems that utilize SIP [1] can be broadly 71 classified as "traditional" videoconferencing systems or 72 "Telepresence" systems. Most SIP implementations today are 73 classified as traditional videoconferencing systems, but there are a 74 growing number of telepresence systems that would benefit in 75 differentiating the two through a media feature tag. 77 The traditional videoconferencing system, which might include any 78 room-based system, desktop videophone, or application running on a 79 computer, tablet, mobile phone, or similar device, typically uses 80 lower-resolution video images and does not make an attempt to provide 81 a real-life, immersive conferencing experience. Some traditional 82 systems do employ high definition (HD) video, but still lack the 83 quality of providing an in-person communication experience. 85 Telepresence systems, on the other hand, are visual conferencing 86 environments that duplicate, as closely as possible, an in-person 87 experience. The objective of such systems is to make the 88 participants in the conference feel as if they are physically 89 together, providing an immersive, realistic experience. 91 This document defines the "immersive" media feature tag for use in 92 the SIP tree, as per Section 12.1 of RFC 3840 [RFC3840]. This 93 feature tag can be utilized by SIP B2BUAs, SIP proxies, or other 94 elements in the SIP network to help ensure the best communication 95 experience for those wishing to establish a telepresence session or 96 other communication session that might be classified as providing an 97 immersive, realistic user experience. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are 106 appropriate when valid exceptions to a general requirement are known 107 to exist or appear to exist, and it is infeasible or impractical to 108 enumerate all of them. However, they should not be interpreted as 109 permitting implementors to fail to implement the general requirement 110 when such failure would result in interoperability failure. 112 3. Motivation 114 The primary motivation for defining an immersive media feature tag is 115 for the transmission of a feature capability that implies a specific 116 "user experience" that is differentiated from classic video. This 117 feature tag can be considered by the various network elements to 118 realize several possible use cases. To name a few: 120 o Admission control decisions: A system could use the media feature 121 tags such as immersive, video, audio, etc. to allow network 122 elements to reserve bandwidth or take measures to ensure the best 123 possible experience. 125 o Selective routing decisions: A proxy or B2BUA could leverage the 126 immersive feature tag to help make routing decisions, including 127 the selection of a specific end system that supports the feature 128 capability or to route a call over specific network segments. 130 4. Examples 132 The following examples omit the message body and various header 133 fields for brevity. 135 4.1. Registration 137 Bob registers with the immersive media feature tag. The message flow 138 is shown in Figure 1: 140 SIP Registrar Bob's 141 Telepresence Endpoint 142 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 143 | | 144 | REGISTER F1 | 145 |<------------------------------| 146 | | 147 | 200 OK F2 | 148 |------------------------------>| 149 | | 151 Figure 1: Immersive Media Feature Tag SIP Registration Example 153 F1 REGISTER Bob -> Registrar 154 REGISTER sip:example.com SIP/2.0 155 Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bK309475a2 156 From: ;tag=a6c85cf 157 To: 158 Call-ID: a84b4c76e66710 159 Max-Forwards: 70 160 CSeq: 116 REGISTER 161 Contact: ;immersive 162 Expires: 3600 164 The registrar responds with a 200 OK: 166 F2 200 OK Registrar -> Bob 168 SIP/2.0 200 OK 169 From: ;tag=a6c85cf 170 To: ;tag=1263390604 171 Contact: ;immersive 172 Expires: 120 173 Call-ID: a84b4c76e66710 174 Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bK309475a2 175 CSeq: 116 REGISTER 176 Expires: 3600 178 4.2. Session Establishment 179 Bob initiates a delayed offer call to Alice indicating that he 180 supports the immersive media feature tag while Alice responds with 181 her support of the immersive media feature tag. The message flow is 182 shown in Figure 2: 184 Bob Alice 185 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 186 | | 187 | INVITE F1 | 188 |------------------------------>| 189 | | 190 | 180 Ringing F2 | 191 |<------------------------------| 192 | | 193 | 200 OK F3 | 194 |<------------------------------| 195 | | 196 | ACK F4 | 197 |------------------------------>| 198 | | 199 | Media F5 | 200 |<=============================>| 201 | | 203 Figure 2: Immersive Media Feature Tag SIP Session Establishment 204 Example 206 F1 INVITE Bob -> Alice 208 INVITE sip:alice@example.com SIP/2.0 209 Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bKnashds8 210 From: "bob" ;tag=a6c85cf 211 To: "alice" 212 Date: Tue, 01 Nov 2011 18:28:52 GMT 213 Call-ID: a84b4c76e66710 214 CSeq: 101 INVITE 215 Contact: ;immersive 216 Max-Forwards: 69 217 Content-Length: 0 219 F2 180 Ringing Alice -> Bob 220 SIP/2.0 180 Ringing 221 Via: SIP/2.0/TCP alice@example.com;branch=z9hG4bKnashds8 222 From: "alice" ;tag=1928301774 223 To: "bob" ;tag=a6c85cf 224 Date: Tue, 01 Nov 2011 18:28:52 GMT 225 Call-ID: a84b4c76e66710 226 CSeq: 101 INVITE 227 Contact: ;immersive 228 Content-Length: 0 230 F3 200 OK Alice -> Bob 232 SIP/2.0 200 OK 233 Via: SIP/2.0/TCP alice@example.com;branch=z9hG4bKnashds8 234 From: "alice" ;tag=1928301774 235 To: "bob" ;tag=a6c85cf 236 Date: Tue, 01 Nov 2011 18:28:52 GMT 237 Call-ID: a84b4c76e66710 238 CSeq: 101 INVITE 239 Contact: ;immersive 240 Content-Type: application/sdp 241 Content-Length: 1963 243 F4 ACK Bob -> Alice 245 ACK sip:aliceexample.com;transport=tcp SIP/2.0 246 Via: SIP/2.0/TCP 10.0.0.2:5060;branch=z9hG4bKnashds9 247 From: "bob" ;tag=a6c85cf 248 To: "alice" ;tag=1928301774 249 Date: Tue, 01 Nov 2011 18:28:52 GMT 250 Call-ID: a84b4c76e66710 251 Max-Forwards: 70 252 CSeq: 101 ACK 253 Contact: ;immersive 254 Content-Type: application/sdp 255 Content-Length: 1452 257 F5 Media transmission Bob <-> Alice 259 Media streams are established between Bob and Alice. 261 5. Security Considerations 263 The security considerations related to the use of media feature tags 264 from Section 11.1 of RFC 3840 [RFC3840] apply. 266 6. IANA Considerations 268 This specification adds a new media feature tag to the SIP Media 269 Feature Tag Registration Tree per the procedures defined in RFC 2506 270 [RFC2506] and RFC 3840 [RFC3840]. 272 Media feature tag name: sip.immersive 274 ASN.1 Identifier: 1.3.6.1.8.4.{PH} 276 Summary of the media feature indicated by this tag: This feature tag 277 indicates that the device provides an immersive audio and/or video 278 communication experience. 280 Values appropriate for use with this feature tag: Boolean. 282 The feature tag is intended primarily for use in the following 283 applications, protocols, services, or negotiation mechanisms: This 284 feature tag is most useful in a communications application for 285 describing the capabilities of a device, such as a Telepresence 286 system. 288 Examples of typical use: Routing a call to a multimedia 289 communication system that can provide an immersive communication 290 experience. 292 Related standards or documents: RFCXXXX 294 Security Considerations: Security considerations for this media 295 feature tag are discussed in Section 5 of this document. 297 [[NOTE TO RFC EDITOR: Please change {PH} above to the correct 298 identifier for this entry in the IANA registry for 299 iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4)]] 301 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 302 this specification, and remove this paragraph on publication.]] 304 7. Acknowledgements 306 Thanks go to the Medianet Session Control group at Cisco for their 307 insightful discussion, advice and feedback that led to the creation 308 of this document. 310 8. References 311 8.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 317 "Indicating User Agent Capabilities in the Session 318 Initiation Protocol (SIP)", RFC 3840, August 2004. 320 8.2. Informative References 322 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 323 Registration Procedure", BCP 31, RFC 2506, March 1999. 325 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 326 A., Peterson, J., Sparks, R., Handley, M., and E. 327 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 328 June 2002. 330 Authors' Addresses 332 Glen Lavers 333 Cisco Systems 334 Mail Stop LKO2/3/ 335 5400 Meadows Road 336 LAKE OSWEGO, OR 97035 337 US 339 Email: glavers@cisco.com 341 Paul E. Jones 342 Cisco Systems 343 7025 Kit Creek Road 344 Research Triangle Park, NC 27709 345 US 347 Email: paulej@packetizer.com 348 Gonzalo Salgueiro 349 Cisco Systems 350 7200-12 Kit Creek Road 351 Research Triangle Park, NC 27709 352 US 354 Email: gsalguei@cisco.com