DECLARATION
`
`I, Alexa Morris, based on my personal knowledge and information, hereby declare as follows:
`
`1.
`
`I am Executive Director of the Internet Engineering Task Force (“IETF”) and have held
`
`ON
`
`~)
`
`Oo6
`
`this position since January 1, 2008.
`
`~
`
`Among my responsibilities as Executive Director, I act as the custodian of Internet-
`
`Drafts for the LETF and recordsrelating to Internet-Drafts. I am familiar with the record
`
`keeping practices relating to Internet-Drafts, including the creation and maintenance of
`
`such records.
`
`U2
`
`I make this declaration based on my personal knowledge and information contained in
`
`the business records of the IETF, or confirmation with other responsible IETF personnel
`
`with such knowledge.
`
`-
`
`Since 1998, it has been the regular practice of the IETF to publish Internet-Drafts and
`
`make them available to the public on its website at www.ietf.org (the IETF website).
`
`The IETF maintains copies of Internet-Drafts in the ordinary course of its regularly
`
`conducted activities.
`
`ys
`
`Any Internet-Draft published on the IETF website was reasonably accessible to the
`
`public and was disseminated or otherwise available to the extent that persons interested
`
`and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have located it.
`
`In particular, the Internet-Drafts were indexed and searchable on the
`
`IETF website.
`
`a
`
`Internet-Drafts are posted to an IETF online directory. When an Internet-Draft is
`
`published, an announcement of its publication that describes the Internet-Draft
`
`is
`
`disseminated. Typically,
`
`that dated announcement is made within 24 hours of the
`
`4832-8075-5826.1
`
`Apple Inc.
`Ex. 1015 - Page 1
`
`Apple Inc.
`Ex. 1015 - Page 1
`
`

`

`publication of the Internet-Draft. The announcementis kept in the IETF email archive
`
`and the date is affixed automatically.
`
`. The records of posting the Internet-Drafts in the IETF online repository are kept in the
`
`course of the IETF’s regularly conducted activity and ordinary course of business. The
`
`records are made pursuant to established procedures and are relied upon by the IETF in
`
`the performanceofits functions.
`
`.
`
`It
`
`is the regular practice of the IETF to make and keep the records in the online
`
`repository.
`
`. Exhibit 1 is a true and correct copy of draft-rosenberg-sipping-ice-00, titled “Interactive
`
`Connectivity Establishment (ICE): A Methodology for Network Address Translator
`
`(NAT) Traversal for the Session Initiation Protocol (SIP).” The Internet-Draft shows
`
`that an announcementofits publication was made on February 24, 2003.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury under the laws of the United States of America that the foregoing is true and correct and
`
`that the foregoing is based upon personal knowledge and information andis believed to betrue.
`
`Date: pr! D?/% By:
`
`Alexa Morris
`
`oo—OnWN&wwNo
`
`\o
`
`bo i)
`
`i) wo
`
`bt &
`
`nN AY
`
`DECLARATION OF ALEXA MORRIS
`
`Apple Inc.
`Ex. 1015 - Page 2
`
`Apple Inc.
`Ex. 1015 - Page 2
`
`

