<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!--rfc category="info" ipr="full3978"-->
<rfc category="std" docName="draft-ram-straw-b2bua-feature-tag-00"
     ipr="trust200902">
  <front>
    <title abbrev="A SIP Media Feature Tag for B2BUAs">A Session Initiation Protocol (SIP) Feature Tag for Back-to-Back User Agents (B2BUAs)</title>

    <author fullname="Ram Mohan Ravindranath" initials="R."
            surname="Ravindranath">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>Cessna Business Park</street>

          <street>Sarjapur-Marathahalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>rmohanr@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</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="2015" />

    <area>Applications and Real-Time Area (ART)</area>

    <workgroup>STRAW</workgroup>

    <abstract>
      <t>The User Agent capabilities specification allows Session Initiation Protocol (SIP) User Agents to convey their capabilities and characteristics to other User Agents and to the registrar for its domain.  This information is conveyed as parameters of the Contact header field. Amongst those capabilities are the type of User Agent that is available at a SIP Uniform Resource Identifier (URI). This document extends the User Agent capabilities specification to allow indication of Back-to-Back User Agent (B2BUA) types.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <section title="Overview and Motivation">
        <t>In current Session Initiation Protocol (SIP)<xref target="RFC3261"/> deployments, there are numerous forms of Back-to-Back User Agents (B2BUAs), operating at various levels of transparency and for many differing purposes, and with widely varying behaviors.  Some act as pure SIP proxies and only change to the role of B2BUA in order to generate BYEs to terminate dead sessions. Some are full User Agent (UA) stacks with only high-level event and application logic binding the User Agent Server (UAS) and User Agent Client (UAC) sides. Some B2BUAs operate only in the SIP signaling plane, while others participate in the media plane as well. <xref target="RFC7092"/> provides a taxonomy of several common B2BUA roles.</t>

        <t>As more SIP domains are deployed and interconnected, the probability of a single SIP session crossing multiple B2BUAs at both the signaling and media planes increases significantly. B2BUAs, as described in <xref target="RFC7092"/>, modify SIP and Session Description Protocol (SDP) <xref target="RFC4566"/> bodies and are also likely to be on the media path. Such entities, when present in the signaling and/or media path, are likely to take several actions of varying intrusiveness. For example, some B2BUAs modify parts of the SDP body (like IP address, port) and subsequently modify the Real-time Transport Protocol (RTP) <xref target="RFC3550"/> headers as well. Given that a B2BUA can perform such a wide variety of operations, a SIP UA originating a call may wish to know that it is communicating with a B2BUA. The B2BUA type can be used by a SIP UA to selectively disable identity validation procedure. For B2BUAs functioning in the media termination mode or media aware mode modifying the RTP/RTCP headers, the UA can disable peer identity validation procedure.
 </t>
         
         <t> There are specifications like <xref target="RFC3840"/> that allow a SIP User Agent to convey its capabilities and characteristics to other User Agents and to the registrar for its domain.  This information is conveyed as parameters in the Contact header field. Amongst those capabilities is the type of UA that is available at a SIP URI. For example, <xref target="RFC3840"/> has the isFocus indicator that is used in SIP signaling for conference servers, a special case of B2BUA. There are also other specifications that allow a B2BUA to indicate its capabilities, such as in Session Recording Protocol <xref target="I-D.ietf-siprec-protocol"/>. However, there may be more types of B2BUAs, as defined in  <xref target="RFC7092"/>. Prior to this document there is no support for allowing a UA to indicate its type as a B2BUA. This document extends the User Agent capabilities specification, defined in <xref target="RFC3840"/>, to allow a UA to indicate that it is a B2BUA as well as identify the specific type of B2BUA.</t>
    </section>
      
    <section title ="Document Goals">
    <t>The goal of this document is not to ensure end-to-end security of SIP calls. The intent of this memo is, if a middlebox (like a B2BUA) declares its existence, then that transparency is likely to improve communication and operation overall. At a minimum, this will provide
