<?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" docName="draft-boucadair-pcp-sip-ipv6-07"
     ipr="trust200902">
  <front>
    <title abbrev="PCP &amp; SIP">Port Control Protocol (PCP) for SIP
    Deployments in Managed Networks</title>

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

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

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

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

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

    <author fullname="Parthasarathi Ravindran" initials="R."
            surname="Parthasarathi ">
      <organization>Nokia Networks</organization>

      <address>
        <postal>
          <street>Manyata Embassy Business park</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560045</code>

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

        <email>partha@parthasarathi.co.in</email>
      </address>
    </author>

    <date day="" />

    <abstract>
      <t>This document discusses how PCP (Port Control Protocol) can be used
      in SIP deployments in managed networks. This document applies for both
      IPv4 and IPv6.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The base Port Control Protocol (PCP, <xref target="RFC6887"></xref>)
      specification allows to retrieve the external IP address and external
      port to be conveyed in the SIP signaling messages <xref
      target="RFC3261"></xref>. Therefore, SIP Proxy Servers do not need to
      support means to ease the NAT traversal of SIP messages (e.g., <xref
      target="RFC5626"></xref>, <xref target="RFC6223"></xref>, etc.). Another
      advantage of using the external IP address and port is this provides a
      hint to the proxy server there is no need to return a small expire timer
      (e.g., 60s). In addition, the outbound proxy does not need any further
      feature to be supported in order to assist the remote endpoint to
      successfully establish media sessions. In particular, ALGs are not
      required in the NAT for this purpose and no dedicated functions at the
      media gateway are needed.</t>

      <t>This document discusses how PCP can be used in SIP deployments
      (including IPv6 considerations).</t>

      <t>The benefits of using PCP for SIP deployments are listed below:</t>

      <t><list style="symbols">
          <t>Avoid embedding an ALG in the middleboxes. Note, ALGs are not
          recommended since the evolution of the service would depend on the
          ALG maintenance.</t>

          <t>Not require any Hosted NAT Traversal function (e.g., <xref
          target="RFC7362"></xref>) to be embedded in the SIP server.
          Intermediate NATs and firewalls are transparent to the SIP service
          platform.</t>

          <t>Avoid overloading the network with keepalive message to maintain
          the mapping in intermediate middleboxes. <vspace
          blankLines="1" />Note, mechanisms such as STUN do not allow to
          discover the lifetime assigned by the middleboxes; frequent
          keepalive messages are therefore generated to maintain binding
          entries on those middleboxes. PCP is superior to those mechanisms as
          it allows to retrieve the assigned lifetime, and to provide hints to
          the middleboxes in order to decide which lifetime value is to be
          assigned for that particular flow.</t>

          <t>Work without requiring symmetric RTP/RTCP <xref
          target="RFC4961"></xref>.</t>

          <t>Not require symmetric SIP to work (i.e., rport <xref
          target="RFC3581"></xref>).</t>

          <t>Easily support unidirectional sessions.</t>

          <t>Does not encounter issues with early media.</t>

          <t>The combination of PCP and ALTC <xref target="RFC6947"></xref>
          allows to optimize IPv4-IPv6 interworking function resources.</t>

          <t>Because there is no need for connectivity checks, session
          establishment delay is not impacted (pairs of ports can be
          pre-reserved).</t>

          <t>The binding entries maintained by a flow-aware device
          (NAT/Firewall) can be associated with a textual description (<xref
          target="RFC7220"></xref>).</t>
        </list></t>

      <t>Experimentation results, including SIP flow examples, are documented
      in <xref target="I-D.boucadair-pcp-nat64-experiments"></xref>.</t>

      <t>In deployments where ICE <xref target="RFC5245"></xref> is required,
      PCP can be of great help as discussed in <xref
      target="I-D.penno-rtcweb-pcp"></xref> for the WebRTC case. ICE can be
      used in the context of SIP over WebSocket <xref target="RFC7118"></xref>
      and WebRTC when deployed within managed networks. Because TURN suffers
      from limitations in traversing NAT and firewalls over UDP, PCP is a
      promising solution that can complement ICE in those deployment contexts
      to soften the experienced high failure rate <xref
      target="ICEFailure"></xref>.</t>

      <t>The document targets SIP deployments in managed networks. It can also
      be used as part of SIP-based services delivery in the context of
      network-located residential gateway effort <xref
      target="WT-317"></xref>. Typical deployment scenarios are shown in <xref
      target="ref"></xref>.</t>

      <t><figure align="center" anchor="ref"
          title="Typical deployment scenarios">
          <artwork><![CDATA[(a) SIP UA behind a NAT/FW communicating with a Proxy Server
                                 __________
+----------+   +----------+    /          \   +------------+
|  SIP UA  |___|  NAT/FW  |____| Network  |___|  SIP Proxy |
|PCP Client|   |PCP Server|    |          |   |   Server   |
+----------+   +----------+    \__________/   +------------+

(b) SIP UA behind a NAT/FW communicating with a remote SIP UA
                                 __________
+----------+   +----------+    /          \   +------------+
|  SIP UA  |___|  NAT/FW  |____| Network  |___|   SIP UA   |
|PCP Client|   |PCP Server|    |          |   |            |
+----------+   +----------+    \__________/   +------------+

(c) SIP UAs behind a NATs/FWs
                              __________
+----------+  +----------+  /          \  +----------+  +----------+
|  SIP UA  |__|  NAT/FW  |__| Network  |__|  NAT/FW  |__|  SIP UA  |
|PCP Client|  |PCP Server|  |          |  |PCP Server|  |PCP Client|
+----------+  +----------+  \__________/  +----------+  +----------+

(d) SIP UA behind a CPE: PCP Proxy
                                                 
+----------+    +---------+          +----------+
|  SIP UA  |____|   CPE   |__________|   CGN/FW |
|PCP Client|    |PCP Proxy|          |PCP Server|
+----------+    +---------+          +----------+

]]></artwork>
        </figure></t>

      <t>The PCP server can be provisioned using a variety of means (e.g.,
      <xref target="RFC7291"></xref>) or rely on the discovery method
      specified in <xref target="RFC6887"></xref>.</t>

      <t>This document does not make any assumption whether the PCP client is
      implemented as an OS service or whether it is integrated in the SIP User
      Agent (UA). Those considerations are implementation-service.</t>
    </section>

    <section title="PCP Features">
      <t></t>

      <section title="Learn External IP Address and Port Number">
        <t>The PCP base specification allows to create mappings in
        PCP-controlled devices and therefore prepare for receiving incoming
        packets. A SIP UA can use PCP to create one mapping for SIP signalling
        messages and other mappings for media session purposes.</t>

        <t>The SIP UA uses the external IP address and port number to build
        SIP headers. In particular, this information is used to build the VIA
        and CONTACT headers.</t>

        <t><xref target="ex1"></xref> shows an example of the flow exchange
        that occurs to retrieve the external IP address and an external IP
        address assigned by the NAT, while <xref target="ex1"></xref> provides
        an excerpt of the SIP REGISTER message issued by the SIP UA; only the
        assigned IP address and port number are present in the SIP
        headers.</t>

        <t><figure align="center" anchor="ex1" title="SIP REGISTER Call Flow">
            <artwork><![CDATA[+---------+              +-------+       +------------+
| SIP UA  |              | NAT   |       |  IPv4 SIP  |
|   PCP   |              |+ PCP  |       |Proxy Server|
| Client  |              |Server |       | "Mysip.fr" | 
+---------+              +-------+       +------------+     
     |     (a) PCP MAP       |                |
     |Suggested External IP@ |                |
     |         ::ffff:0.0.0.0|                |             
     |Suggested External Port|                |
     |                   5060|                |
     |======================>|                |             
     |     (b) PCP MAP       |                |
     |Suggested External IP@ |                |
     |       ::ffff:192.0.2.1|                |             
     |Suggested External Port|                |
     |                   3938|                |
     |<======================|                |
     |   (1)SIP REGISTER     |(2)SIP REGISTER |
     |======================>|===============>|
     |  (4) SIP 200 OK       | (3) SIP 200 OK |
     |<======================|<===============|
     |                       |                |

]]></artwork>
          </figure></t>

        <t><figure align="center" anchor="reg"
            title="Example of REGISTER messager">
            <artwork><![CDATA[ SIP Message:
  REGISTER sip:mysip.fr SIP/2.0
  Via: SIP/2.0/UDP 192.0.2.1:3938;branch=z9hG4bK1572043597
  From: <sip:client4@mysip.fr:5070>;tag=893886783
  To: <sip:client4@mysip.fr:5070>
  Call-ID: 1271173454
  CSeq: 2 REGISTER
  Contact: <sip:client4@192.0.2.1:3938;line=b3433a7df33282d>
      Authorization: Digest username="client4", realm="asterisk",
      nonce="09f75e47", uri="sip:mysip.fr",
      response="826fcff4c6e84ee45fbfa52c351e6316", algorithm=MD5
  Max-Forwards: 70
  User-Agent: Linphone/3.4.0 (eXosip2/unknown)
  Expires: 3600]]></artwork>
          </figure></t>

        <t>The external IP address and port(s) instantiated for media streams,
        are used to build the SDP offer/answer. In particular, the "c" line
        and "m" lines.</t>
      </section>

      <section title="Learn and Set the Lifetime of Mapping Entries">
        <t>PCP allows to discover and to set the lifetime of mapping
        instantiated in intermediate middleboxes.</t>

        <t>The discovery of the lifetime of a mapping avoids overloading the
        network and SIP servers with frequent messages. This is in particular
        important for cellular devices. According to <xref
        target="Power"></xref>, the consumption of a cellular device with a
        keep-alive interval equal to 20 seconds (that is the default value in
        <xref target="RFC3948"></xref> for example) is 29 mA (2G)/34 mA (3G).
        This consumption is reduced to 16 mA (2G)/24 mA (3G) when the interval
        is increased to 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval
        is equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if the interval
        is equal to 180 seconds. When no keep-alive is issued, the consumption
        would be 5.2 mA (2G)/6.1 mA (3G). The impact of keepalive messages
        would be more severe if multiple applications are issuing those
        messages (e.g., SIP, IPsec, etc.).</t>
      </section>

      <section title="Allow Unidirectional Media Flows">
        <t>As a consequence of instantiating mappings for media/session flows,
        incoming packets can be successfully forwarded to the appropriate SIP
        UA. Particularly, unidirectional media flows (e.g., announcement
        server) will be forwarded accordingly.</t>
      </section>

      <section title="Preserve Port Parity">
        <t>For deployments relying on classic RTP/RTCP odd/even port numbers
        assignment scheme, PORT_SET option <xref
        target="I-D.ietf-pcp-port-set"></xref> can be used by a SIP UA to
        request port parity be preserved by the PCP server.</t>

        <t>An example is depicted in <xref target="ex2"></xref>.</t>
      </section>

      <section title="Preserve Port Contiguity">
        <t>For deployments assuming RTCP port number can be deduced from the
        RTP port number, PORT_SET option <xref
        target="I-D.ietf-pcp-port-set"></xref> can be used by a SIP UA to
        retrieve a pair of contiguous ports from the PCP server.</t>

        <t>A flow example is shown in <xref target="ex2"></xref>.</t>

        <t><figure align="center" anchor="ex2"
            title="Retrieve a pair of ports that preserves port parity">
            <artwork><![CDATA[+---------+              +-------+       +------------+
| SIP UA  |              | NAT   |       |  IPv4 SIP  |
|   PCP   |              |+ PCP  |       |Proxy Server|
| Client  |              |Server |       | "Mysip.fr" | 
+---------+              +-------+       +------------+     
     |     (a) PCP MAP       |                |
     |Suggested External IP@ |                |   
     |       ::ffff:192.0.2.1|                |    
     |Suggested External Port|                |   
     |                   6000|                |   
     |        PORT_SET:      |                |
     |  "P" bit set to 1     |                |
     |   Port Set Size=2     |                |
     |======================>|                |             
     |     (b) PCP MAP       |                |
     |Assigned External IP@  |                |   
     |       ::ffff:192.0.2.1|                |    
     |Assigned External Port |                |   
     |                   7076|                |   
     |        PORT_SET:      |                |
     |  "P" bit set to 1     |                |
     |   Port Set Size=2     |                |
     |<======================|                |
     |                       |                |

]]></artwork>
          </figure></t>
      </section>

      <section title="Learn PREFIX64">
        <t>If the SIP UA is located behind a NAT64 device <xref
        target="RFC6146"></xref>, the option defined in <xref
        target="RFC7225"></xref> can be used to retrieve the PREFIX64 used by
        that NAT64 device.</t>

        <t>The retrieved prefix will be used to locally build an
        IPv6-converted IPv4 address (<xref target="RFC6052"></xref>)
        corresponding to the IPv4 address included in the SDP message received
        from a remote IPv4-enabled SIP UA; the SDP message can be an SDP offer
        or an answer.</t>

        <t><figure align="center" anchor="nat64"
            title="Example of IPv6 to IPv4 SIP-Initiated Session">
            <artwork><![CDATA[   +---------+              +-----+       +------------+     +---------+
   |IPv6-only|              |NAT64|       |  IPv4 SIP  |     |IPv4-only|
   | SIP UA  |              |     |       |Proxy Server|     | SIP UA  |
   +---------+              +-----+       +------------+     +---------+
       | (a) PCP MAP Request   |                |                 |
       |Suggested External IP@ |                |                 |
       |       ::ffff:192.0.2.1|                |                 |
       |Suggested External Port|                |                 |
       |                   6000|                |                 |
       |        PORT_SET       |                |                 |
       |        PREFIX64       |                |                 |
       |======================>|                |                 |
       | (b) PCP MAP Response  |                |                 |
       |Assigned External IP@  |                |                 |
       |       ::ffff:192.0.2.1|                |                 |
       |Assigned External Port |                |                 |
       |                   7076|                |                 |
       |        PORT_SET       |                |                 |
       |        PREFIX64:      |                |                 |
       |     2001:db8:122::/48 |                |                 |
       |<======================|                |                 |
       |  (1) SIP INVITE       | (2) SIP INVITE |  (3) SIP INVITE |
       |======================>|===============>|================>|
       |   (6) SIP 200 OK      | (5) SIP 200 OK |  (4) SIP 200 OK |
       |<======================|<===============|<================|
       |     (7) SIP ACK       |  (8) SIP ACK   |    (9) SIP ACK  |
       |======================>|===============>|================>|
       |                       |                |                 |
       |src port:     dst port:|src port:                dst port:|
       |6000             port_B|7076                        port_B|
       |<======IPv6 RTP=======>|<============IPv4 RTP============>|
       |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
       |src port:     dst port:|src port:                dst port:|
       |6001           port_B+1|7077                      port_B+1|
       |                       |                                  |

]]></artwork>
          </figure><xref target="invite"></xref> shows the content of the SIP
        INVITE message sent by the IPv6-only SIP UA. This message uses the
        retrieved external IP address and external port numbers in SIP headers
        and SDP lines. This message is translated by the NAT64 without
        altering the SIP/SDP content.</t>

        <t><figure align="center" anchor="invite"
            title="Content of the INVITE message">
            <artwork><![CDATA[  INVITE sip:13@mysip.fr:5070 SIP/2.0
  Via: SIP/2.0/UDP 192.0.2.1:56252;branch=z9hG4bK1876803184
  From: <sip:client4@mysip.fr:5070>;tag=631384602
  To: <sip:13@mysip.fr:5070> Call-ID: 1377792765 CSeq: 21 INVITE
  Contact: <sip:client4@192.0.2.1:56252>
  Authorization: Digest username="client4", realm="asterisk",
   nonce="3358d80b", uri="sip:13@mysip.fr:5070",
   response="41442e94f6610e6f383a355a1bdf3e48", algorithm=MD5
  Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS,
   BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
  Max-Forwards: 70
  User-Agent: Linphone/3.4.0 (eXosip2/unknown)
  Subject: Phone call Content-Length: 443

  v=0
  o=client4 2487 2487 IN IP4 192.0.2.1
  s=Talk c=IN IP4 192.0.2.1
  b=AS:256
  t=0 0
  m=audio 7076 RTP/AVP 111 110 3 101
  a=rtpmap:111 speex/16000
  a=fmtp:111 vbr=on a=rtpmap:110 speex/8000
  a=fmtp:110 vbr=on a=rtpmap:3 GSM/8000
  a=rtpmap:101 telephone-event/8000
  a=fmtp:101 0-11
  m=video 9076 RTP/AVP 102 99
  a=rtpmap:102 H264/90000
  a=fmtp:102 profile-level-id=428014
  a=rtpmap:99 MP4V-ES/90000
  a=fmtp:99
  profile-level-id=3
]]></artwork>
          </figure></t>
      </section>

      <section title="Compliant with &quot;a=rtcp&quot; Attribute">
        <t>The base PCP specification can be used to retrieve the port number
        to be singled if "a=rtcp" attribute is in use <xref
        target="RFC3550"></xref>.</t>
      </section>

      <section title="DSCP Marking Policy">
        <t>PCP can be used to discover the DSCP value to be used when sending
        real-time flows or to create a mapping that matches a DSCP marking.
        This can be achieved using the DSCP option defined in <xref
        target="I-D.boucadair-pcp-extensions"></xref>. DSCP setting value is
        configured by the network and not the SIP UA.</t>

        <t>This feature can be used as an input for DSCP marking in some
        deployments such as <xref
        target="I-D.ietf-tsvwg-rtcweb-qos"></xref>.</t>
      </section>
    </section>

    <section title="Avoid Crossing CGNs">
      <t></t>

      <section title="Avoid NAT64">
        <t>Because an IPv6-only SIP UA is not aware of the connectivity
        capabilities of the remote UA, the IPv6-only SIP UA uses the ALTC
        attribute <xref target="RFC6947"></xref> to signal the assigned IPv6
        address and the IPv4 address learned via PCP.</t>

        <t>If the remote SIP UA is IPv6-enabled, IPv6 transfer capabilities
        will be used to place the session. If the remote SIP UA is IPv4-only,
        IPv4 transfer capabilities will be used. NAT64 devices will be crossed
        only if the remote UA is IPv4-only.</t>

        <t><xref target="altc"></xref> provides an except of a SIP INVITE
        message that encloses both the local IPv6 address and the IPv4
        address/port number assigned by a NAT64 device.</t>

        <t><figure align="center" anchor="altc"
            title="Content of the INVITE message (with ALTC Attribute)">
            <artwork align="center"><![CDATA[INVITE sip:13@mysip.fr:5070 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:35011;branch=z9hG4bK702695557
From: <sip:client4@mysip.fr:5070>;tag=641336337
To: <sip:13@mysip.fr:5070>
Call-ID: 1532307201
CSeq: 20 INVITE
Contact: <sip:client4@192.0.2.1:35011>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY,
       MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Subject: Phone call
Content-Length:   538

v=0
o=client4 3867 3867 IN IP4 192.0.2.1
s=Talk
c=IN IP4 192.0.2.1
b=AS:256
t=0 0
m=audio 7056 RTP/AVP 111 110 3 101
a=altc:1 IP6 2001:db8:1f94:3000:6c73:ea54:cef:2730 45678
a=altc:2 IP4 192.0.2.1 7056

]]></artwork>
          </figure></t>
      </section>

      <section title="Avoid Crossing DS-Lite AFTR">
        <t>SIP UAs co-located with the B4 <xref target="RFC6333"></xref> or
        located behind the CPE can behave as dual-stack UAs:<list
            style="symbols">
            <t>Native IPv6 address is assigned locally.</t>

            <t>The external IPv4 address and port is retrieved using PCP.</t>
          </list>To avoid unnecessary invocation of AFTR resources, ALTC
        attribute is used to signal both IPv4 and IPv6 addresses. If the
        remote SIP UA is IPv6-enabled, IPv6 transfer capabilities will be used
        to place the session (i.e., the flows will avoid crossing the DS-Lite
        AFTR device). If the remote SIP UA is IPv4-only, IPv4 transfer
        capabilities will be used. AFTR devices will be crossed only if the
        remote UA is IPv4-only.</t>
      </section>
    </section>

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

      <t>Security considerations related to the discovery of PREFIX64 are
      discussed in Section 7 of <xref target="RFC7225"></xref> and those
      related to retrieving a set of ports are discussed in Section 7 of <xref
      target="I-D.ietf-pcp-port-set"></xref>.</t>

      <t>An attacker that wants to intercept media flows, without requiring
      intercepting SIP signalling message, can insert a fake PCP server that
      will influence the content of SIP messages so that an illegitimate node
      is inserted in the media path. Such behavior is not desirable. Means to
      prevent the PCP client from discovering illegitimate PCP servers must be
      enforced. Within the context of this document, the network on which the
      PCP messages are to be sent is fully trusted. For example, access
      control lists (ACLs) can be installed on the PCP client, PCP server, and
      the network between them, so those ACLs allow only communications from a
      trusted PCP client to the PCP server.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks for T. Reddy and S. Kiesel for their review.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-pcp-port-set'?>

      <?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?>

      <?rfc include='reference.I-D.boucadair-pcp-extensions'?>

      <?rfc include='reference.I-D.penno-rtcweb-pcp'?>

      <?rfc include='reference.I-D.boucadair-pcp-nat64-experiments'?>

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

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

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

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

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

      <reference anchor="Power"
                 target="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4212635">
        <front>
          <title>Energy Consumption of Always-On Applications in WCDMA
          Networks</title>

          <author fullname="Henry Haverinen" initials="H." surname="Haverinen">
            <organization>Nokia Enterprise Solutions</organization>
          </author>

          <author fullname="Jonne Siren" initials="J." surname="Siren">
            <organization>Nokia Enterprise Solutions</organization>
          </author>

          <author fullname="Pasi Eronen" initials="P." surname="Eronen">
            <organization>Nokia Research Center</organization>
          </author>

          <date day="" month="April" year="2007" />
        </front>
      </reference>

      <reference anchor="WT-317"
                 target="https://www.broadband-forum.org/technical/technicalwip.php">
        <front>
          <title>Network Enhanced Residential Gateway (NERG)</title>

          <author fullname="" initials="" surname="">
            <organization>Broadband Forum</organization>
          </author>

          <date day="" month="" year="2015" />
        </front>
      </reference>

      <reference anchor="ICEFailure"
                 target="http://telemetry.mozilla.org/#filter=beta%2F36%2FWEBRTC_ICE_SUCCESS_RATE%2Fsaved_session%2FFirefox&amp;aggregates=multiselect-all!Submissions&amp;evoOver=Builds&amp;locked=true&amp;sanitize=true&amp;renderhistogram=Graph">
        <front>
          <title>WEBRTC_ICE_SUCCESS_RATE</title>

          <author fullname="" initials="" surname="">
            <organization>Telemetry Dashboard</organization>
          </author>

          <date day="" month="March" year="2015" />
        </front>
      </reference>

      <!---->
    </references>
  </back>
</rfc>