`

`CALIFDSRS ALL-PURPOSEae
`
`CIVIL CODEa 1189
`
`
`
`A notary public or other officer completing this certificate verifies only the identity of the individual who signed the
`documentto whichthiscertificate is attached, and not the truthfulness, accuracy, orvalidity of that document.
`
`State of California
`
`Date
`
`County of
`SB nta Chava
`On Sepf+ - 144 ZAR before me, Sharon | Chay
`
`personally appeared
`[ | [ELA Maras
`Name(s) of Signer(s)
`
`
`
`
`who proved to me on the basis of satisfactory evidence to be the person i} whose name(s) is/are—
`subscribed to the within instrument and Feseesto me that~he/éhe
`xecuted the same in
`
`histiertheirauthorized capacitytes)-and thatif er;epeiraeneieay the instrumentthe person(s”
`
`or the’entity upon behalf of which the person
`
`a
`
`cted; executedthe in
`
`trument.
`
`| certify under PENALTY OF PERJURY underthe laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`WITNESS my hand and official seal.
`
`Notary Public - California 3 SSS
`
`
`SHARONJ. CHAI
`
`wey)
`3
`
`;
`
`Santa Clara County
`Commission # 2224197
`MyComm.ExpiresJan3,2022
`
`Z
`r
`p
`
`Place Notary Seal Above
` OPTIONAL
`Thoughthis section is optional, completing this information can deteralteration of the documentor
`fraudulent reattachment of this form to an unintended document.
`
`
`Number of Pages: ¥-
`
`Description of Attached Document
`{uae eV)
`Title or Type of Document:
`Document Date:
`64-1
`Signer(s) Other Than Named Above:
`Capacity(ies) Claimed by Signer(s)
`Signer’s Name: MervA
`Lani 4%
`
`[] Corporate Officer — Title(s):
`
`
`
`(I General
`[| Partner — [) Limited
`
`
`_] Attorney in Fact
`Individual
`
`[] Guardian or Conservator
`Trustee
`L) Other:
`
`UTA
`
`
`
`
`
`
`Signer Is Representing:
`SignerIseerKetea
`
`
`Signer’s Name:
`
`
`
`Corporate Officer — Title(s):
`
`
`
`
`
`J Partner — (J Limited
`General
`
`|_| Attorney in Fact
`CJ Individual
`
`J] Guardian or Conservator
`_] Trustee
`
`[J Other:
`
`Apple Inc.
`Ex. 1015 - Page 3
`
`
`Apple Inc.
`Ex. 1015 - Page 3
`
`

`

`SIPPING J. Rosenberg
`Internet-Draft dynamicsoft
`Expires: August 25, 2003 February 24, 2003
`
` Interactive Connectivity Establishment (ICE): A Methodology for
` Network Address Translator (NAT) Traversal for the Session Initiation
` Protocol (SIP)
` draft-rosenberg-sipping-ice-00
`
`Status of this Memo
`
` This document is an Internet-Draft and is in full conformance with
` all provisions of Section 10 of RFC2026.
`
` Internet-Drafts are working documents of the Internet Engineering
` Task Force (IETF), its areas, and its working groups. Note that other
` groups may also distribute working documents as Internet-Drafts.
`
` 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."
`
` The list of current Internet-Drafts can be accessed at http://
` www.ietf.org/ietf/1id-abstracts.txt.
`
` The list of Internet-Draft Shadow Directories can be accessed at
` http://www.ietf.org/shadow.html.
`
` This Internet-Draft will expire on August 25, 2003.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2003). All Rights Reserved.
`
`Abstract
`
` This document describes a methodology for Network Address Translator
` (NAT) traversal for the Session Initiation Protocol (SIP). This
` methodology is called Interactive Connectivity Establishment (ICE).
` ICE is not a new protocol, but rather makes use of existing
` protocols, such as Simple Traversal of UDP Through NAT (STUN),
` Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP).
` ICE works through the mutual cooperation of both endpoints in a SIP
` dialog. By having the endpoints work together in NAT traversal, a
` number of important properties are obtained. ICE always works,
` independent of the types or number of NATs. It always represents the
` cheapest solution for a carrier. It always results in the minimum
`
`Rosenberg Expires August 25, 2003 [Page 1]
`
`Apple Inc.
`Ex. 1015 - Page 4
`
`

