<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-dispatch-ipv6-atypes-01"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="The atypes media feature tag">The atypes media feature tag
    for Session Initiation Protocol (SIP)</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Andrew Allen" initials="A." surname="Allen">
      <organization>Blackberry</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <country>USA</country>
        </postal>

        <email>aallen@blackberry.com</email>
      </address>
    </author>

    <date day="11" month="June" year="2013" />

    <keyword>Internet-Draft</keyword>

    <keyword>SIP</keyword>

    <keyword>IPv6</keyword>

    <abstract>
      <t>This specification defines a new media feature tag called atypes.
      This new media feature tag indicates the IP address type capabilities of
      the UA (User Agent) and can aid the routing process and ease the
      invocation of required functions when heterogeneous (i.e., IPv4 and
      IPv6) parties are involved in a given SIP session.</t>

      <t>This specification solves a problem raised in 3GPP TS 24.229 <xref
      target="TS.24229"></xref>.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Due to IPv4 address exhaustion problem, IPv6 deployment should be
      accelerated. In this context and especially from a SIP perspective <xref
      target="RFC3261"></xref>, the IPv4-IPv6 co-existence introduces
      heterogeneous scenarios with combinations of IPv4 and IPv6 nodes some of
      which are capable of supporting both IPv4 and IPv6 (i.e., dual-stack
      (DS)) and some of which are capable of supporting only IPv4 or only
      IPv6. Additionally, some UAs that are dual-stack capable are unable to
      use both interfaces natively at the same time which can mean for example
      that if a UA has to use IPv6 for signaling it cannot use IPv4 for media
      even though the UA supports an IPv4 stack. This mainly motivated by
      restrictions due to available resources such the need to maintain one
      PDP (Packet Data Protocol) context in case of mobile networks.</t>

      <t><xref target="RFC6157"></xref> provides recommendations to solve this
      issue including recommending dual-stack nodes in the core service
      platform having the signalling and media path traverse these DS
      elements. While this is viable for big service providers it not viable
      for smaller ones especially at the earlier stages of IPv6 deployment.
      Upgrading existing networks to follow all these recommendations requires
      a large investment.</t>

      <t>An interim alternative is to use a SIP Application Level Gateway
      (ALG) and a IPv4-IPv6 Interworking Function to convert between IPv4 and
      IPv6 addressing. However an ALG and a IPv4-IPv6 Interworking Function
      introduce additional nodes into the signaling and media paths and can
      result in the so called "trombone" effect with signaling and even more
      importantly media being unnecessarily routed via an ALG/IPv4-IPv6
      Interworking Function in a network located at a significant distance
      from both of the UAs involved in the session. This is particularly
      significant in mobile networks in roaming scenarios where potentially
      media then has be routed via multiple hops over international links when
      a roaming user establishes a session with a user located in the roamed
      to country. This situation is potentially unavoidable when an
      ALG/IPv4-IPv6 Interworking Function is needed to be inserted in the
      signaling and the media path because of incompatible IP versions between
      UAs that require IP address translation. It is highly undesirable to
      redundantly include ALG/IPv4-IPv6 Interworking nodes in the path when
      the UAs can establish sessions without requiring ALG/IPv4-IPv6
      Interworking nodes in the path.</t>

      <t>In order to avoid redundant inclusion of ALG/IPv4-IPv6 Interworking
      nodes in the path, it is necessary for network nodes to be able to
      determine the connectivity types supported by UAs prior to forwarding
      session establishment requests. Without such a capability, SIP Proxy
      Servers have no way to predict a session failure without a ALG/IPv4-IPv6
      Interworking being included in the path even when ICE <xref
      target="RFC5245"></xref> or ALTC <xref target="RFC6947"></xref> are also
      used.</t>

      <t>Additionally, when multiple UAs are registered with the same Address
      of Record (AoR) it is useful to be able to have a UA indicate a
      preference to contact a UA using the mechanism defined in <xref
      target="RFC3841">RFC 3841</xref> that supports the same IP version in
      order to avoid the need for ALG/IPv4-IPv6 Interworking node.</t>

      <t>This specification also addresses call routing and optimization
      mechanisms using the atypes Media Feature Tag to avoid as much as
      possible invoking SIP ALGs and IPv4-IPv6 Interworking Function when
      establishing a multimedia session between UAs.</t>
    </section>

    <section title="Justification for atypes">
      <t>SIP service platforms should be aware of the type of the involved
      peers before forwarding session establishment requests. If these means
      are not supported, SIP Proxy Servers have no way to predict a session
      failure, even if ICE or ALTC procedures are adopted, and also to
      optimise the invocation of adaptation functions.</t>

      <t>The first alternative to notify the service platform about the type
      of the UA is to send SIP REGISTER message which encloses all available
      IP addresses. For IPv4-only and IPv6-only UAs, only one single IP
      address is carried in SIP REGISTER messages. For DS UAs, two IP
      addresses are enclosed. Upon receipt, of this message, the registrar
      stores these addresses. Two registration databases may be maintained,
      one for IPv4 and another one for IPv6. A second alternative is to send
      several REGISTER request using available connectivity types. In this
      case, a DS UA sends two REGISTER messages. The first one is sent using
      its IPv4 connectivity and the second one using its IPv6 one. Two
      databases are maintained by the conversational service platform.
      Consequently, upon receipt of an INVITE, the SIP Proxy Server may
      question its databases to retrieve the types of the involved parties.
      SIP ALG is invoked accordingly.</t>

      <t>The drawback of this procedure is that it depends on the behavior of
      the terminal. A standardised behavior should be encouraged. To that aim,
      a new Media Feature Tag is introduced in this document. More details are
      provided hereafter.</t>

      <t>According to Section 5.4.4.1 of <xref target="TS.24229"></xref>, if
      the S-CSCF knows that the UE supports both versions simultaneously, it
      forwards the initial INVITE request to the UE without examining the SDP
      Offer. Section 5.4.3.1 of <xref target="TS.24229"></xref> indicates also
      if the S-CSCF knows that the originating UE supports both IPv6 and IPv4
      addresses simultaneously, the S-CSCF will forward the error response to
      the UE using the Via header field. However, <xref
      target="TS.24229"></xref> does not currently specify any solution to
      enable the S-CSCF to get this knowledge. atypes is intended to be a
      solution for that problem.</t>
    </section>

    <section title="Relationship of atypes to ICE/ALTC">
      <t>ICE <xref target="RFC5245"></xref> specification deprecates <xref
      target="RFC4091"></xref><xref target="RFC4092"></xref>. Like ANAT, ICE
      can be used to enclose both IPv4 and IPv6 information in a given SDP
      offer. In the remaining part, ANAT and ICE are used interchangeably
      since, from IPv4-IPv6 Interworking perspective, both provide the same
      solution. ALTC <xref target="RFC6947"></xref> is solution that allows to
      convey both an IPv4 address and IPv6 address in the same SDP offer.</t>

      <t>Both ICE and ALTC make it possible for DS UAs to provide both IPv4
      and IPv6 addresses for a single logical media stream. This singularly
      helps interworking as, whatever the distant UA version is
      (IPv4/IPv6-only or dual-stack), this latter should be able to understand
      at least one of the offers. In this way the ICE/ALTC semantic provides a
      first approach to interworking problem, when heterogeneous UAs are
      involved in the SIP communication. It indeed improves SIP exchanges, in
      so far as it allows all sessions arising/coming from dual-stack UA to
      lead to successful calls.</t>

      <t>This interesting feature needs however to be nuanced, as it
      unfortunately does not fit all cases. <xref target="RFC4091"></xref>
      already lists some cases where, depending on the implementation,
      recipients of an offer using ANAT might have different behaviours, thus
      requiring the introduction of the sdp-anat option-tag. ANAT also
      requires the UA to be dual-stack, which means it does not cover the case
      where UAs belong to different and restrictive IP version realms. In
      other words, the ANAT solution does not help solving scenarios where
      mono-stack (i.e., IPv4 or IPv6) UAs are involved. In this latter case,
      SIP exchanges can only succeed if intermediary nodes or functions (Proxy
      Servers, ALG, Session Border Controllers (SBCs), etc.) intervene in the
      signalling path. This intervention, denoted as IPv4-IPv6 adaptation
      function in the rest of this document, is necessary to ensure a
      successful SIP exchange between these mono-satck UAs. Unfortunately, in
      these situations, ANAT/ICE does not help SIP servers situated all along
      the signalling path to take the right decision when IPv4-IPv6
      interconnection needs (or should need) to be tackled.</t>

      <t>The atypes Media Feature Tag helps to provide a global answer to the
      interconnection problem, when heterogeneous SIP UAs are involved.
      Moreover, it aids SIP nodes situated all along the signalling path, to
      determine when to invoke the adaptation function helping the routing of
      the call.</t>

      <t>The atypes Media Feature Tag makes it possible for SIP Proxy Servers
      to determine the IP versions supported by the distant and the
      originating UA, when they process the initial SIP request. This means
      that, the earlier possible in the exchange, a SIP node becomes aware of
      the potential interconnection problem due to IP version incompatibility.
      This also means that this particular node can trigger the invocation of
      the adaptation function, which will modify the initial SDP offer in
      order to make this SIP exchange successful.</t>

      <t>The atypes Media Feature Tag can therefore aid treatment of all
      exchange types intervening between mono-stack (IPv4 or IPv6) or
      dual-stack UAs (whether they use ICE or not). Anytime a potential
      interconnection problem is suspected using the atypes Media Feature Tag,
      the SIP Proxy will be able to drive the adaptation function invocation
      and route the SIP exchange accordingly.</t>

      <t>The atypes Media Feature Tag can also provide interesting
      optimisation characteristics. For instance, a service provider might
      force adaptation function like SIP ALGs to be invoked each time the SIP
      message leave an IPv4 realm for an IPv6 realm (and vice-versa), in order
      to modify the SDP offer accordingly. This kind of modifications could
      happen more than once during the SIP signalling exchanges (and even more
      than once in a single direction). In the end, both UAs intervening in
      the SIP exchange might be of the same type, thus not requiring any
      change of the SDP offer. Using the atypes Media Feature Tag such
      situation could be avoided, as the SIP Proxy Server would determine UAs
      are compatible, thus no modification should be make to SDP offers, even
      if Layer 3 information are modified during the routing of the SIP
      message.</t>

      <t>The atypes Media Feature Tag can also help in the case where
      different SIP realms are crossed, where the information from the atypes
      Media Feature Tag for the distant UA is not available at the originating
      Proxy Server. In this case, the atypes Media Feature Tag can be included
      in the SIP request thus enabling the distant SIP Proxy Server, which has
      the atypes Media Feature Tag information for the remote UA, to determine
      whether to route the SIP request via its adaptation function.</t>

      <t>The atypes Media Feature Tag is not limited to the single IPv4-IPv6
      interconnection problem, though this first version of the specification
      is dedicated to this usage.</t>

      <t>Further values of atypes can be defined in future specifications. The
      atypes Media Feature Tag is also compatible with the parallel usage of
      ICE or ALTC.</t>
    </section>

    <section title="Specification of sip.atypes Media Feature Tag">
      <t></t>

      <section title="sip.atypes Media Feature Tag">
        <t>The 'sip.app-subtype' media feature tag is of type token with a
        case-sensitive equality relationship. It indicates whether a
        (communications) device supports IPv4 for both signaling and media,
        IPv6 for both signaling and media, IPv6 for signaling and IPv4 for
        media simultaneously, IPv4 for signaling and IPv6 for media
        simultaneously. A plurality of tokens is included for all the
        supported combinations. Its values include:</t>

        <t><list style="symbols">
            <t>ipv4: The device supports IPv4.</t>

            <t>ipv6: The device supports IPv6.</t>
          </list></t>

        <t>Other values of atypes can be defined such as:</t>

        <t><list style="symbols">
            <t>ipv4_via_nat46: When enclosed in a SIP message, a given SIP UA
            indicates "here is my IPv4 address, it goes through a translator
            so avoid using it if you can utilize my IPv6 address"</t>

            <t>ipv6_via_nat64: When enclosed in a SIP message, a given SIP UA
            indicates "here is my IPv6 address, it goes through a translator
            so avoid using it if you can utilize my IPv4 address"</t>

            <t>ipv4_via_cgn: When enclosed in a SIP message, a given SIP UA
            indicates "here is my IPv4 address, it goes through a CGN device
            so avoid using it if you can utilize a public IPv4 or IPv6
            address"</t>
          </list></t>

        <t></t>
      </section>

      <section title="Behavior">
        <t>When atypes is included in the Contact header field of a REGISTER
        request or an INVITE request, a UAC SHOULD include all atypes values
        that represent the address type combinations it can currently support.
        When included in the Contact header field of a response a UAS SHOULD
        include all atypes values that represent the address type combinations
        it can currently support.</t>

        <t>A UAS that receives an OPTIONS request SHOULD include in the
        Contact header field an atypes Media Feature Tag containing all atypes
        values that represent the address type combinations it can currently
        support.</t>

        <t>A given UA MAY restrict its SIP communications to its IPv4-only
        interface or IPv6-only ones or MAY use all available ones. The
        selected local restriction is conveyed in the atypes Media Feature
        Tag. Within this context, an IPv6 interface is judged available only
        if the scope of this interface is global and not local to the
        link.</t>

        <t>When included in the Accept-Contact or Reject-Contact header field,
        it indicates a desire on the part of a UAC to be connected to a UAS
        which can support, or cannot support respectively, the address types
        and address type combinations specified.</t>
      </section>

      <section title="Session Routing Considerations">
        <t>Based on atypes tag value, the Registrar classifies the UA IP
        address capabilities for signaling and media.</t>

        <t>In order to route calls and to decide the need to invoke a SIP ALG
        or to alter SIP messages, which leads to a successful call between
        heterogeneous parties, a SIP Proxy Server MAY act as follows:</t>

        <t><list style="letters">
            <t>A first alternative is to interrogate the registration database
            maintained by the Registrar Server: In this alternative, the SIP
            Proxy Server asks the Registrar Server about the type of the
            Called and the Caller parties. The SIP Proxy Server decides to
            invoke an ALG in case the two involved parties are either
            IPv4-only or IPv6-only.</t>

            <t>The second alternative is to examine the atypes Media Feature
            Tag conveyed in the Contact header field of the INVITE request and
            the atypes Media Feature Tag values stored by the Registrar Server
            for the address type of the Called party. In this scenario, the
            SIP Proxy Server routes the call by comparing the compatibility of
            the two retrieved atypes values (types of Called and Caller
            parties).</t>
          </list></t>
      </section>
    </section>

    <section title="Examples of atypes tag usages">
      <t>These sections provide a set of SIP message examples when atypes
      media feature tag is used.</t>

      <section title="IPv4-only UA">
        <t>Let consider an IPv4-only UA denoted "HostA". Its IP address is
        192.0.2.1. This UA has been provisioned with required contact
        information to contact its Registrar (RS). In this example, a FQDN is
        provided: registrar.example.com. Means that have been used to
        provision the UA are out of scope of this document.</t>

        <t>(1) A sends this REGISTER message to its Registrar Server RS:</t>

        <t></t>

        <figure align="center">
          <artwork><![CDATA[REGISTER sip:registrar.example.com SIP/2.0 
Via: SIP/2.0/UDP 192.0.2.1:5062;branch=z9hG4bK00e31d6ed 
Max-Forwards: 70 
Content-Length: 0 
To: HostA <sip:HostA@example.com> 
From: HostA <sip:HostA@example.com>;tag=ed3833bd7363e68 
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 
CSeq: 1830746364 REGISTER 
Contact: HostA <sip:HostA@192.0.2.1:5062>
         ;atypes="ipv4";expires=900]]></artwork>
        </figure>

        <t></t>

        <t>(2) RS answers to A with a 200 OK message as follows:</t>

        <t></t>

        <figure align="center">
          <artwork><![CDATA[SIP/2.0 200 OK 
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 
CSeq: 1830746365 REGISTER 
From: HostA <sip:HostA@example.com>;tag=ed3833bd7363e68 
To: HostA <sip:HostA@example.com>;tag=3ab7fe89d998709 
Via:SIP/2.0/UDP 192.0.2.1:5062;branch=z9hG4bK00e31d6ed 
Content-Length: 0 
Contact: HostA <sip:HostA@192.0.2.1:5062>
         ;atypes="ipv4";expires=900]]></artwork>
        </figure>

        <t></t>
      </section>

      <section title="IPv6-only UA">
        <t>Let consider an IPv6-only UA called HostB which IP address is
        2001:db8:0:0:1::1. Its attached Registrar Server is identified by this
        FQDN: registrar.example.com.</t>

        <t>(1) B sends to its Registrar Server the following message:</t>

        <t></t>

        <figure align="center">
          <artwork><![CDATA[REGISTER sip:registrar.example.com SIP/2.0 
Via: SIP/2.0/UDP 
  [2001:db8:0:0:1::1]:5060;branch=z9hG4bK00e31d6ed 
Max-Forwards: 70 
Content-Length: 0 
To: HostB <sip:HostB@example.com> 
From: HostB <sip:HostB@example.com>;tag=ed3833bd7363e68 
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746364 REGISTER 
Contact: HostB <sip:HostB@[2001:db8:0:0:1::1]:5060>
         ;atypes="ipv6";expires=900]]></artwork>
        </figure>

        <t></t>

        <t>(2) The Registrar Server answers with the following 200 OK
        message:</t>

        <t></t>

        <figure align="center">
          <artwork align="center"><![CDATA[SIP/2.0 200 OK 
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746365 REGISTER 
From: HostB <sip:HostB@example.com>;tag=ed3833bd7363e68 
To: HostB <sip:HostB@example.com>;tag=3ab7fe89d998709 
Via:SIP/2.0/UDP[2001:db8:0:0:1::1]:5060;branch=z9hG4bK00e31d6ed 
Content-Length: 0 
Contact: HostB <sip:HostB@[2001:db8:0:0:1::1]:5060>
         ;atypes="ipv6";expires=900]]></artwork>
        </figure>

        <t></t>

        <t>One IP address MAY be enclosed in the Contact header field of a
        dual stack registration message. The type of the contact address MAY
        be distinct from the value of atypes. For instance:</t>

        <t><list style="symbols">
            <t>an IPv4 address may be enclosed in the Contact header field
            even if the assigned atypes value is equal to "ipv6",</t>

            <t>or only one IP address may be carried in the Contact header
            field even if the atypes value is set to "ipv6,ipv4".</t>
          </list>The IP address in the Contact header field MAY be used by
        intermediary proxies when contacting the UA.</t>
      </section>

      <section title="Dual Stack UA">
        <t>Let consider a dual-stack UA (DS) which IP addresses are
        2001:db8:0:0:1::1 and 192.0.2.2 which does not support IPv4 and IPv6
        simultaneously. The FQDN of the Register Server is
        registrar.example.com.</t>

        <t>(1) DS sends a REGISTER message to its Registrar Server as
        follows:</t>

        <t></t>

        <figure align="center">
          <artwork><![CDATA[REGISTER sip:registrar.example.com SIP/2.0 
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK00e31d6ed 
Max-Forwards: 70 
Content-Length: 0 
To: DS <sip:DS@example.com> 
From: DS <sip:DS@example.com>;tag=ed3833bd7363e68 
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746364 REGISTER 
Contact: DS <sip:DS@192.0.2.2:5060>
         ;atypes="ipv4,ipv6";expires=900]]></artwork>
        </figure>

        <t></t>

        <t>(2) The Registrar Server answers with a 200 OK message as shown
        below:</t>

        <t></t>

        <figure align="center">
          <artwork><![CDATA[SIP/2.0 200 OK 
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746365 REGISTER 
From: DS <sip: DS@example.com>;tag=ed3833bd7363e68 
To: DS <sip:DS@example.com>;tag=3ab7fe89d998709 
Via:SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK00e31d6ed 
Content-Length: 0 
Contact: DS <sip:DS@192.0.2.2:5060>
         ;atypes="ipv4,ipv6";expires=900]]></artwork>
        </figure>

        <t></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This specification adds a new media feature tag to the SIP Media
      Feature Tag Registration Tree defined in <xref target="RFC3840">RFC
      3840</xref>.</t>

      <t>Media feature tag name: sip.atypes</t>

      <t>ASN.1 Identifier: TBD</t>

      <t>Summary of the media feature indicated by this tag: The sip.atypes
      media feature tag indicates whether a communications device supports
      IPv4 for both signaling and media, IPv6 for both signaling and media,
      IPv6 for signaling and IPv4 for media simultaneously, IPv4 for signaling
      and IPv6 for media simultaneously. A plurality of tokens is included for
      all the supported combinations.</t>

      <t>Values appropriate for use with this feature tag: Token with an
      equality relationship.</t>

      <t>Typical values include:</t>

      <t>ipv4: The device can support IPv4 addresses for both signaling and
      media.</t>

      <t>ipv6: The device can support IPv6 addresses for both signaling and
      media.</t>

      <t>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 phone or PDA.</t>

      <t>Examples of typical use: Optimally routing a session and ensuring
      compatibility between IP versions to successfully establish
      sessions.</t>

      <t>Related standards or documents: RFC XXXX [[Note to IANA: Please
      replace XXXX with the RFC number of this specification.]].</t>

      <t>Security Considerations: Security considerations for this media
      feature tag are discussed in <xref target="Security"></xref> of RFC XXXX
      . [[Note to IANA: Please replace XXXX with the RFC number of this
      specification.]]</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>SIP-related security considerations are discussed in <xref
      target="RFC3261"></xref>.</t>

      <t>When present in a SIP request or response, this media feature tag may
      be used to determine whether a session is routed via a ALG/IPv4-IPv6
      Interworking Function in order to successfully establish a session. If
      the values of the atypes Media Feature Tags are modified by an
      intermediary then it is possible that a session would fail to be
      established if the modified values caused the network proxies to not
      insert a ALG/IPv4-IPv6 Interworking Function when they are needed.
      However if the contact address itself is also modified this could also
      prevent a session being established. Integrity protection for the
      Contact header field SHOULD be provided.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.3840'?>

      <?rfc include='reference.RFC.3261'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4091'?>

      <?rfc include='reference.RFC.4092'?>

      <?rfc include='reference.RFC.3841'?>

      <?rfc include='reference.RFC.5245'?>

      <?rfc include='reference.RFC.6157'?>

      <?rfc include='reference.RFC.6947'?>

      <reference anchor="TS.24229">
        <front>
          <title>IP multimedia call control protocol based on Session
          Initiation Protocol (SIP) and Session Description Protocol (SDP);
          Stage 3</title>

          <author fullname="" surname="">
            <organization>3GPP</organization>
          </author>

          <date day="0" month="March" year="2013" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
