Subject: [MMUSIC] ICE-10: SIP Interaction with preconditions

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 13 Sep 2006 10:58:41 +0200

Hi,

Chapter 12.3 says:

"Indeed, an agent SHOULD NOT indicate that Qos preconditions have been
met until the ICE checks have completed and selected the candidate
pairs to be used for media."

Later, there is an open issue saying:

"OPEN ISSUE: Are these preconditions really needed with ICE? ICE
provides a connectivity precondition on its own using the
mechanisms described above."

It seems like the text assumes that preconditions is only about
end-to-end resource reservation. But, please don't forget the terms
"local" and "remote" used in precondtions. 

I think we need need to think about the case where one or more of the
STUN servers can not even be reached before the preconditions have been
met. Currently the text seems to assume that they can always be reached
at any time. Especially a STUN relay media server may not always be
reachable, since preconditions normally are assoicated with the
establishment of media bearer resources.

So, assuming one or more of the STUN servers can not be reached before
the preconditions are met, it is not possible to include a candidate for
them in the first SDP offer(s).

The question is what we do then:

1. We don't include any candidates until the preconditions have been
met. This is a case where it perhaps would be useful to have an
option-tag to indicate that the offerer still supports ICE).

2. We include the candidates we can retreive for the moment, and "add"
more candidates later. Now, the question is how useful this would be,
assuming that one of the previously included candidates have resulted in
a positive connectivity check.

3. We only use the candidates which are retrievable once the initial
offer (or, at least the initial set of candidates) are sent.

Regards,

Christer

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