indication to the caller and callee that it is talking to a B2BUA, which can then decide on what to do with that information.</t>
    </section>
    </section>     

    <section anchor="sec-term" 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>The following generalized terms are defined in <xref target="RFC3261"/>, Section 6.</t>

      <t><list style="hanging">
          <t>B2BUA: a SIP Back-to-Back User Agent, which is the logical
          combination of a User Agent Server (UAS) and User Agent Client
          (UAC).</t>

          <t>UAS: a SIP User Agent Server.</t>

          <t>UAC: a SIP User Agent Client.</t>
        </list></t>

      <t>All of the pertinent B2BUA terminology and taxonomy used in this document is based on <xref target="RFC7092"/>.</t>

      <t>It is assumed the reader is already familiar with the SIP User Agent capabilities specification defined in <xref target="RFC3840"/>.</t>
    </section>

    <section title="Overview of Operation">

    <section title="SIP Media Feature Tag for B2BUAs">
       
      <t>This section describes how a B2BUA, as defined in <xref target="RFC7092"/>, can convey its capabilities and characteristics to other User Agents and to the registrar for its domain by leveraging and extending the semantics of <xref target="RFC3840"/>.</t>

       <t> A B2BUA is essentially comprised of two UAs, one acting as a UAC and other a UAS. So, each side of a B2BUA, when it registers, can indicate a subset of capabilities in a REGISTER message, as described in <xref target="RFC3840"/>, or in response to an OPTION message or in-dialog messages. Along with those capabilities, the B2BUA MUST also indicate its B2BUA type. This type will be indicated in a REGISTER message to the registrar in the B2BUA domain. It can also be indicated in response to an OPTION message. The B2BUA MUST also indicate the type as part of in-dialog messaging (INVITE, UPDATE, etc.).</t>
       
       <t>The syntax of the B2BUA type MUST follow the <xref target="RFC3840"/> syntax, which requires all new feature tags to have "+" followed by "sip.tag_name". The Contact header of SIP messages from the B2BUA MUST have this new feature tag. The tag MUST contain one or more of the below values:</t>
       
       <t><list style="hanging">
         <t>sip.isSignalingB2BUA - This feature tag will be used by B2BUAs who act only on the signaling plane (SIP and/or SDP modifying only), as defined in Section 3.1 of <xref target="RFC7092"/>.</t>
         
          <t>sip.isMediaRelayB2BUA - This feature tag will be used by B2BUAs who act on the media plane as a media unaware relay, as defined in Section 3.2.1 of <xref target="RFC7092"/>.</t>

          <t>sip.isMediaAwareRelayB2BUA - This feature tag will be used by B2BUAs who act on the media plane as a media aware relay, as defined in Section 3.2.2 of <xref target="RFC7092"/>.</t>
          
          <t>sip.isMediaAwareHeaderModifyingB2BUA - This feature tag will be used by B2BUAs who act on the media plane as a media aware relay, as defined in Section 3.2.2 of <xref target="RFC7092"/> and will likely modify the media headers.</t>
           
           <t>sip.isMediaTerminationB2BUA - This feature tag will be used by B2BUAs who act on the media plane and terminate media, as defined in section 3.2.3 of <xref target="RFC7092"/>.</t>
        </list></t>
       </section>
       
       <section title="Example Usage of SIP Media Feature Tag for B2BUAs">
       <t>Below is example REGISTER message with the Contact header showing B2BUA type feature tag. In this example, the B2BUA registering is a media aware relay B2BUA.</t>
        
         <t> 
           <figure>
        <artwork><![CDATA[
        
          REGISTER sip:example.com SIP/2.0
          From: sip:user@example.com;tag=asd98
          To: sip:user@example.com
          Call-ID: hh89as0d-asd88jkk@host.example.com
          CSeq: 1 REGISTER
          Max-Forwards: 70
          Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
          Contact: <sip:b2bua1@host.example.com>;audio;video;
                  methods="INVITE,BYE,OPTIONS,ACK,CANCEL"; 
                  +sip.isMediaAwareRelayB2BUA 
         Content-Length: 0
        ]]></artwork>
        </figure>
         </t>
         
         <t>Note that in the above example the B2BUA, apart from indicating other capabilities it has, also indicates that it is a B2BUA that acts as media aware relay.</t>
         
       <t>[[NEEDS WG DISCUSSION: Do we need a separate feature tag for each B2BUA type? It is feasible to do so, however the issue is a B2BUA may likely play multiple roles described in <xref target="RFC7092"/>, depending upon call scenario. For example, for one scenario the B2BUA may be simple media relay, for some other scenario, the same B2BUA may play a media aware relay. So its tricky to indicate one specific type. Perhaps should such a B2BUA indicate multiple feature tags?]]</t>
    </section>
    </section>
    

    <section title="Security Considerations">
      <t> When present in a REGISTER request, this media feature tag gives information on the set of supported application media streams.  It is possible that this information is sensitive, providing insight into