`

`
`Internet-Draft ICE February 2003
`
` voice latency. It can be done with no increase in call setup delays.
` It is far less brittle than STUN. ICE also facilitates the transition
` of the Internet from IPv4 to IPv6, supporting calls between
` dual-stack and v6 clients behind a 4to6 NAT. Preconditions can be
` used in conjunction with ICE, to guarantee that the phone never rings
` unless the users will both hear and see each other when they pick up.
`
`Table of Contents
`
` 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
` 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 4
` 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
` 4. Core ICE Algorithm . . . . . . . . . . . . . . . . . . . . . 7
` 5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . 8
` 5.1 Gathering Transport Addresses . . . . . . . . . . . . . . . 8
` 5.2 Enabling STUN on Each Transport Address . . . . . . . . . . 8
` 5.3 Prioritizing the Transport Addresses . . . . . . . . . . . . 10
` 5.4 Constructing the Offer . . . . . . . . . . . . . . . . . . . 10
` 5.5 Answerer Processing - Connectivity Checks and Gathering . . 11
` 5.6 Generating the Answer . . . . . . . . . . . . . . . . . . . 13
` 5.7 Offerer Processing of the Answer . . . . . . . . . . . . . . 14
` 5.8 Additional ICE Cycles . . . . . . . . . . . . . . . . . . . 14
` 6. Running STUN on a Derived Transport Addresses . . . . . . . 15
` 6.1 STUN on a TURN Derived Transport Address . . . . . . . . . . 15
` 6.2 STUN on a STUN Derived Transport Address . . . . . . . . . . 16
` 7. SDP Extensions for STUN . . . . . . . . . . . . . . . . . . 18
` 7.1 The stun Attribute . . . . . . . . . . . . . . . . . . . . . 18
` 7.2 The derived Attribute . . . . . . . . . . . . . . . . . . . 18
` 8. Connectivity Preconditions . . . . . . . . . . . . . . . . . 20
` 9. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 22
` 9.1 Public Internet . . . . . . . . . . . . . . . . . . . . . . 22
` 9.2 Disconnected Enterprise . . . . . . . . . . . . . . . . . . 23
` 10. Security Considerations . . . . . . . . . . . . . . . . . . 27
` 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
` 11.1 Precondition Type . . . . . . . . . . . . . . . . . . . . . 28
` 11.2 SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 28
` 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 29
` 12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 29
` 12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 29
` 12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . . 30
` 12.4 Requirements for a Long Term Solution . . . . . . . . . . . 31
` 12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 31
` Informative References . . . . . . . . . . . . . . . . . . . 32
` Author’s Address . . . . . . . . . . . . . . . . . . . . . . 33
` Intellectual Property and Copyright Statements . . . . . . . 34
`
`Rosenberg Expires August 25, 2003 [Page 2]
`
`Apple Inc.
`Ex. 1015 - Page 5
`
`

`

`
`Internet-Draft ICE February 2003
`
`1. Introduction
`
` The subject of NAT traversal for SIP has received a profound amount
` of attention. SIP extensions have been defined for routing responses
` [11] through NAT, and for routing requests from a public network to a
` private one through persistent connections [12].
`
` However, far more troubling is the traversal of SIP’s media sessions
` through NAT. Numerous solutions have been proposed for that. These
` include Application Layer Gateways (ALGs), the Middlebox Control
` Protocol [2], Simple Traversal of UDP through NAT (STUN) [13],
` Traversal Using Relay NAT" [14], Realm Specific IP [3][4], Topology
` Insensitive Service Traversal (TIST) [15], symmetric RTP [16], along
` with protocol extensions needed to make them work, such as [17]. The
` sum total is so complex, that an extensive scenarios document [18]
` has been written. This document outlines the various network
` situations, and analyzes the various solutions in each.
` Unsurprisingly, each situation has a specific ideal solution.
`
` However, the result is a system which is incredibly complex and very
` brittle. What is needed is a single solution which is flexible enough
` to work well in all situations.
`
` Our proposal for such a solution is called Interactive Connectivity
` Establishment, or ICE. ICE makes use of many of the protocols above,
` but uses them in a specific methodology which avoids many of the
` pitfalls of using any one alone. ICE is not a new protocol, and does
` not require extensions from STUN, TURN or RSIP. However, it does
` require some additional SDP attributes, which are discussed below.
`
`Rosenberg Expires August 25, 2003 [Page 3]
`
`Apple Inc.
`Ex. 1015 - Page 6
`
`

