Subject: [MMUSIC] Re: Minor comments on ICE-15

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2007 14:17:48 -0400

Thanks for the comments. Responses inline.

Philip Matthews wrote:

> Jonathan:
> 
> Below are some more comments on ICE-15. Most of them are minor  
> editorial comments.
> I have extracted text from ICE-15, and then put in comments marked  with 
> "PM:".
> 
> - Philip
> 
> 
> ----------------
> 
>    The basic idea behind ICE is as follows: each agent has a variety of
>    candidate TRANSPORT ADDRESSES (combination of IP address and  port) it
>    could use to communicate with the other agent.  These might include:
> 
>    o  A transport address on a directly attached network interface or
>       interfaces
> PM: s/or interfaces//  (since a given transport address can only be  on 
> one interface)
> 

done

> ----
> 
>    Next, the agent uses STUN to obtain additional candidates.  These
>    come in two flavors: translated addresses on the public side of a  NAT
>    (SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED
>    CANDIDATES).  The relationship of these candidates to the host
>    candidate is shown in Figure 2.  Both types of candidates are
> PM: s/in Figure 2/in Figure 2 (here the notation "X:x" means IP  address 
> X and port x)./
>    discovered using STUN.
> 

fixed.

> ----
> 
>    To find a server reflexive candidate, the agent sends a STUN Binding
>    Request, using the Binding Discovery Usage [12] from each host
>    candidate, to its STUN server.  It is assumed that the address of  the
>    STUN server is manually configured or learned in some unspecified
>    way.  It is RECOMMENDED that when an agent has a choice of STUN
>    servers (when, for example, they are learned through DNS records and
>    multiple results are returned), an agent uses a single STUN server
>    (based on its IP address) for all candidates for a particular
>    session.  This improves the performance of ICE.
> PM: First of all, I suggest NOT placing normative text in the  Overview 
> section.
> More fundamentally, there are topologies where one absolutely wants  to use
> multiple STUN servers. After all, this is the main point of the draft  
> that you
> co-authored with Dan Wing on discovering STUN servers.

THis text got stuck in the wrong place and belongs in the section on 
server reflexive canddiates. I moved it there.

ANyway what this is saying is that for each stun server you want to use, 
pick one amongst the values returned from DNS and don't load balance 
within a session. I clarified.

> 
> ----
> 
>    Each candidate is associated with a property called its FOUNDATION.
>    Two candidates have the same foundation when they are "similar" - of
>    the same type and obtained from the same interfaces and STUN  servers.
> PM: s/interfaces/interface/  and s/servers/server/.

fixed

>    Otherwise, their foundation is different.  A candidate pair has a
>    foundation too, which is just the concatenation of the  foundations of
>    its two candidates.  Initially, only the candidate pairs with unique
>    foundations are tested.  The other candidate pairs are marked
>    "frozen".  When the connectivity checks for a candidate pair  succeed,
>    the candidate pairs with the same foundation are unfrozen.  This
> PM: s/the candidate pairs/other candidate pairs/  ?

fixed

>    avoids repeated checking of components which are superficially more
>    attractive but in fact are likely to fail.
> 
> ----
> 
>    With regular nomination, the controlling agent lets the checks
>    continue until at least one valid candidate pair for each media
>    stream is found.  Then, it picks amongst those that are valid, and
>    sends a second STUN request on its NOMINATED candidate pair, but  this
>    time with a flag set to tell the peer that this pair has been
>    nominated for use.  A This is shown in Figure 4.
> PM: s/A This/This/

fixed

> 
> ----
> 
> 2.7.  Lite Implementations
> 
>    In order for ICE to be used in a call, both agents need to support
>    it.  However, certain agents will always be connected to the public
>    Internet and have a public IP address at which it can receive  packets
>    from any correspondent.  To make it easier for these devices to
>    support ICE, ICE defines a special type of implementation called  LITE
>    (in contrast to the normal FULL implementation).  A lite
>    implementation doesn't gather candidates; it includes only host
>    candidates for any media stream.  When a lite implementation  connects
>    with a full implementation, the full agent takes the role of the
>    controlling agent, and the lite agent takes on the controlled role.
>    In addition, lite agents do not need to generate connectivity  checks,
>    run the state machines, or compute candidate pairs.  Additional
> PM: s/Additional/For/
>    guidance on when a lite implementation is appropriate, see the
>    discussion in Appendix A.

