Subject: [MMUSIC] ICE and open internet devices

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 2 Oct 2006 16:02:50 -0700

Ice should be simplified for devices that are running on the open internet
or not behind a NAT from the perspective of other devices.  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 gateways 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 convenience, 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 permissions.  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 advertises
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 2 Oct 2006 17:17:23 -0700

_____  

From: Derek MacDonald [mailto:[email-masked]] 
Sent: Monday, October 02, 2006 4:03 PM
To: [email-masked]
Subject: [MMUSIC] ICE and open internet devices

Desired simplifications

Proposed Solution

-Derek