the capabilities of a product.  These considerations are already discussed in <xref target="RFC3840"/>, and those considerations apply here as well.</t>

<t>Applications that utilize this media feature tag MUST provide a means for ensuring its integrity.  Similarly, the media feature tag should only be trusted as valid when it comes from the user or User Agent described by the feature tag.  As a result, mechanisms for conveying the feature tag MUST provide a mechanism for guaranteeing authenticity. If B2BUA advertises any type other than sip.isMediaTerminationB2BUA and 
 sip.isMediaAwareHeaderModification and the identity validation procedure
 <xref target="I-D.ietf-stir-rfc4474bis"/> by the 
 UA fails then it is an indication that the B2BUA or devices on the other side are misbehaving or have malicious intents.</t>
    </section>

    <section anchor="sec.iana-considerations" title="IANA Considerations">
      
      <t>This section registers new media feature tags in the SIP tree, defined in Section 12.1 of <xref target="RFC3840"/>. The following feature tags are defined by this specification.</t>

   <t><list style="hanging">
         <t>Media feature tag name: sip.isSignalingB2BUA.</t>
         <t>Summary of the media feature indicated by this tag:  This feature tag will be used by B2BUAs who act only on the signaling plane (SIP and/or SDP modifying only), as defined in Section 3.1 of <xref target="RFC7092"/>.</t>
         
          <t>Media feature tag name:  sip.isMediaRelayB2BUA .</t>
          <t>Summary of the media feature indicated by this tag:  This feature tag will be used by B2BUAs who act on the media plane as a media unaware relay, as defined in Section 3.2.1 of <xref target="RFC7092"/>.</t>

          <t>Media feature tag name:  sip.isMediaAwareRelayB2BUA. </t>
          <t>Summary of the media feature indicated by this tag:  This feature tag will be used by B2BUAs who act on the media plane as a media aware relay, as defined in Section 3.2.2 of <xref target="RFC7092"/>.</t>
          
          <t>Media feature tag name:  sip.isMediaAwareHeaderModifyingB2BUA. </t>
          <t>Summary of the media feature indicated by this tag:  This feature tag will be used by B2BUAs who act on the media plane as a media aware relay, as defined in Section 3.2.2 of <xref target="RFC7092"/> and will likely modify headers.</t>
           
           <t>Media feature tag name:  sip.isMediaTerminationB2BUA. </t>
           <t>Summary of the media feature indicated by this tag:  This feature tag will be used by B2BUAs who act on the media plane and terminate media, as defined in Section 3.2.3 of <xref target="RFC7092"/>.</t>
   </list></t>

   <t>Values appropriate for use with all the above feature tags: Boolean.</t>
   
    </section>

    <section title="Acknowledgments">
      <t>Special thanks to Stephen Farrel, whose IESG review (and subsequent discussion) of <xref target="I-D.ietf-straw-b2bua-stun"/> led to the formulation of this draft. Additionally, the authors would like to thanks all the members of the STRAW WG for their comments and discussion that helped improve 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.3261"?>
      <?rfc include="reference.RFC.3550"?>
      <?rfc include="reference.RFC.4566"?>
      <?rfc include="reference.RFC.7092"?>
      <?rfc include="reference.I-D.ietf-siprec-protocol"?>
	  <?rfc include="reference.I-D.ietf-straw-b2bua-stun"?> 
	  <?rfc include="reference.I-D.ietf-stir-rfc4474bis"?>

    </references>
  </back>
</rfc>
