Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-06

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 Jan 2006 18:52:10 -0800 (PST)

Jonathan,

I have a few questions on media flow setup in ICE.

1. It seems all candidate endpoints  for media (including private endpoint,
STUN derived endpoint and TURN derived endpoint) must be prepared to send and
process STUN Binding requests. 

If this is true, dont you think it is overbearing to require media endpoints to
offer STUN service (irrespective of whehter a node is behind a NAT or not) and
multiplex it with the real media content? 

You suggest a way to distinguish STUN messages from RTP/RTCP data from the
first 2 bits of the RTP/RTCP header. This  can be problematic for other media
stream protocols and in general for other P2P applications. Is ICE intended
principally for use with RTP and RTCP only?

2. Say, the two peering nodes are not behind NAT. In such a case, why should
the media endpoints be required to process STUN messages? That adds no value,
right?

Likewise, say, one of the endpoints is relay endpoint and the other is public
endpoint. Why should either of the endpoints be required to process STUN
messages? I.e., Once again, I donot see the value in exchanging STUN messages
between the endpoints. Might as well not bother with STUN messages and simply
exchange media between the endpoints.

3. Say, both nodes are behind Cone NAT devices. How can you ensure that STUN
Binding request sent by one node is received by the peer node or vice versa.
There is a chance that this might succeed only if they both parties try sending
at the same time. But, I dont see how you can ensure that in that in the
connectivity model.

4. Lastly, if both nodes are behind cone NAT, and each node has 3 candidate
endpoints (private endpoint, STUN derived endpoint and TURN derived endpoint),
I believe, the connection between TURN derived endpoints is most likely to
succeed at the earliest. DO you agree? If not, please explain why.

Thanks.

regards,
suresh

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