`

`
`Internet-Draft ICE February 2003
`
`2. Overview of ICE
`
` ICE makes the fundamental assumption that clients exist in a network
` of segmented connectivity. This segmentation is the result of a
` number of addressing realms in which a client can simultaneously be
` connected. We use "realms" here in the broadest sense. A realm is
` defined purely by connectivity. Two clients are in the same realm if,
` when they exchange the addresses each has in that realm, they are
` able to send packets to each other. This includes IPv6 and IPv4
` realms, which actually use different address spaces, in addition to
` private networks connected to the public Internet through NAT.
`
` The key assumption in ICE is that a client cannot know, apriori,
` whether the peer it wishes to communicate with is connected to one or
` all of the address realms it is in. Therefore, in order to
` communicate, it has to try them all, and choose the best one that
` works.
`
` Before a UA makes a call, it obtains as many IP address and port
` combinations in as many address realsm as it can. These adresses all
` represent potential points at which the UA will receive a specific
` media stream. Any protocol that provides a client with an IP address
` and port on which it can receive traffic can be used. These include
` STUN, TURN, RSIP, and even a VPN. The client also uses any local
` interface addresses. A dual-stack v4/v6 client will obtain both a v6
` and a v4 address/port. The only requirement is that, across all of
` these addresses, the client can be certain that at least one of them
` will work for any peer. This is easily guaranteed by using TURN,
` RSIP, MIDCOM or a VPN from a server on the public Internet to obtain
` one of the addresses.
`
` The UAC then makes a STUN server available on each of the address/
` port combinations it has obtained. This STUN server is running
` locally, on the UA.
`
` All of these addresses are placed into the SDP offer [5] sent by the
` UAC. Each of them is represented by a separate m-line. The SDP ALT
` grouping [19] is used to indicate that each of these m-lines
` represents an alternate point of connectivity for the media stream.
` They are ordered in terms of preference. Local IPv6 addresses always
` have the highest preference, followed by local IPv4 addresses,
` followed by STUN-allocated addresses, followed last by addresses
` allocated through protocols using relays, such as TURN and VPN. SDP
` attributes are also used to convey the STUN username and password
` which are required to gain access to the STUN server on each address/
` port combination.
`
` This offer is sent to the called party. ICE also assumes that SIP
`
`Rosenberg Expires August 25, 2003 [Page 4]
`
`Apple Inc.
`Ex. 1015 - Page 7
`
`

`

`
`Internet-Draft ICE February 2003
`
` itself can provide global connectivity across address realms. Indeed,
` the point of the SIP URI is to act as a globally useful identifier
` for reaching a user wherever they are.
`
` Once the offer arrives at the UAS, it sends STUN requests to each
` alternate address/port in the SDP offer, similar to the intra-realm
` STUN mechanism [20] proposed previously. These STUN requests include
` the username and password obtained from the SDP. None of the flags
` are used. The STUN requests serve two purposes. The first is to check
` for connectivity. If a response is received, the UAS knows that it
` can reach the UAC at that address. The second purpose is to obtain
` more addresses at which the UAS can be contacted. If there were NATs
` between the UAS and UAC, the UAS may discover another address through
` the STUN responses. In its answer, the UAS includes all addresses
` that it can unilaterally determine (just as the UAC did), in addition
` to any that were discovered using the STUN messages to the UAC.
`
` When the answer arrives at the UAC, it performs a similar operation.
` Using STUN, it checks connectivity to each of the addresses in the
` answer. Through the STUN responses, it may learn of additional
` addresses that it can use to receive media. It can therefore generate
` a re-INVITE or UPDATE [6] request to pass this address to the callee.
` Generally, at the end of the first exchange, both sides will have
` discovered one of more addresses which they are capable of
` successfully sending to. Each side uses the most preferred address
` amongst the ones which worked.
`
`Rosenberg Expires August 25, 2003 [Page 5]
`
`Apple Inc.
`Ex. 1015 - Page 8
`
`

`

`
`Internet-Draft ICE February 2003
`
`3. Terminology
`
` Several new terms are introduced in this specification:
`
` Transport Address: The combination of an IP address and port.
`
` Local Transport Address: A local transport address is transport
` address that has been allocated from the operating system on the
` host. This includes transport addresses obtained through VPNs, and
` also transport addresses obtained through RSIP (which lives at the
` operating system level). Transport addresses are typically
` obtained by binding to an interface.
`
` Derived Transport Address: A derived transport address is a
` transport address which is associated with, but different from, a
` local transport address. The derived transport address is
` associated with the local transport address in that packets sent
` to the derived transport address are received on the socket bound
` to that local transport address. Derived addresses are obtained
` using protocols like STUN and TURN, and more generally, any UNSAF
` protocol [8].
`
` Peer Derived Transport Address: A peer derived transport address
` is a derived transport address learned from a STUN server
` advertised by a peer in a media session.
`
` TURN Derived Transport Address: A derived transport address
` obtained from a TURN server.
`
` STUN Derived Transport Address: A derived transport address
` obtained from a STUN server that has been provisioned into the UA.
` This, by definition, excludes Peer Derived Transport Addresses.
`
`Rosenberg Expires August 25, 2003 [Page 6]
`
`Apple Inc.
`Ex. 1015 - Page 9
`
`

`

`
`Internet-Draft ICE February 2003
`
`4. Core ICE Algorithm
`
` At its core, the ICE algorithm is an iterative process in which two
` cooperating entities, A and B, exchange addresses with each other in
` an attempt to connect. One side (say A) starts, collecting all of the
` addresses it can find. It sends those to B. B also collects all of
` the addresses it can find, including those obtained by sending
` address-fixing requests (such as STUN requests) to A itself. Those
` are passed to A. B also checks connectivity to the addresses provided
` by A. When A gets the set of addresses, it performs connectivity
` checks, and attempts to obtain further addresses based on the
` information sent by B. If A learns more addresses, it sends these to
` B, which checks connectivity to those addresses. This process
` iterates back and forth until both sides have obtain all the
` addresses which can be obtained. At least one address past in each
` direction should work.
`
`Rosenberg Expires August 25, 2003 [Page 7]
`
`Apple Inc.
`Ex. 1015 - Page 10
`
`

`

`
`Internet-Draft ICE February 2003
`
`5. Detailed ICE Algorithm
`
` This section describes the detailed processing needed for ICE.
`
`5.1 Gathering Transport Addresses
`
` The offerer begins the process by gathering transport addresses.
` There are two types of addresses it can gather - local transport
` addresses, and derived transport addresses. Local transport addresses
` are obtained by binding to an ephemeral port on an interface
` (physical or virtual) on the host. A multi-homed host SHOULD attempt
` to bind on all interfaces for all media streams it wishes to receive.
` For media streams carried using the Real Time Transport Protocol
` (RTP) [10], the offerer will need to bind to an ephemeral port for
` both RTP and RTCP.
`
` The result will be a set of local transport addresses. The offerer
` may also have access to servers that provide unilateral self-address
` fixing (UNSAF) [8]. Examples of such protocols include STUN, TURN,
` and TEREDO [21]. For each of these protocols, the offerer may have
` access to a multiplicity of servers. For example, a user connected to
` a natted cable access network might have access to a STUN server in
` the private cable network and in the public Internet. For each local
` transport address, the offerer SHOULD address-fix against every
` server for each protocol it supports. The result of this will be a
` set of derived transport addresses, with each derived address
` associated with the local transport address it is derived from.
`
` ICE works better the more options exist for connectivity. However, in
` order to communicate with the peer, at least one of the offered
` addresses has to be guaranteed to work with any peer that might be
` called. This generally requires that one of the derived addresses be
` obtained from a relay service (such as TURN or TEREDO) that exist
` within the public Internet.
`
`5.2 Enabling STUN on Each Transport Address
`
` Once the offerer has obtained a set of transport addresses, it starts
` a STUN server on each local transport address (including ones used
` for RTCP). This, by definition, means that the STUN service will be
` reached for requests sent to the derived addresses.
`
` However, the client does not need to provide STUN service on any
` other IP address or port, unlike the normal STUN usage as described
` in [13]. The need to run the service on multiple ports is to support
` the change flags. However, those flags are not needed with ICE, and
` the server SHOULD reject any requests with these flags set.
`
`Rosenberg Expires August 25, 2003 [Page 8]
`
`Apple Inc.
`Ex. 1015 - Page 11
`
`

