[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Proposed approach for NICE
Hi Remi,
Rémi Denis-Courmont wrote:
On Saturday 05 July 2008 13:09:45 ext Hannes Tschofenig, you wrote:
I am not sure whether this is really such a useful effort.
There aren't too many protocols that are going to make use of ICE as
there aren't too many protocols anyway. We have been experimenting with
ICE for usage with MIP and HIP. The work has not gone very far yet. The
lack of progress had nothing todo with this type of document. The work
in XMPP is already finished and hence this document will not help them
either.
A rough list of things that may cause simplification:
This is exactly the type of things the protocol designer has to figure
out when they work on their favorite protocol. Another document will not
take a decision away from thinking about these things.
If these things are not sufficiently well explained then they should be
fixed in ICE rather than adding another document.
* Multiple components:
Protocols should avoid using multiple inter-dependent UDP flows, as it adds
complexity and increases the failure rate. ICE has this because of RTCP
running on a different port than RTP.
* Multiple medias:
Protocols should avoid using multiple independent UDP flows for the same
reasons. This is in ICE because SIP must negotiate all media (m= lines)
together within Offer/Answer. If a protocol really needs multiple media, it
can try to negotiate them sequentially (-> RTSP?) which also simplifies
things a lot.
* Role conflict:
This is needed because SIP has no requester/answerer asymmetry, at least when
3pcc is used. When there is unambiguously a requester and an answerer (e.g.
RTSP client/server), there is no need for this. Unfortunately, this is a bit
more difficult to implement a simplification, as it violates the base ICE
spec.
I suppose that's what Jonathan was referring to by "talk about role selection
and how that is kind of specific to sip but how to be compatible with it".
And then you need to spell out which parameter need to be encoded.
And when ICE can/should (not) be used.
Coming to some specific protocols that could use ICE:
MIP is a client(MN)-server(HA) protocol. It should not even need to use ICE.
The HA should sit on a public IP/port tuple, and receive UDP packets from the
client (that does not preclude doing return routability checks). That's
several order of magnitude simpler than using ICE, *and* it is just as
reliable. At least, that's my take on it...
I am not sure where you got that impression from.
I am not suggesting to use ICE between the MN and the HA. Instead, I am
suggesting to use it between the MN and the CN.
I suppose HIP-ICE already does assume a single media and a single component.
We are not fully sure.
XMPP is very close to SIP in terms of ICE "requirements", since it uses
RTP/RTCP in a similar way. The only thing that it might be to spare is role
conflict handling, which is only needed because of 3pcc, I suppose. And even
that might be a bad idea for the sake SIP-XMPP gateways.
RTSP could spare multiple components if it forces RTCP-mux when RTSP-ICE
transport is used.
... and they investigate this without having a NICE document.
Avoiding being too focused in the ICE specification when it comes to the
usage of SIP could have been nice but that hasn't caused too many
problems -- just took longer to read it. Since you have to read through
the specification anyway when you want to make use of ICE I doubt that
items (1)-(4) from your list below would provide any more insight.
So, who would make use of this document?
You have a point that there aren't that many protocols at this point. I wonder
if there is any interest in ICE outside IETF and XSF protocols... Anybody
heard of any?
When you look around then the Internet is not going towards a waist like
described in draft-rosenberg-internet-waist-hourglass-00 but rather a
model where the new waist is HTTP
So, do you think that there will be many protocols in the future with
the characteristics required by ICE?
Ciao
Hannes
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic