Communicating Final ICE results

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

Ice and open internet devices

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

ICE and open internet devices

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

RE: ICE and open internet devices--second is a repost; mmusic or my mailserver is glitchy

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

RE: About the VAD in SDP negotiation

Hi
It is codec-dependant. There is no global VAD attribute in SDP.
The media type registration of an audio codec may define a VAD-related parameter (e.g. 'annexb' for audio/G729).


________________________________

	De : alan [mailto:alan_zhang <at> sh.askey.com.tw] 
	Envoyé : mercredi 27 septembre 2006 09:28
	À : mmusic
	Objet : [MMUSIC] About the VAD in SDP negotiation
	
	
		Dear mmusic-request :
	 
	　　How to enable/disable VAD in sdp ? 
	 
	2006-09-27
	=================================== 
	Best Regards from Alan on 2005/6/2.
	MSN:laoer23 <at> hotmail.com
	Tel :021-50808186-109
	M : 13564020066
	Company :VoIP.Askey
	 
	在我的眼里，你如梦幻！
	============================　
	 
			

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

Question about bundling SDP m=lines

Folks,

I hope I would like to ask an question on SDP offer/answer model.

Imagine the case where the offerer initiates a video call.
Is there any parameter which indicates offerer doesn't want
answerer to answer an SDP with video medium only,
without an audio medium?

An SDP offer for video call includes two m=lines, m=audio and m=video. 
According to RFC4566/3264, the answerer may read
each m=line independently, and may return a SDP answer
with port 0 in either of the two m=lines.
Session may be established with video only, without audio,
which is not the caller's intention.

  offerer                             answerer
     |                                  |
     | INVITE (m=video & m=audio)       |
     |--------------------------------->|
     | 200 OK (m=video & m=audio port 0)|
     |<---------------------------------|
     |     RTP session (video only)     |
     |<================================>|
     |                                  |

To avoid this, offerer have to tell the answerer that
m=audio and m=video are bundled and that it doesn't
want to establish with either of the media.

I hope I would like to ask you how to express the offerer's intention.

I guess this should be achived by m=line group attribute
defined by RFC3388, because it says in Chapter 1 that "expression of 
how different media streams within a session description relate to 
each other." I guess that this would make it possible to express
that m=audio and m=video are bundled.

What the "semantics" field should be set, 
if I use a group attribute in this way? 
Four values, "LS", "FID", "SRF" and "ANAT" are registered on IANA,
but none of them seems to be intended to influence UA's offer/answer.
Is a new semantics parameter needed to meed the requirement?

Please let me know your advice.

Does this topic match to another mailing list more?
I apologize if this subject is off-topic for this mailing list.

Thank you,
Jun Koshiko

Re: Ice and open internet devices

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

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 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
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>

RE: Ice and open internet devices

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: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
> 
> 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
> 
> 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 
> 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
> > mmusic <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

Re: Ice and open internet devices

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 <philip_matthews <at> magma.ca> wrote:
> 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
>
> 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 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
> > mmusic <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >
>
>
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>

Re: Ice and open internet devices

A device would not determine that it is on the open internet by discovery; it would use configuration which
is set at delpoyment time.

If a PSTN gateway is behind a NAT, it would have to implement full ice.  The purpose of 'ice-passive' is to
simplify the implementation of devices that are not behind a NAT.

-Derek

Michael Slavitch <slavitch <at> gmail.com> said:

> 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 <philip_matthews <at> magma.ca> wrote:
>> 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
>>
>> 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 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
>> > mmusic <at> ietf.org
>> > https://www1.ietf.org/mailman/listinfo/mmusic
>> >
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
>