fixed

> 
> ----
> 
>    Default Destination/Candidate:  The default destination for a
>       component of a media stream is the transport address that  would be
>       used by an agent that is not ICE aware.  For the RTP component,
>       the default IP address is in the c line of the SDP, and the port
>       in the m line.  For the RTCP component it is in the rtcp  attribute
>       when present, and when not present, the IP address in the c line
>       and 1 plus the port in the m line.  A default candidate for a
>       component is one whose transport address matches the default
>       destination for that component.
> PM: The term "default" doesn't work very well when you talk about a
> re-offer that specifies a new "default" value.

I'm not going to change this term at this point. Its changed like three 
times already. Its the default because its where media is sent if ICE 
were not in use, and that is true in re-invites too.

> 
> ----
> 
>    The agent will receive a STUN Binding or Allocate response.  A
>    successful Allocate Response will provide the agent with a server
>    reflexive candidate (obtained from the mapped address) and a relayed
>    candidate in the RELAY-ADDRESS attribute.  If the Allocate  request is
>    rejected because the server lacks resources to fulfill it, the agent
>    SHOULD instead send a Binding Request to obtain a server reflexive
>    candidate.  A Binding Response will provide the agent with only a
>    server reflexive candidate (also obtained from the mapped address).
>    The base of the server reflexive candidate is the host candidate  from
>    which the Allocate or Binding request was sent.  The base of a
>    relayed candidate is that candidate itself.  If a relayed candidate
>    is identical to a host candidate (which can happen in rare cases),
>    the relayed candidate MUST be discarded.  Proper operation of ICE
>    depends on candidate having a unique base when their transport
>    addresses are identical.
> PM: You are mixing singular and plural in this sentence.
> PM: The operation implied by the last two sentences seems to be the same
>     as that described in the next section.

Actually the second sentence is stale and needs to be discarded. The 
first sentence states the rule - eliminate a relayed candidate that 
equals a host candidate.

> 
> ----
> 
> 4.1.1.3.  Eliminating Redundant Candidates
> 
>    Next, the agent eliminates redundant candidates.  A candidate is
>    redundant if its transport address equals another candidate, and its
>    base equals the base of that other candidate.  Note that two
>    candidates can have the same transport address yet have different
>    bases, and these would not be considered redundant.
> 
> PM: Which candidate should be kept? The highest priority candidate?

At this point in the spec, there hasn't been prioritization. It doesnt 
really matter which is eliminated, so I don't want to introduce 
priorities here.

> 
> 4.1.1.4.  Computing Foundations
> 
>    Finally, the agent assigns each candidate a foundation.  The
>    foundation is an identifier, scoped within a session.  Two  candidates
>    MUST have the same foundation ID when all of the following are true:
> 
>    o  they are of the same type (host, relayed, server reflexive, peer
>       reflexive or relayed)
> PM: "relayed" appears twice

fixed

> 
> ----
> 
>    Each candidate is assigned a foundation.  The foundation MUST be
>    different for two candidates from different interfaces, and MUST be
>    the same otherwise.  A simple integer that increments for each
>    interface will suffice.  In addition, each candidate MUST be  assigned
>    a unique priority amongst all candidates for the same media stream.
> PM: s/all candidates/all local candidates/

Everywhere else in this section, it is implicitly talking about local 
candidates since we havent exchanged candidates. So I dont see a need to 
add that qualifier here.

>    This priority SHOULD be equal to 2^24*(126) + 2^8*(65535) + 256  minus
>    the component ID, which is 2130706432 minus the component ID.
> 
>    If an agent has included two candidates for a component, the v4
>    candidate SHOULD be selected as the default.  Since a lite
> PM:  How can a lite agent include two candidates for a component. ???
>    implementation has a single candidate for a component, each of these
>    candidates is considered to be default.

lol. This is actually leftover text for when I tried (the first time) to 
work in the ability for lite implementations to support multiple host 
candidates. This is all changed now.