`

`
`Internet-Draft ICE February 2003
`
` Furthermore, there is no need to support TLS or to be prepared to
` receive SharedSecret request messages. Those messages are used to
` obtain shared secrets to be used with BindingRequests. However, with
` ICE, usernames and passwords are exchanged in SIP itself.
`
` It is important to note that the transport address being used by the
` STUN server will also need to support the media stream which is to be
` sent to that transport address. This will require the offerer to
` disambiguate STUN messages from messages for the underlying media
` stream protocol. In the case of RTP/RTCP, this disambiguation is
` easy. RTP and RTCP packets start with the bits 0b10 (v=2). The first
` two bits in STUN are always 0b00. Disambiguating STUN with other
` media stream protocols may be more complicated. However, it is
` guaranteed to always be possible by selecting an appropriately random
` username (see below).
`
` The need to run STUN on the same transport address as the media
` stream represents the "ugliest" piece of ICE. However, it is an
` essential part of the story. By sending STUN requests to the very
` same place media is sent, any bindings learned through STUN will be
` useful even when communicating through symmetric NATs. This results
` in a substantial increase in the scope of applicability of STUN, in
` terms of cases where it can provide connectivity. In that sense, the
` usage of STUN here is radically different than the usage models
` outlined in [13], where STUN is generally useless for dealing with
` symmetric NAT.
`
` For each local transport address where a STUN server is running, the
` client MUST choose a username and password. The username MUST be
` globally unique, so that no other host will select a username with
` the same value. This username and password will be passed to the
` answerer in the SDP. They are used by the answerer to authenticate
` the STUN requests to the server.
`
` The gloal uniqueness requirement stems from the lack of uniquenes
` afforded by IP addresses. Consider user agents A, B, and C. A and B
` are within private enterprise 1, which is using 10.0.0.0/8. C is
` within private enterprise 2, which is also using 10.0.0.0/8. As it
` turns out, B and C both have IP address 10.0.1.1. A makes a call to
` C. C, in its answer, provides A with its transport addresses. In this
` case, thats 10.0.1.1:8866 and 8877. As it turns out, B is on a call
` at that same time, and is also using 10.0.1.1:8866 and 8877. This
` means that B has a STUN server running on those ports, just as C
` does. A will send a STUN request to 10.0.1.1:8866 and 8877. However,
` these do not go to C as expected. Instead, they go to B. If B just
` replied to them, A would believe it has connectivity to C, when it
` fact it has connectivity to a completely different user, B. To fix
` this, the STUN username takes on the role of a unique identifier. C
`
`Rosenberg Expires August 25, 2003 [Page 9]
`
`Apple Inc.
`Ex. 1015 - Page 12
`
`

`

