Indicating the Immersive User Agent Capability in the Session Initiation Protocol (SIP)
draft-lavers-sipcore-immersive-capability-00

Abstract

This document defines and registers with IANA the new 'immersive' media feature tag for use with the Session Initiation Protocol (SIP). This media feature tag can be used to route calls to a device that can provide an immersive communication experience, such as a Telepresence system.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 04, 2012.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Motivation
• 4. Examples
• 4.1. Registration
• 4.2. Session Establishment
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

Videoconferencing systems that utilize SIP [1] can be broadly classified as “traditional” videoconferencing systems or “Telepresence” systems. Most SIP implementations today are classified as traditional videoconferencing systems, but there are a growing number of telepresence systems that would benefit in differentiating the two through a media feature tag.

The traditional videoconferencing system, which might include any room-based system, desktop videophone, or application running on a computer, tablet, mobile phone, or similar device, typically uses lower-resolution video images and does not make an attempt to provide a real-life, immersive conferencing experience. Some traditional systems do employ high definition (HD) video, but still lack the quality of providing an in-person communication experience.

Telepresence systems, on the other hand, are visual conferencing environments that duplicate, as closely as possible, an in-person experience. The objective of such systems is to make the participants in the conference feel as if they are physically together, providing an immersive, realistic experience.

This document defines the "immersive" media feature tag for use in the SIP tree, as per Section 12.1 of RFC 3840 [RFC3840]. This feature tag can be utilized by SIP B2BUAs, SIP proxies, or other elements in the SIP network to help ensure the best communication experience for those wishing to establish a telepresence session or other communication session that might be classified as providing an immersive, realistic user experience.

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

"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.

3. Motivation

The primary motivation for defining an immersive media feature tag is for the transmission of a feature capability that implies a specific “user experience” that is differentiated from classic video. This feature tag can be considered by the various network elements to realize several possible use cases. To name a few:

• Admission control decisions: A system could use the media feature tags such as immersive, video, audio, etc. to allow network elements to reserve bandwidth or take measures to ensure the best possible experience.
• Selective routing decisions: A proxy or B2BUA could leverage the immersive feature tag to help make routing decisions, including the selection of a specific end system that supports the feature capability or to route a call over specific network segments.

4. Examples

The following examples omit the message body and various header fields for brevity.

4.1. Registration

Bob registers with the immersive media feature tag. The message flow is shown in Figure 1:

          
SIP Registrar                       Bob's
                            Telepresence Endpoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                               |
      |          REGISTER F1          |
      |<------------------------------|
      |                               |      
      |           200 OK F2           |
      |------------------------------>|
      |                               |
          

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bK309475a2
From: <sip:bob-tp@example.com>;tag=a6c85cf
To: <sip:bob-tp@pexample.com>
Call-ID: a84b4c76e66710
Max-Forwards: 70
CSeq: 116 REGISTER
Contact: <sip:bob-tp@example.com;transport=tcp>;immersive
Expires: 3600
		

F1 REGISTER Bob -> Registrar

The registrar responds with a 200 OK:

SIP/2.0 200 OK
From: <sip:bob-tp@example.com>;tag=a6c85cf
To: <sip:bob-tp@example.com>;tag=1263390604
Contact: <sip:bob-tp@example.com;transport=tcp>;immersive
Expires: 120
Call-ID: a84b4c76e66710
Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bK309475a2
CSeq: 116 REGISTER
Expires: 3600
		

F2 200 OK Registrar -> Bob

4.2. Session Establishment

Bob initiates a delayed offer call to Alice indicating that he supports the immersive media feature tag while Alice responds with her support of the immersive media feature tag. The message flow is shown in Figure 4:

          
Bob                            Alice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 |                               |
 |           INVITE F1           |
 |------------------------------>|
 |                               |      
 |        180 Ringing F2         |
 |<------------------------------|
 |                               |      
 |           200 OK F3           |
 |<------------------------------|
 |                               |
 |            ACK F4             |
 |------------------------------>| 
 |                               |      
 |           Media F5            |
 |<=============================>|
 |                               |
          

INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP bob-TP@example.com;branch=z9hG4bKnashds8
From: "bob" <sip:bob-tp@example.com>;tag=a6c85cf
To: "alice" <sip:alice@example.com>
Date: Tue, 01 Nov 2011 18:28:52 GMT
Call-ID: a84b4c76e66710
CSeq: 101 INVITE
Contact: <sip:bob-tp@example.com;transport=tcp>;immersive
Max-Forwards: 69
Content-Length: 0
		

F1 INVITE Bob -> Alice

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice@example.com;branch=z9hG4bKnashds8
From: "alice" <sip:alice@example.com>;tag=1928301774
To: "bob" <sip:bob-tp@example.com>;tag=a6c85cf
Date: Tue, 01 Nov 2011 18:28:52 GMT
Call-ID: a84b4c76e66710
CSeq: 101 INVITE
Contact: <sip:alice@example.com;transport=tcp>;immersive
Content-Length: 0
		

F2 180 Ringing Alice -> Bob

SIP/2.0 200 OK
Via: SIP/2.0/TCP alice@example.com;branch=z9hG4bKnashds8
From: "alice" <sip:alice@example.com>;tag=1928301774
To: "bob" <sip:bob-tp@example.com>;tag=a6c85cf
Date: Tue, 01 Nov 2011 18:28:52 GMT
Call-ID: a84b4c76e66710
CSeq: 101 INVITE
Contact: <sip:alice@example.com;transport=tcp>;immersive
Content-Type: application/sdp
Content-Length: 1963
		

F3 200 OK Alice -> Bob

ACK sip:aliceexample.com;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.0.0.2:5060;branch=z9hG4bKnashds9
From: "bob" <sip:bob-tp@example.com>;tag=a6c85cf
To: "alice" <sip:alice@example.com>;tag=1928301774
Date: Tue, 01 Nov 2011 18:28:52 GMT
Call-ID: a84b4c76e66710
Max-Forwards: 70
CSeq: 101 ACK
Contact: <sip:bob-tp@example.com;transport=tcp>;immersive
Content-Type: application/sdp
Content-Length: 1452
		

F4 ACK Bob -> Alice

Media streams are established between Bob and Alice.
		

F5 Media transmission Bob <-> Alice

5. Security Considerations

The security considerations related to the use of media feature tags from Section 11.1 of RFC 3840 [RFC3840] apply.

6. IANA Considerations

This specification adds a new media feature tag to the SIP Media Feature Tag Registration Tree per the procedures defined in RFC 2506 [RFC2506] and RFC 3840 [RFC3840].

Media feature tag name:

sip.immersive

ASN.1 Identifier:

1.3.6.1.8.4.{PH}

Summary of the media feature indicated by this tag:

This feature tag indicates that the device provides an immersive audio and/or video communication experience.

Values appropriate for use with this feature tag:

Boolean.

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

This feature tag is most useful in a communications application for describing the capabilities of a device, such as a Telepresence system.

Examples of typical use:

Routing a call to a multimedia communication system that can provide an immersive communication experience.

Related standards or documents:

RFCXXXX

Security Considerations:

Security considerations for this media feature tag are discussed in Section 5 of this document.

[[NOTE TO RFC EDITOR: Please change {PH} above to the correct identifier for this entry in the IANA registry for iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4)]]

[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]]

7. Acknowledgements

Thanks go to the Medianet Session Control group at Cisco for their insightful discussion, advice and feedback that led to the creation of this document.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses