RE: Ice and open internet devices
Christer Holmberg (JO/LMF <christer.holmberg <at> ericsson.com>
2006-10-03 13:37:16 GMT
I think Derek is bringing up some interesting issues.
How a device "knows" whether it's on the "open internet" or not can of
course be discussed, but there may be scenarios where the device doesn't
have any STUN servers configured - ie it is not able to retrieve
candidates no matter what internet it's located on.
Now, in that case, if the device still supports ICE, I think it's good
to include a candidate for the c/m-line, in order to allow the remote
entity (which may be located behind a NAT, and have access to STUN
servers), to use ICE.
Also, if the global address is chosen for the session, the question is
(as Derek said) whether we need STUN keep-alives. We don't need it in
order to keep NAT bindings open, but do we need it in order to provide
connectivity checks? Or, can we assume that the connectivity will be
> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthews <at> magma.ca]
> Sent: 3. lokakuuta 2006 16:26
> To: Derek MacDonald
> Cc: mmusic <at> ietf.org
> Subject: Re: [MMUSIC] Ice and open internet devices
> How does a device determine that it is on the open Internet?
> Does it look at its IP address? This mostly works, but there
> was a recent case in Italy where this test would have failed.
> And, BTW, a PSTN gateway does not have to be on the open Internet.
> With ICE, a PSTN gateway can easily be behind a NAT.
> - Philip
> On 2-Oct-06, at 19:51 , Derek MacDonald wrote:
> > Ice should be simplified for devices that are running on the open
> > internet or not behind a NAT from the perspective of other
> > The most common example of this device is a PSTN gateway, although
> > B2BUAs could be deployed
> > in the 'same place'. I do not know of any ice-aware PSTN
> > that
> > have been deployed, and I suspect this is due to the implementation
> > cost of ice.
> > Desired simplifications
> > 1. stateless processing, or a much simplified ice state machine 2.
> > should never be the deciding endpoint in the ice algorithm
> 3. limited
> > communication between the signaling component and media component
> > Proposed Solution
> > This type of device, which I will refer to as a GW for
> > will
> > only ever have one candidate. The candidate will be the global IP
> > address
> > of the GW, which will always be the same as the m/c line;
> so candidate
> > gathering is eliminated. The GW will not have a NAT/FW in
> front of
> > it, so
> > it will not have to send STUN requests to open NAT/FW
> > Local
> > permissions would have to be opened based on the remote
> SDP, but GW
> > devices
> > that wish to enforce must already do this for the remote
> m/c line.
> > A GW
> > does not prefer any candidate, as it only has one, so it has no
> > motivation
> > to prioritize candidates. This leads us to:
> > 1. a GW will only perform triggered checks
> > 2. for each component the GW will send media to the last successful
> > triggered check, unless informed otherwise by the remote party
> > 3. the GW is never the controlling endpoint, and will
> announce this
> > in SDP
> > (see later)
> > The triggered check is necessary because the remote (non GW)
> > endpoint could
> > be behind a NAT/FW which allows outgoing UDP packets but blocks
> > incoming UDP
> > packets. #2 is the same as we are proposing for normal ice
> > devices, which
> > will send to the first validated candidate for a component.
> A new SDP
> > attribute, ice-passive, would be used for #3. Any GW that
> > ice-passive must be in the open region of the topology, so it will
> > not need
> > ice to communicate with another GW which offers ice-passive. So,
> > if both
> > devices advertise ice-passive, no ice discovery will take place.
> > Keepalives
> > should not be necessary, but if they are desired, ice keepalives
> > will be
> > used. If no side indicates ice-passive, the offerer is the
> > controlling
> > endpoint, as in ice-10.
> > If the controlling endpoint wishes the ice-passive endpoint to
> > switch to
> > another candidate, it can accomplish this by sending an ice-check
> > which will
> > cause the GW to send a triggered check and change candidates if the
> > triggered check succeeds.
> > This approach will allow a very light implementation of ICE for
> > this type of
> > device. It requires very little state (one table of permissions,
> > one table
> > of validated candidates from triggered checks) and very little
> > communication
> > between the signaling and media components. It eliminates candidate
> > gathering, priority processing and the ice-check state machine.
> > -Derek
> > _______________________________________________
> > mmusic mailing list
> > mmusic <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> mmusic mailing list
> mmusic <at> ietf.org