> 
> ----
> 
>    STUN connectivity checks between agents make use of a short term
>    credential that is exchanged in the offer/answer process.  The
>    username part of this credential is formed by concatenating a
>    username fragment from each agent, separated by a colon.  Each agent
>    also provides a password, used to compute the message integrity for
>    requests it receives.  The username fragment and password are
> PM: s/receives/sends/

NO. Remember when a server receives a request it recomputes the message 
integrity and compares it. So the password I select is used to construct 
M-I in requests sent to me, not ones I send.

>    exchanged in the ice-ufrag and ice-pwd attributes, respectively.  In
>    addition to providing security, the username provides disambiguation
>    and correlation of checks to media streams.  See Appendix B.4 for
>    motivation.
> 
> ----
> 
>        v=0
>        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
>        s=
>        c=IN IP4 192.0.2.3
>        t=0 0
>        a=ice-pwd:asd88fgpdd777uzjYhagZg
>        a=ice-ufrag:8hhY
>        m=audio 45664 RTP/AVP 0
>        b=RS:0
>        b=RR:0
>        a=rtpmap:0 PCMU/8000
>        a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host
>        a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
>    10.0.1.1 rport 8998
> PM: How are these priority value computed? I would have expected a  
> value of 2,130,706,431 and 1,694,498,815 respectively.

Yes, I get the same results. Must be based on a formula in a previous 
draft. Fixed.

> 
> ----
> 
>    o  For each media stream, the default destination for at least one
>       component of the media stream appears in a candidate attribute.
>       For example, in the case of RTP, the IP address and port in the c
>       and m line, respectively, appears in a candidate attribute, or  the
>       value in the rtcp attribute appears in a candidate attribute.
> PM: Why just "at least one component"? Why not all components?

THis is now fixed.

> 
> ----
> 
>    Once roles are determined for a session, they persist unless ICE is
>    restarted.  A ICE restart (Section 9.1 causes a new selection of
>    roles and tie-breakers.
> PM: s/9.1/9.1)/

fixed

> 
> ----
> 
> 5.7.2.  Computing Pair Priority and Ordering Pairs
> 
>    Once the pairs are formed, a candidate pair priority is computed.
>    Let O be the priority for the candidate provided by the offerer.   Let
>    A be the priority for the candidate provided by the answerer.  The
>    priority for a pair is computed as:
> 
>       pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0)
> 
>    Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is  greater
>    than A-P, and 0 otherwise.  This formula ensures a unique priority
> PM: Do you mean "O" rather than "O-P" and "A" rather than "A-P"?
> 
>    for each pair in most cases.  Once the priority is assigned, the
>    agent sorts the candidate pairs in decreasing order of priority.  If
>    two pairs have identical priority, the ordering amongst them is
>    arbitrary.

yes this is fixed.

> 
> ----
> 
> 5.7.3.  Pruning the Pairs
> 
>    This sorted list of candidate pairs is used to determine a sequence
>    of connectivity checks that will be performed.  Each check involves
>    sending a request from a local candidate to a remote candidate.
>    Since an agent cannot send requests directly from a reflexive
>    candidate, but only from its base, the agent next goes through the
>    sorted list of candidate pairs.  For each pair where the local
>    candidate is server reflexive, the server reflexive candidate  MUST be
>    replaced by its base.  Once this has been done, the agent MUST prune
> PM: A candidate is replaced by its corresponding base candidate. In  
> other words, all the associated information about the candidate  (e.g., 
> its foundation) is replaced by the associated information for  its base.

No, thats not true. Just the base. We are computing the check to be sent 
to verify that actual candidate pair.

> 
>    the list.  This is done by removing a pair if its local and remote
>    candidates are identical to the local and remote candidates of a  pair
>    higher up on the priority list.  The result is a sequence of ordered
>    candidate pairs, called the check list for that media stream.
> PM: Do we need to talk about what happens when the default candidate  pair
> gets pruned?

No, its fine. These are check lists, not signaled in the SDP.

> 
>    In addition, in order to limit the attacks described in
>    Section 17.4.2, an agent SHOULD limit the total number of
>    connectivity checks they perform across all check lists to 100, by
>    discarding the lower priority candidate pairs until there are less
>    than 100.
> 
> ----
> 
>    The initial states for each pair in the check list are computed by
> PM: s/the check list/a check list/
>    performing the following sequence of steps:
> 

fixed

> ----
> 
>    One of the check lists will have some number of pairs in the Waiting
>    state, and the other check lists will have all of their pairs in the
>    Frozen state.  A check list with at least one pair that is  Waiting is
>    called an active check list, and a check list with all pairs frozen
>    is called a frozen check list.
> PM: "active" and "frozen" look like check list states to me. Could we  
> make them explicit states?

They are orthogonal to the actual states; these are more like properties.

> 
>    The check list itself is associated with a state, which captures the
>    state of ICE checks for that media stream.  There are two states:
> PM: s/two states/three states/
> 
>    Running:  In this state, ICE checks are still in progress for this
>       media stream.
> 
>    Completed:  In this state, ICE checks have completed successfully  for
>       this media stream.
> 
>    Failed:  In this state, the ICE checks have not completed
>       successfully for this media stream.

fixed

> 
> ----
> 
>    Once the agent has computed the check lists as described in
>    Section 5.7, it sets a timer for each active check list.  The timer
>    fires every Ta*N seconds, where N is the number of active check  lists
>    (initially, there is only one active check list).  Implementations
>    MAY set the timer to fire less frequently than this.  Ta is the same
>    value used to pace the gathering of candidates, as described in
>    Section 4.1.1.  Multiplying by N allows this aggregate check
>    throughput to be split between all active check lists.  The first
>    timer for each active check list fires immediately, so that the  agent
>    performs a connectivity check the moment the offer/answer exchange
>    has been done, followed by the next periodic check Ta seconds later.
> PM: There is nothing here that requires all these timers to be spaced  out.
> As it stands, once every Ta*N seconds, all the timers could fire at  once.
> I am wondering if it is better to have just one timer and round-robin  
> between
> the check lists?

THe text now recommends spreading them out

> 
>    When the timer fires, the agent MUST:
> 
>    o  Find the highest priority pair in that check list that is in the
>       Waiting state.
> 
>    o  If there is such a pair:
> 
>       *  Send a STUN check from the local candidate of that pair to the
>          remote candidate of that pair.  The procedures for forming the
>          STUN request for this purpose are described in Section 7.1.1.
> PM: Move state of pair to "In-Progress"?
> 

wow, good catch. fixed.

> ----
> 
>    2.  If there is a pair in the valid list for every component of this
>        media stream (where this is the actual number of components  being
>        used, in cases where the number of components signaled in the  SDP
>        differs from offerer to answerer), the success of this check may
>        unfreeze checks for other media streams.  Note that this step is
> PM: Following the procedures as laid out here, the pair which has just
> transitioned to Succeeded is NOT YET on the valid list, because that  step
> doesn't happen until the next section.

good catch. I swapped the order of these sections.

>        followed not just the first time the valid list under
>        consideration has a pair for every component, but every
>        subsequent time a check succeeds and adds yet another pair to
>        that valid list.  The agent examines the check list for each
>        other media stream in turn:
> 
> ----
> 
>    If the agent is the controlled agent, the response may result in the
>    valid pair having its nominated flag set.  See Section 7.2.1.5 for
>    the procedure.
> PM: I don't see how this could be the case, since this is a binding  
> response.

THis part is complicated. For the controlled agent, when it receives a 
binding request with the USE-CANDIDATE flag, the nominated flag for the 
pair learned from the triggered check is set to true. So this section 
here is dealing with the case when that triggered check generates a 
success response.

> 
> ----
> 
>    Section 7.2.1.4, and Section 7.2.1.5 for full implementations.  In
>    cases where multiple STUN requests are received before the answer,
>    this may cause several triggered notifications to all be sent at the
>    same time,
> PM: s/,/./ ?
> PM: Can the response include a NONCE, as the STUN spec says it can?

Good question. I think its very counter-productive here. I'll indicate that.

