Subject: [MMUSIC] Ice and open internet devices

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 2 Oct 2006 16:51:13 -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: Philip Matthews <[email-masked]>
Date: Tue, 3 Oct 2006 09:26:09 -0400

Derek:

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 3 Oct 2006 15:37:16 +0200

Hi,

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
there?

Regards,

Christer

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]] 
> Sent: 3. lokakuuta 2006 16:26
> To: Derek MacDonald
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Ice and open internet devices
> 
> Derek:
> 
> Does it look at its IP address? This mostly works, but there 
> was a recent case in Italy where this test would have failed.
> 
> > 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
> > 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
> > 3. the GW is never the controlling endpoint, and will 
> announce this  
> > in SDP
> > (see later)
> >

---

From: "Michael Slavitch" <[email-masked]>
Date: Tue, 3 Oct 2006 09:43:41 -0400

In many situations that would fail. An assumption that a public IP
address is not behind some kind of firewall, walled garden or gateway
is a false assumption.

Philip is entirely correct about a PSTN gateway supporting ICE
operating behind a NAT.  Same goes for any SIP registrar.

On 10/3/06, Philip Matthews <[email-masked]> wrote:
> > internet
> > in the 'same place'.   I do not know of any ice-aware PSTN gateways
> > that
> > cost of

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 08:58:12 -0700

I think the simple answer would be that the device does not detect  
this in any way. Originally we tried to make a scheme where only the  
UA that was behind a NAT needed to deal with NAT traversal (and stun  
was invented). That worked some of the time but not all. We then  
moved to a idea where both sides had to support something new to work  
through NATs - this is ICE. We recognized that the major drawback of  
ICE is that both sides, not just one had to do write new software and  
deploy it.

What Derek's proposal here does it reduce the bar on how much work  
the side that is *not* behind the NAT needs to do. I'm very much in  
favor of thinking about this and figuring out how to do this. I am  
not aware of a single ICE GW on the market yet and the current design  
of full ICE is surprisingly complicated for a large GW to implement.  
Keep in mind the software that sees the sip is usually running on a  
different CPU than the one sees the RTP and often they are not even  
in the same box. Most the large PSTN GWs that can do SS7 interconnect  
are very distributed in their architecture.

It would of course be best if the GWs did full ICE but if they are  
unwilling to do that, they could instead implement something somewhat  
reduced that allowed them to work in certain (but not all) topologies  
- specifically if their IP were always global and routable.

Now you might think, who cares if large PSTN GWs can work or not but  
until they deploy something that the soft-phones can use, there is  
little benefit in the soft-phones bothering to do ICE since they will  
have to do something else to work with the PSTN GWs.

On Oct 3, 2006, at 6:26 AM, Philip Matthews wrote:

>> convenience, will
>> permissions.  Local

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 3 Oct 2006 21:37:43 +0200

Hi Cullen,

In the case where there the GW is not behind a NAT, does it really make
a difference whether the GW implements "full ICE" or not? Because, if
there is no NAT, there is no STUN server to connect (at least it makes
no sense to connect to one), so there will only be a single candidate in
any case...

Regards,

Christer 

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 3. lokakuuta 2006 18:58
> To: Philip Matthews
> Cc: [email-masked]
> I think the simple answer would be that the device does not 
> detect this in any way. Originally we tried to make a scheme 
> where only the UA that was behind a NAT needed to deal with 
> NAT traversal (and stun was invented). That worked some of 
> the time but not all. We then moved to a idea where both 
> sides had to support something new to work through NATs - 
> this is ICE. We recognized that the major drawback of ICE is 
> that both sides, not just one had to do write new software 
> and deploy it.
> 
> What Derek's proposal here does it reduce the bar on how much 
> work the side that is *not* behind the NAT needs to do. I'm 
> very much in favor of thinking about this and figuring out 
> how to do this. I am not aware of a single ICE GW on the 
> market yet and the current design of full ICE is surprisingly 
> complicated for a large GW to implement.  
> Keep in mind the software that sees the sip is usually 
> running on a different CPU than the one sees the RTP and 
> often they are not even in the same box. Most the large PSTN 
> GWs that can do SS7 interconnect are very distributed in 
> theiFrom [email-masked] Tue Oct 03 15:38:03 2006
Content-class: urn:content-classes:message
Subject: RE: [MMUSIC] Ice and open internet devices
Date: Tue, 3 Oct 2006 21:37:43 +0200
From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>,
	"Philip Matthews" <[email-masked]>
Cc: [email-masked]

Hi Cullen,

In the case where there the GW is not behind a NAT, does it really make
a difference whether the GW implements "full ICE" or not? Because, if
there is no NAT, there is no STUN server to connect (at least it makes
no sense to connect to one), so there will only be a single candidate in
any case...

Regards,

Christer 

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 3. lokakuuta 2006 18:58
> To: Philip Matthews
> Cc: [email-masked]
> I think the simple answer would be that the device does not 
> detect this in any way. Originally we tried to make a scheme 
> where only the UA that was behind a NAT needed to deal with 
> NAT traversal (and stun was invented). That worked some of 
> the time but not all. We then moved to a idea where both 
> sides had to support something new to work through NATs - 
> this is ICE. We recognized that the major drawback of ICE is 
> that both sides, not just one had to do write new software 
> and deploy it.
> 
> What Derek's proposal here does it reduce the bar on how much 
> work the side that is *not* behind the NAT needs to do. I'm 
> very much in favor of thinking about this and figuring out 
> how to do this. I am not aware of a single ICE GW on the 
> market yet and the current design of full ICE is surprisingly 
> complicated for a large GW to implement.  
> Keep in mind the software that sees the sip is usually 
> running on a different CPU than the one sees the RTP and 
> often they are not even in the same box. Most the large PSTN 
> GWs that can do SS7 interconnect are very distributed in 
> their architecture.
> 
> It would of course be best if the GWs did full ICE but if 
> they are unwilling to do that, they could instead implement 
> something somewhat reduced that allowed them to work in 
> certain (but not all) topologies
> Now you might think, who cares if large PSTN GWs can work or 
> not but until they deploy something that the soft-phones can 
> use, there is little benefit in the soft-phones bothering to 
> do ICE since they will have to do something else to work with 
> the PSTN GWs.
> 
> 
> > Does it look at its IP address? This mostly works, but there was a 
> > recent case in Italy where this test would have failed.
> >
> >> gateways that
> >> only ever have one candidate.  The candidate will be the 
> global IP  
> >> address
> >> will send to the first validated candidate for a 
> component.  A new  
> >> SDP
> >> ice-passive must be in the open region of the topology, so 
> it will  
> >> not need
> >> triggered check succr architecture.
> 
> It would of course be best if the GWs did full ICE but if 
> they are unwilling to do that, they could instead implement 
> something somewhat reduced that allowed them to work in 
> certain (but not all) topologies
> Now you might think, who cares if large PSTN GWs can work or 
> not but until they deploy something that the soft-phones can 
> use, there is little benefit in the soft-phones bothering to 
> do ICE since they will have to do something else to work with 
> the PSTN GWs.
> 
> 
> > Does it look at its IP address? This mostly works, but there was a 
> > recent case in Italy where this test would have failed.
> >
> >> gateways that
> >> only ever have one candidate.  The candidate will be the 
> global IP  
> >> address
> >> will send to the first validated candidate for a 
> component.  A new  
> >> SDP
> >> ice-passive must be in the open region of the topology, so 
> it will  
> >> not need