On 06/04/2008 9:00 AM, Paul Witty wrote: > 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?
The protocol-level session-accept is different from the user-level button-click involved in making a go/no-go decision about whether the user wants to "pick up the phone" or whatever. I imagine that the client will show the user some kind of interface that requires user interaction to approve the session request after sending the initial ack of the session-initiate and before sending the session-accept. However I suppose that the client should not send the session-accept before the user has had a chance to click the big "accept this call" button. > 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. We will never reach that error state or we should never reach that error state? I like to spec out all eventualities, even if we never "should" get to that point. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
