Subject: [MMUSIC] ICE-10: Indication of ICE support

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 8 Sep 2006 09:29:41 +0200

Hi,

Currently, the SDP candidate attributes is the only way for an entity to
indicate support of ICE. The issues with that is:

1. You can't use OPTIONS to figure out whether the remote entity
supports ICE (yes, you can include an SDP in the OPTIONS reply, but I
don't see how the candidate attributes would "fit" there).

2. If you send an INVITE without SDP, the remote entity does not know
whether the caller supports ICE or not. If it knew that the caller does
NOT support ICE, it would not need to collect attributes itself.

An options-tag would solve these issues. 

I am pretty sure this has been discussed before, so was there some
conclusion why such an option-tag would be harmful? Or, was it simply
seen as not needed?

Regards,

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

---

From: "Michael Slavitch" <[email-masked]>
Date: Fri, 8 Sep 2006 08:57:47 -0400

An option tag would  would also solve the protocol version problem, as ICE
versioning will eventually happen.
It would simplify things greatly up front and limit the protocol handshake
as it will only have to guess the  available connection path, not the
capabilities of the remote agent.

We shouldn't  guess when that is known and can be transmitted. That should
not be guesswork.

For implementors:   Interoperability testing will also be easier because the
options tag becomes a spec.
For future proofing:  Versioning will prevent our successors from having a
reason to curse us.
For vendors:           The options tag allows a quick and easy way to spec
out supported devices.
For users:              It makes the buyind decision easy.

There is so much benefit from clarity. Let's always try for clarity and
up-front behavior unless there are compelling reasons not to do so.

Regards

M

On 9/8/06, Christer Holmberg (JO/LMF) <[email-masked]>
wrote:
> 1. You can't use OPTIONS to figure out whether the remote entity supports
> ICE (yes, you can include an SDP in the OPTIONS reply, but I don't see how
> the candidate attributes would "fit" there).
>
> whether the caller supports ICE or not. If it knew that the caller does NOT
> support ICE, it would not need to collect attributes itself.
>
> conclusion why such an option-tag would be harmful? Or, was it simply seen
> as not needed?
>
> Regards,
>
> Christer
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 12 Sep 2006 09:50:14 +0200

Hi,
 
Another possible use-case is when all media stream components are
inactive in the offer.
 
According to chapter 4.3 those components are not active, and may
therefor not contain candidates, which means there is no indication of
ICE support.
 
Regards,
 
Christer

________________________________

	From: Michael Slavitch [mailto:[email-masked]] 
	Sent: 8. syyskuuta 2006 15:58
	To: Christer Holmberg (JO/LMF)
	Cc: IETF MMUSIC WG; Jonathan Rosenberg
	Subject: Re: [MMUSIC] ICE-10: Indication of ICE support

	An option tag would  would also solve the protocol version
problem, as ICE versioning will eventually happen.
	It would simplify things greatly up front and limit the protocol
handshake as it will only have to guess the  available connection path,
not the capabilities of the remote agent.  
	
	We shouldn't  guess when that is known and can be transmitted.
That should not be guesswork.
	
	For implementors:   Interoperability testing will also be easier
because the options tag becomes a spec.
	For future proofing:  Versioning will prevent our successors
from having a reason to curse us. 
	For vendors:           The options tag allows a quick and easy
way to spec out supported devices.
	For users:              It makes the buyind decision easy.
	
	There is so much benefit from clarity. Let's always try for
clarity and up-front behavior unless there are compelling reasons not to
do so. 
	
	Regards
	
	M

	On 9/8/06, Christer Holmberg (JO/LMF)
<[email-masked]> wrote: 

		Hi, 

		Currently, the SDP candidate attributes is the only way
for an entity to indicate support of ICE. The issues with that is:

		1. You can't use OPTIONS to figure out whether the
remote entity supports ICE (yes, you can include an SDP in the OPTIONS
reply, but I don't see how the candidate attributes would "fit" there). 

		2. If you send an INVITE without SDP, the remote entity
does not know whether the caller supports ICE or not. If it knew that
the caller does NOT support ICE, it would not need to collect attributes
itself. 

		I am pretty sure this has been discussed before, so was
there some conclusion why such an option-tag would be harmful? Or, was
it simply seen as not needed?

		Regards, 

		Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 11:48:05 -0400

> don't see how the candidate attributes would "fit" there).

RFC3264 talks about construction of SDP in OPTIONS responses. I think 
its fairly easy to add some text on how one would add candidate 
attributes in an options response. Namely, they would be present, one 
for each type of candidate supported, but with useless IP/ports. Thus, 
there are no allocations. THe candidate lines indicate ICE support and 
an indiction of candidate types. Much like codecs.

> NOT support ICE, it would not need to collect attributes itself.

THis is a fair point. I'll note that one common use case for offerless 
INVITEs is 3pcc; in this case the controller couldn't insert an option 
tag anyway. HOwever, there are use cases for offerless INVITE where the 
offerer does know whether it supports ICE.

THe option tag would possibly also help when presence is used; the 
presence document could indicate ICE support ahead of time.

I'm inclined to add this.

> conclusion why such an option-tag would be harmful? Or, was it simply 

Seen as not neeeded. Everything you point out above is corner case. THe 
baseline cases don't need it.

-Jonathan R.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 11:49:23 -0400

Michael Slavitch wrote:

> An option tag would  would also solve the protocol version problem, as 
> ICE versioning will eventually happen.

I disagree. We may have revisions of ICE, but the aim would be to retain 
backwards compatibility once the RFC is issued. If we require an option 
tag, this basically implies a 'dual-stack' implementation that 
implements both the old and the new spec, and I'd rather avoid that.

-Jonathan R.