> 
> ----
> 
> 7.2.1.1.  Detecting and Repairing Role Conflicts
> 
>    Normally, the rules for selection of a role in Section 5.2 will
>    result in each agent selecting a different role - one controlling,
>    and one controlled.  However, in unusual call flows, typically
>    utilizing third party call control, it is possible for both  agents to
>    select the same role.  This section describes procedures for  checking
>    for this case and repairing it.
> PM: Can we see examples of 3PCC cases where this problem comes up?
> I am worried that no one but Jonathan understands these cases.

I added an informational appendix on it.

> 
>    An agent MUST examine the Binding Request for either the ICE-
>    CONTROLLING or ICE-CONTROLLED attribute.  It MUST follow these
>    procedures:
> 
>    o  If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the
>       request, there is no conflict.
> 
> PM: Isn't this a malformed binding request, since 7.1.1.2. requires
> one of these to be included?

Yes - this is to deal with previous versions of the draft which didn't 
use it.

> 
> ----
> 
> 7.2.1.4.  Triggered Checks
> 
>    Next, the agent constructs a pair whose local candidate is equal to
> 
> PM: This is a transport address pair, not a candidate pair. Then we  are 
> trying to match this transport address pair to a candidate pair  on a 
> check list. We use the local and remote UFRAGs to do this. In  fact, I 
> claim all this processing happens just before section 7.2.1.3.

THe term transport address pair is not used anymore; this is a candidate 
pair.

> 
> ----
> 
>    If a triggered check is to be generated, it is constructed and
>    processed as described in Section 7.1.1.  These procedures require
>    the agent to know the transport address, username fragment and
>    password for the peer.  The username fragment for the remote
>    candidate is equal to the part after the colon of the USERNAME in  the
>    Binding Request that was just received.  Using that username
> PM: Why do I have to extract the username fragment in this manner?
> I know the local and remote candidate pair -- why can't I just used  the 
> username fragment and password associated with it?

You don't know the remote candidate from the SDP at this point; you are 
trying to determine it based on the received triggered check. You can't 
look at source IP/port alone and match to SDP, due to peer reflexive 
candidates and forking.

>    fragment, the agent can check the SDP messages received from its  peer
> 
> 
> 
> Rosenberg              Expires September 27, 2007              [Page 46]
> Internet-Draft                     ICE                        March 2007
> 
> 
>    (there may be more than one in cases of forking), and find this
>    username fragment.  The corresponding password is then selected.  If
>    agent has not yet received the username in an SDP (a likely case for
>    the offerer in the initial offer/answer exchange), it MUST wait for
>    the SDP to be received (since it won't have its peer's ICE password
>    without it), and then proceed with the triggered check.
> PM: You already said this above.

RIght - deleted here.

> 
> ----
>    o  If there is at least one nominated pair in the valid list for a
>       media stream and the state of the check list is Running:
> 
>       *  The agent MUST remove all Waiting and Frozen pairs in the  check
>          list for the same component as the nominated pairs for that
>          media stream
> PM: Do we remove ALL, or only those of lower priority?
> 
> ----
> 
>    o  Once there is at least one nominated pair in the valid list for
>       every component of at least one media stream and the state of the
>       check list is Running:
> 
>       *  The agent MUST change the state of processing for its check
>          list for that media stream to Completed.
> 
> PM: What about checks that are "In-Progress"? Do these continue to  run? 
> If they do, then the stuff below about changing the state of ICE  
> processing overall to Completed seems wrong. (Or is this why it is  
> possible in Aggressive Nomination, for the default candidate to  change 
> multiple times?)

exactly.

> 
>       *  The agent MUST continue to respond to any checks it may still
>          receive for that media stream, and MUST perform triggered
>          checks if required by the processing of Section 7.2.
> 
> ----
> 
>    <connection-address>:  is taken from RFC 4566 [10].  It is the IP
>       address of the candidate, allowing for IPv4 addresses, IPv6
>       addresses and FQDNs.  An IP address SHOULD be used, but an FQDN
>       MAY be used in place of an IP address.  In that case, when
>       receiving an offer or answer containing an FQDN in an a=candidate
>       attribute, the FQDN is looked up in the DNS using an A or AAAA
>       record, and the resulting IP address is used for the remainder of
>       ICE processing.
> PM: What is the motivation for allowing an FQDN in this position? I  
> think this just makes the implementation more complex, for no good  reason.

