<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
    <!-- try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>    <!-- items used when reviewing the document -->
<?rfc comments="no" ?>  <!-- controls display of <cref> elements -->
<?rfc inline="no" ?>    <!-- when no, put comments at end in comments section,
                                otherwise, put inline -->
<?rfc editing="no" ?>   <!-- when yes, insert editing marks -->

    <!-- create table of contents (set it options).
           Note the table of contents may be omitted
         for very short documents -->

<?rfc toc="yes"?><?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>

    <!-- choose the options for the references. Some like
         symbolic tags in the references (and citations)
         and others prefer numbers. --> 
<?rfc symrefs="yes"?><?rfc sortrefs="yes" ?>
    <!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes" ?><?rfc subcompact="no" ?>
<!-- end of list of processing instructions -->
    <!-- Information about the document.
         categories values: std, bcp, info, exp, and historic
         For Internet-Drafts, specify attribute "ipr".
         (ipr values are: full3667, noModification3667, noDerivatives3667),
         Also for Internet-Drafts, can specify values for
         attributes "iprExtract", and "docName".  Note
         that the value for iprExtract is the anchor attribute
         value of a section that can be extracted, and is only
         useful when the value of "ipr" is not "full3667". -->
    <!-- TODO: verify which attributes are specified only
            by the RFC editor.  It appears that attributes
            "number", "obsoletes", "updates", and "seriesNo"
            are specified by the RFC editor (and not by
            the document author). -->

<rfc    
    category="std"
    ipr="trust200902"
    docName="draft-lavers-sipcore-immersive-capability-00" >
<front>
    <title abbrev="Immersive Media Feature Tag ">Indicating the Immersive User Agent Capability
    in&nbsp;the&nbsp;Session&nbsp;Initiation&nbsp;Protocol&nbsp;(SIP)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->    

    <author fullname="Glen Lavers" initials="G" surname="Lavers">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Mail Stop LKO2/3/</street>
          <street>5400 Meadows Road</street>
          <city>LAKE OSWEGO</city>
          <region>OR</region>
          <code>97035</code>
          <country>US</country>
        </postal>
        <email>glavers@cisco.com</email>
      </address>
    </author>

	<author fullname="Paul E. Jones" initials="P.E." surname="Jones">
	  <organization>Cisco Systems</organization>

		<address>
		  <postal>
			<street>7025 Kit Creek Road</street>
			<city>Research Triangle Park</city>
			<region>NC</region>
			<code>27709</code>
			<country>US</country>
		  </postal>
		  <email>paulej@packetizer.com</email>
		</address>
	  </author>

    <author fullname="Gonzalo Salgueiro" initials="G" surname="Salgueiro">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>US</country>
        </postal>
        <email>gsalguei@cisco.com</email>
      </address>
    </author>

    <date year="2012" />
<!-- month="May" is no longer necessary note also, day="30" is optional -->
    
    <area>Real Time Applications and Infrastructure</area>    
    
    <!-- WG name at the upperleft corner of the doc, IETF fine for individual submissions -->
    
    <workgroup>SIPCORE</workgroup>
	
    <abstract>
      <t>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.</t>
    </abstract>

</front>