`
`Internet-Draft ICE February 2003
`
` provides A with a unique username. A uses this username in its STUN
` query to 10.0.1.1:8866. This STUN query arrives at B. However, the
` username is unknown to B, and so the request is rejected. A treats
` the rejected STUN request as if there were no connectivity to C
` (which is actually true). Therefore, the error is avoided.
`
` Once the STUN server is started, it MUST run until the first media
` packet arrives on that address. Once that occurs, the agent MAY
` terminate the server. It is still possible that a late or lose STUN
` message will show up, but these will generally fail any media stream
` validity checks and be discarded (STUN packets always fail the RTP
` validity checks).
`
` While the server is running, it MUST act as a normal STUN server, but
` MUST only accept STUN requests from clients that authenticate using
` the username and password handed out for the dialog.
`
`5.3 Prioritizing the Transport Addresses
`
` With the STUN servers starting, the next step is to prioritize the
` transport addresses. This priority reflects the desire that the UA
` has to receive media on that address, and is assigned as a value from
` 0 to 1 (1 being most preferred). Although any prioritization is
` possible, it is RECOMMENDED that the prioritization be based on the
` number of intermediaries that will be traversed. The fewer
` intermediaries, the higher the priority. As a result of this, local
` IPv6 transport addresses obtained from physical interfaces have
` highest priority (it is RECOMMENDED that 1.0 be used). Next are local
` IPv4 transport addresses obtained from physical interfaces (it is
` RECOMMENDED that 0.8 be used). Next are STUN derived transport
` addresses (it is RECOMMENDED that 0.6 be used), followed by TURN,
` RSIP or TEREDO derived transport addresses (it is RECOMMENDED that
` 0.4 be used). Last up are local transport addresses obtained from VPN
` interfaces (it is RECOMMENDED that 0.2 be used).
`
`5.4 Constructing the Offer
`
` The next step is to construct the offer. For each media stream, the
` client encodes its available set of transport addresses as a series
` of m-lines. Each m-line conveys a single transport address (or, in
` the case of RTP, two transport addresses - one for RTP, and one for
` RTCP). If, in the case of RTP, the RTP and RTCP transport addresses
` do not follow the even/odd convention, the SDP for NAT [17]
` extensions can be used to convey them.
`
` Each m-line in a media stream is marked with a unique media stream
` identifier (MID) [9]. Furthermore, the Alternative Semantics for the
` SDP Grouping Framework [19] is used to indicate that all of those
`
`Rosenberg Expires August 25, 2003 [Page 10]
`
`Apple Inc.
`Ex. 1015 - Page 13
`
`

`

`
`Internet-Draft ICE February 2003
`
` m-lines are alternatives for that media stream. This is done using
` the ALT group attribute.
`
` Each m-line is also tagged with its q-value, as obtained from the
` processing of Section 5.3. This is done with a new proposed SDP
` attribute, "qvalue". The value of this attribute is a q-value, as
` defined in RFC 3261 [1].
`
` The q-value attribute belongs in the ALT specification. That
` specification provides an ordering of media streams based on the
` order their MIDs are listed in the ALT attribute. However, the
` actual absolute values of the preferences are needed for ICE to
` properly choose the optimal connectivity.
`
` Each m-line also includes the "stun" SDP attribute. This attribute,
` defined in Section 7, indicates that a STUN server is running on the
` transport addresses associated with that m-line, and conveys the
` username and password used to access that server. In the case of RTP,
` this means that STUN servers are running on both the RTP and RCP
` ports, independently of whether the RTCP port is equal to the RTP
` port plus one, or explicitly signaled using [17]. Note that the stun
` attribute is included for local transport addresses and derived
` transport addresses. In the case of derived transport addresses, the
` username and password is the same as that for the STUN server bound
` to the associated local transport address. Section 6 discusses
` running STUN servers on derived transport addresses, and demonstrates
` that it does the "right thing".
`
` Once the offer is constructed, it is sent.
`
`5.5 Answerer Processing - Connectivity Checks and Gathering
`
` Once the answerer receives the offer, it does several things in
` parallel. First, it performs the same processing described in Section
` 5.1. Specifically, for each group of m-lines in the offer that
` represents a distinct media stream, the answerer allocates a set of
` local transport addresses and the full set of derived transport
` addresses.
`
` Note that these addresses can be "pre-gathered" before the call is
` even received, so that a set is always "on-deck". This will avoid any
` increase in call setup times, at the expense of holding onto
` addresses which may not get used. Retaining these addresses may also
` require refresh traffic that consumes network bandwidth.
`
` While the unilateral derived addresses are being obtained, the
` answerer sends a STUN BindingRequest from each local transport
` address to each STUN server identified in the offer. This
`
`Rosenberg Expires August 25, 2003 [Page 11]
`
`Apple Inc.
`Ex. 1015 - Page 14
`
`

`

`
`Internet-Draft ICE February 2003
`
` BindingRequest MUST contain the USERNAME attribute, and the value of
` this attribute MUST equal the username from the stun attribute in the
` offer. The BindingRequest MUST contain a MESSAGE-INTEGRITY attribute,
` computed using the username and password from the stun attribute in
` the offer. The BindingRequest MUST NOT contain the CHANGE-REQUEST or
` RESPONSE-ADDRESS attribute.
`
` It is RECOMMENDED that these STUN requests be sent in parallel. The
` answerer MAY alert the user during this time. Generally, if the user
` is a human (and not an automata), the STUN transactions will have
` completed before the call is answered.
`
` If the STUN BindingRequest elicits a BindingResponse before the STUN
` transaction times out, the result is considered a success. For
` successful transactions, the answerer stores the offered transport
` address (which identifies both the STUN server and the place where
` media is sent), the local transport address from which the STUN
` request was sent, the MID from the offer, and the q-value from the
` offer. If the STUN transaction succeeds, the client knows for certain
` that the media can reach the destination as well. That is because the
` media traffic will be sent from the same transport address, to the
` same trasport address, as the STUN packet was.
`
` Once