[Standards] Jingle: content-replace during PENDING state

[Peter Saint-Andre]

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

--
Peter Saint-Andre
https://stpeter.im/

[Robert McQueen]

Peter Saint-Andre wrote:
> 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).

+1 from me. My gut feeling is that content-replace is more of a content
apocalypse in terms of implementations. I don't think it's reasonable to
expect people to have to diff content descriptions and transports in
normal operation - it should have a similar semantic/behaviour as
content-remove and content-add delivered simultaneously.

> Peter

Regards,
Rob

[Paul Witty]

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

[Peter Saint-Andre]

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/

[Paul Witty]

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

[Peter Saint-Andre]

On 05/28/2008 12:44 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> 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).
>
> +1 from me. My gut feeling is that content-replace is more of a content
> apocalypse in terms of implementations. I don't think it's reasonable to
> expect people to have to diff content descriptions and transports in
> normal operation - it should have a similar semantic/behaviour as
> content-remove and content-add delivered simultaneously.

Hmm.

I agree that content-replace should be equivalent to simultaneous
content-remove and content-add. I thought it was, but perhaps I was
wrong. :)

However, it seems that we need content-replace during PENDING in order
to handle certain fallback use cases (see the thread on Jingle file
transfer). I am going to update XEP-0234 to use this model so that we
can see if it will solve the fallback problem in a more elegant way. If
so, I may request that we allow content-replace during PENDING.

More soon. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/