Peter Saint-Andre wrote:
This is the first in my series of posts on Jingle. More soon.
According to version 0.25 of XEP-0166, use of the content-replace action
is forbidden during the PENDING state. However, XEP-0176 (ICE-UDP) uses
the content-replace action during the PENDING state:
http://www.xmpp.org/extensions/xep-0176.html#protocol-acceptance
In XEP-0176, this usage maps to nomination of the candidates to be used
in ICE, see section 2.6 of draft-ietf-mmusic-ice-19.
However, in ICE this nomination is done over STUN, not via SIP/SDP.
Therefore I think the content-replace action is unnecessary in XEP-0176
(since nomination in the Jingle ICE-UDP transport will also occur over
STUN and does not need to happen in the signalling channel).
Unless there are objections, I will update XEP-0176 accordingly (a usage
inherited by some of the examples in XEP-0167 and XEP-0180, which will
be harmonized with the modified XEP-0176).
Peter
Can I just get a bit of clarification about how the initiation should
work, and what part the user plays in accepting the session. If the
session-accept is only sent upon successful completion of ICE, does this
mean that the user should only be alerted about the incoming session
after ICE is complete, to prevent them accepting a session for which the
session-accept will never actually be sent because there are no
acceptable candidates?
Also, when it comes to to sending the session-accept, the completion of
ICE means that we have already accepted a candidate, so explicitly doing
so in the session-accept is redundant. A correct implementation of ICE
will never choose a candidate which will not work for both parties, so
we will never reach the error state in Example 10 of section 5.6.
--
Paul
