Peter Saint-Andre wrote:
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.
I see two potential call flows here:
ICE succeeds, the call works, everyone is happy
Romeo Juliet
| |
| session-initiate |
|---------------------------->|
| ack |
|<----------------------------|
| session-info (ringing) |
|<----------------------------|
| ack |
|---------------------------->|
| transport-info (X times) |
| (with acks) |
|<--------------------------->|
| STUN connectivity checks |
|<--------------------------->|
| session-accept |
|<----------------------------|
| ack |
|---------------------------->|
| AUDIO (RTP) |
|<===========================>|
| session-terminate |
|<----------------------------|
| ack |
|---------------------------->|
| |
ICE fails, the call fails, Romeo and Juliet poison themselves
Romeo Juliet
| |
| session-initiate |
|---------------------------->|
| ack |
|<----------------------------|
| session-info (ringing) |
|<----------------------------|
| ack |
|---------------------------->|
| transport-info (X times) |
| (with acks) |
|<--------------------------->|
| STUN connectivity checks |
|<--------------------------->|
| session-terminate |
|<----------------------------|
| ack |
|---------------------------->|
| |
However, in both of these, it makes sense for Juliet to be alerted of
the incoming call at the session-info (ringing) stage (that's what
ringing means, after all). Juliet being twitchy and waiting for Rome to
call, she hits the accept button immediately (i.e. before ICE
concludes). In the first example, that's fine. In the second, Romeo has
initiated a call, Juliet has hit the answer button, but her client sends
a session-terminate message instead.
If my telephone rings, I should be sure that the call will succeed when
I answer it. As the initiator of the content will be the controlling
party for ICE, they will be the one who knows the chosen candidate pair
(at least for aggressive nomination; regular nomination makes it
unambiguous for both parties as only a single STUN request, which is
certain to be received, has the nomination flag). I propose sending a
content-modify after ICE completes from the initiator, which declares
the nominated candidate pair (with information about the nominated pair
being removed from the session-accept), and the called client only
alerting the user and sending the session-info (ringing) after receiving
this message. This is more in line with the ICE draft, which states:
"Once all of the media streams are completed, the controlling endpoint
sends an updated offer if the candidates in the m and c lines for the
media stream (called the DEFAULT CANDIDATES) don't match ICE's SELECTED
CANDIDATES."
We don't send default candidates, because we know beforehand through
service discovery that ICE is supported by the far end, but doing a
content-modify would be in line with the updated offer.
Unfortunately this won't work if we are unwilling to send candidates
before accepting, but such is the price of security.
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.
We will never reach that state. ICE will conclude after the controlling
agent sends a STUN request with the nomination flag, and successfully
receives a response from the controlled agent, which means that media
can flow. The two members of the candidate pair were suggested by the
appropriate ends, so they must be acceptable, and the fact that the STUN
check succeeded means that media can be sent over the selected candidate.
--
Paul
