Subject: RE: [MMUSIC] Confusion regarding ICE username fragment

From: "Thomas Zeng" <[email-masked]>
Date: Tue, 26 Oct 2004 17:09:05 -0700

One comment inlined. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Monday, October 25, 2004 10:36 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Confusion regarding ICE username fragment
> 
> Jon,
> 
> Good question. Basically, this was a bug in ICE.
> 
> Each local transport address has to have its own username and 
> password. 
> Now, in -03, each local transport address is either used in 
> the initiate/accept mesage, or else is associated with a 
> single derived transport address. This means that if I have a 
> single local interface and can use TURN and STUN unilateral 
> allocations, I'll bind to *three* local interfaces. One of 
> them gets sent directly to the peer. One is used for the STUN 
> allocations. One is used for the TURN allocations. A stun 
> server is set to run locally on all three sockets, and each 
> of the three has a unique username/password.
> 
> If you don't do this, you run into a nasty problem which is 
> there is no way to reliably know that your peer has suceeded 
> in its connectivity checks. That is needed to allow you to 
> turn off the stun server and accept only media packets. This 
> also simplified the protocol in several places.

I'd like to point out that there are use cases for keeping STUN server
running on the chosen endpoint (i.e., <address, port>) even after
connectivity checks have succeeded. 

For RTSP where media packets flow one way from the RTSP server to its
client, it is useful to keep periodic STUN exchanges to keep alive the
NAT bindings. It is known in the real world that cerntain NAT bindings
will be deleted if there is no traffic going a specific direction
(normally from outside in, if I remember correctly).

I do agree though the other STUN servers can be closed after the
connectivity phase.

> 
> The drawback (compared to having multiple derived transport 
> addresses from a single local transport address) is that it 
> increases your port usage. I was hesitatnt to go this route 
> at first because of this, but the alternative (not being able 
> to turn off the stun servers) seemed worse based on group 
> consensus on this point.
> 
> The problem is probably only a big deal in servers like 
> gateways and conference bridges. However, if those do ICE, I 
> wouldn't expect them to do turn or stun, in which case there 
> is no additional cost in terms of socket resources.
> 
> HTH,
> Jonathan R.
> 
> Jon Ringle wrote:
> > I'm a little confused regarding the use of username 
> fragments in ICE. 
> > The following statement is in draft-ietf-mmusic-ice-02, 
> Section 5.3.2:
> > 
> >    For each local transport address where a STUN server is 
> running, the
> >    client MUST choose a username fragment and a password.  
> The username
> >    fragment created by the client will be concatenated with 
> the fragment
> >    created by its peer.  The result will serve as the 
> username provided
> >    by its peer in STUN requests.  By creating the username as a
> >    combination of information from each side of a call, it allows a
> >    client to correlate the source of the request with a candidate
> >    transport address.  This is discussed further below.
> > 
> >    The username fragment MUST be globally unique, so that 
> no other host
> >    will select a username with the same value.  This 
> username fragment
> >    and password will be passed to its peer in an initiate or accept
> >    message.  As such, the process described in this section will
> >    associate, with each local transport address, a username 
> fragment and
> >    password.  The client also associates this same username 
> fragment and
> >    password with any transport addresses derived from the local
> >    transport address.
> > 
> > Suppose phone-A has only one local transport address on eth0 and 
> > derives a STUN and TURN address from the eth0 local 
> transport address. 
> > From what I read above, it seems like only a username fragment and 
> > password is chosen only for the eth0 address, and that the derived 
> > STUN/TURN addresses use this same username/password. So, this would 
> > result in alt's in SDP in the initiate message from phone-A 
> to phone-B like this:
> > 
> > a=alt:1 1.0 : PhoneAeth0user password 172.16.1.102 1234
> > a=alt:2 0.8 : PhoneAeth0user password 1.1.1.4 8801
> > a=alt:3 0.4 : PhoneAeth0user password 1.1.1.5 3002
> > 
> > This seems to go against the examples that are shown in 
> > draft-rosenberg-sipping-nat-scenarios-03, where a separate username 
> > fragment is shown for each local and derived addresses.
> > 
> > It seems to me that separate username fragments would be needed for 
> > each gathered address for correlation to the candidate table.
> > 
> > I feel like I am missing a key concept here. Could someone 
> please explain.
> > 
> > Thanks,
> > 
> > Jon
> > 
> > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Oct 2004 12:28:57 -0400

inline.

> (normally from outside in, if I remember correctly).

Right. ICE does currently say that this is an application problem, and 
in this context, it would mean using things like comfort noise of 
perhaps the rtp no-op format from the client to the RTSP server. Have 
you considered that?

If we want to use STUN for keepalives, the problem you run into is how 
the client knows whether the stun server is still running or not. If its 
not, the client shouldnt send the STUn packets; if it is, it can. The 
-03 draft solves this by using the transmission and receipt of RTP 
packets onto that address/port as a means for synchronizing this 
transition. If you leave it flexible as to whether it stays running or 
not, now you need to signal and syncrhonize on it, adding additional 
protocol options (a bad thing in general) and complexity.

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