<middle>

    <section anchor="Introduction" title="Introduction">
		<t>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.</t>
	
		<t>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.</t>
	
		<t>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.</t>
	
		<t>This document defines the "immersive" media feature tag for use in the SIP tree, as per Section 12.1 of RFC 3840 <xref target="RFC3840"></xref>.  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.</t>
    </section>

    <section anchor="Terminology" title="Terminology">
		<t>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 <xref target="RFC2119"/>.</t>

		<t>"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.</t>
	</section>
	
	<section anchor="Motivation" title="Motivation">
		<t>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:</t>
		
		<t>
		<list style="symbols">
			<t>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.</t>
			
			<t>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.</t>			
		</list>
		</t>
	</section>
	
	<section anchor="Examples" title="Examples">
	
		<t>The following examples omit the message body and various header fields for brevity.</t>
		
	<section anchor="Registration" title="Registration">
	
		<t>
		<figure anchor="immersive_registration" title="Immersive Media Feature Tag SIP Registration Example">
		  <preamble>Bob registers with the immersive media feature tag.  The message flow is shown in <xref target="immersive_registration"/>:
          </preamble>

          <artwork align="center">
          <![CDATA[
SIP Registrar                       Bob's
                            Telepresence Endpoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                               |
      |          REGISTER F1          |
      |<------------------------------|
      |                               |      
      |           200 OK F2           |
      |------------------------------>|
      |                               |
          ]]></artwork>
		  <postamble>
		  </postamble>
        </figure></t>
        
        <t>F1 REGISTER Bob -&gt; Registrar
		<figure>
		<artwork><![CDATA[
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
		]]></artwork>
        </figure></t>
		<t>The registrar responds with a 200 OK:</t>

		<t>F2 200 OK Registrar -&gt; Bob
		<figure>
		<artwork><![CDATA[
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
		]]></artwork>
        </figure></t>
    </section>
    
    <section anchor="Session_Establishment" title="Session Establishment">
    
		<t>
		<figure anchor="immersive_session_establishment" title="Immersive Media Feature Tag SIP Session Establishment Example">
		  <preamble>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 <xref target="immersive_session_establishment"/>:
          </preamble>

          <artwork align="center">
          <![CDATA[
Bob                            Alice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 |                               |
 |           INVITE F1           |
 |------------------------------>|
 |                               |      
 |        180 Ringing F2         |
 |<------------------------------|
 |                               |      
 |           200 OK F3           |
 |<------------------------------|
 |                               |
 |            ACK F4             |
 |------------------------------>| 
 |                               |      
 |           Media F5            |
 |<=============================>|
 |                               |
          ]]></artwork>
		  <postamble>
		  </postamble>
        </figure></t>
        
        <t>F1 INVITE Bob -&gt; Alice
		<figure>
		<artwork><![CDATA[
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
		]]></artwork>
        </figure></t>

        <t>F2 180 Ringing Alice -&gt; Bob
		<figure>
		<artwork><![CDATA[
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
		]]></artwork>
        </figure></t>

		<t>F3 200 OK Alice -&gt; Bob
		<figure>
		<artwork><![CDATA[
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
		]]></artwork>
        </figure></t>
        
        <t>F4 ACK Bob -&gt; Alice
        <figure>
		<artwork><![CDATA[
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
		]]></artwork>
        </figure></t>
        
		<t>F5 Media transmission Bob &lt;-&gt; Alice
		<figure>
		<artwork><![CDATA[
Media streams are established between Bob and Alice.
		]]></artwork>
        </figure></t>
	</section>	
	</section>

	<section anchor="Security" title="Security Considerations"> 
		<t>The security considerations related to the use of media feature tags from Section 11.1 of RFC 3840 <xref target="RFC3840"></xref> apply.</t>
	</section>
	
	<section anchor="IANA" title="IANA Considerations"> 
  		<t>This specification adds a new media feature tag to the SIP Media Feature Tag Registration Tree per the procedures defined in RFC 2506 <xref target="RFC2506"></xref> and RFC 3840 <xref target="RFC3840"></xref>.</t>
  		
      <t>
        <list style="hanging">
          <t hangText="Media feature tag name:">sip.immersive</t>
          <t hangText="ASN.1 Identifier:">1.3.6.1.8.4.{PH}</t>
          <t hangText="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.</t>
          <t hangText="Values appropriate for use with this feature tag:">Boolean.</t>
          <t hangText="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.</t>
          <t hangText="Examples of typical use:">Routing a call to a multimedia communication system that can provide an immersive communication experience.</t>
          <t hangText="Related standards or documents:">RFC&rfc.number;</t>
          <t hangText="Security Considerations:">Security considerations for this media feature tag are discussed in <xref target="Security"/> of this document.</t>
        </list>
      </t>
      
      <t>[[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)]]</t>
      
      <t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the number assigned to this specification, and remove this paragraph on publication.]]</t>
	</section>

    <section anchor="Acknowledgements" title="Acknowledgements">
    	<t>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.</t>
    </section>
    
</middle>

<back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.3840" ?>	 
    </references>
    <references title="Informative References">
      <?rfc include="reference.RFC.2506" ?>
      <?rfc include="reference.RFC.3261" ?>    
	</references>
  </back>
</rfc>