We discussed on the list; largely this is because SDP generally allows 
FQDN and I'm not changing that.

> 
> ----
> 
> 15.5.  "ice-options> Attribute
> PM: s/>/"/

fixed

> 
> ----
> 
> 17.5.  Interactions with Application Layer Gateways and SIP
> 
>    Application Layer Gateways (ALGs) are functions present in a NAT
>    device which inspect the contents of packets and modify them, in
>    order to facilitate NAT traversal for application protocols.   Session
>    Border Controllers (SBC) are close cousins of ALGs, but are less
>    transparent since they actually exist as application layer SIP
>    intermediaries.  ICE has interactions with SBCs and ALGs.
> 
>    If an ALG is SIP aware but not ICE aware, ICE will work through  it as
>    long as the ALG correctly modifies the SDP.  In this case, correctly
>    means that the ALG does not modify the m and c lines or the rtcp
>    attribute if they contain external addresses.  If they contain
>    internal addresses, the modification depends on the state of the  ALG.
>    If the ALG already has a binding established that maps an external
>    port to an internal IP address and port in m and c lines or rtcp
>    attribute , the ALG uses that binding instead of creating a new one.
> PM: I think these last two sentences are meant to be descriptions of
> a correctly operating ALG, but this is not obvious from the wording.

clarified.

> 
> ----
> 
> B.1.  Pacing of STUN Transactions
> 
>    STUN transactions used to gather candidates and to verify
>    connectivity are paced out at an approximate rate of one new
>    transaction every Ta milliseconds, where Ta has a default of 20ms.
>    Why are these transactions paced, and why was 20ms chosen as  default?
> PM: Below you describe why transactions are paced, but do not explain  
> why 20ms was chosen as the default. Perhaps add a sentence that says  
> that 20ms was chosen after an experiments with a number of NATs  showed 
> that they could all handle 20ms but could not handle  significantly 
> higher rates?

done

> 
> ----
> 
> B.2.  Candidates with Multiple Bases
> 
>    Section 4.1.1 talks about merging together candidates that are
>    identical but have different bases.  When can an agent have two
>    candidates that have the same IP address and port, but different
>    bases?  Consider the topology of Figure 23:
> 
> PM: There is no discussion in section 4.1.1 about "merging"  candidates. 
> Are you referring here to section 4.1.1.3 on eliminating  duplicate 
> candidates, and in particular to the last sentence? If so,  perhaps 
> reword this as follows:
> "Section 4.1.1.3 talks about eliminating duplicate candidates, and  
> states that a candidate can be eliminated only if there is another  
> candidate with the same transport address and base. This leads to the  
> question: How two candidates can have the same transport addresses,  but 
> different bases? Consider the topology of Figure 23:".

fixed

> 
> PM: Also, I think it would be useful to add a paragraph motivating  why 
> one wants to eliminate duplicate candidates. I suggest mentioning  the 
> common case of obtaining a server reflexive candidate for a host  
> candidate, and discovering that the two candidates are the same.  
> Perhaps you can think of other common cases?

Thats the main one. I mention it now in the section on eliminating 
redundant candidates.

> 
> 
> ---
> B.5.  The Candidate Pair Sequence Number Formula
> 
>    The sequence number for a candidate pair has an odd form.  It is:
> 
>       pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P? 1:0)
> 
>    Why is this?  When the candidate pairs are sorted based on this
>    value, the resulting sorting has the MAX/MIN property.  This means
>    that the pairs are first sorted based on decreasing value of the
>    maximum of the two sequence numbers.  For pairs that have the same
>    value of the maximum sequence number, the minimum sequence number is
>    used to sort amongst them.  If the max and the min sequence numbers
>    are the same, the offerers priority is used as the tie breaker in  the
>    last part of the expression.  The factor of 2*32 is used since the
>    priority of a single candidate is always less than 2*32,  resulting in
>    the pair priority being a "concatenation" of the two component
>    priorities.  This creates the desired sorting property.
> 
> PM: Perhaps add a paragraph on why this particular sorting algorithm  
> was chosen?
> 

Added a sentence.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic