Re: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes

[Peter Saint-Andre <[e-mail]>]

Paul, thanks for the feedback and my apologies for the extremely slow reply.

On 1/9/14, 10:41 AM, Paul Kyzivat wrote:
> As requested, I have taken a look at treatment of Hold in section 6 of
> draft-ietf-stox-media-02.
>
> The draft says:
>
>     The same semantics are also
>     supported by Jingle through the "senders" element and its "initiator"
>     and "responder" values.
>
>                   [example to follow]
>
>     In addition to these semantics however Jingle also defines a more
>     concise way for achieving the same, which consists in sending a
>     "hold" command within a "session-info" action:
>
> Before I can make any useful comments I need to get educated on some
> aspects of xmpp. (I *browsed* XEP 0166, but couldn't quickly figure this
> out.) Hopefully somebody can clue me in on the following:
>
> 1) I see that the "senders" element has values that correspond 1:1 with
> SDP sendrecv/sendonly/recvonly/inactive. Are there equivalent
> constraints on O/A behavior? Specifically that:
>
>      Offer    Permissible Answer
>      -----    ------------------
>      sendrecv sendrecv/sendonly/recvonly/inactive
>      sendonly recvonly/inactive
>      recvonly sendonly/inactive
>      inactive inactive

Although those constraints look reasonable, I think the original Jingle 
authors were not aware of them when defining the protocol. In general, 
Jingle implementations are simpler than SIP implementations, and might 
tend to assume senders='both' / a=sendrecv. Also, not all uses of the 
'senders' attribute quite follow the offer/answer model - see, for 
instance, the content-modify action:

###

The content-modify action is used to change the direction of an existing 
content definition through modification of the 'senders' attribute. If 
the recipient deems the directionality of a content-modify action to be 
unacceptable, it MAY reply with a contrary content-modify action, 
terminate the session, or simply refuse to send or accept application 
data in the new direction. In any case, the recipient MUST NOT send a 
content-accept action in response to the content-modify.

###

> 2) Are the "senders" element values semantically equivalent to the
> corresponding SDP attributes in their implications to how the
> corresponding RTP stream is used?

As far as I understand those implications, yes.

> 3)) What are the precise semantics of the "hold" command within a
> "session-info" action?

Those are defined in XEP-0167 for RTP sessions (not in the core Jingle 
spec):

###

The <hold/> payload indicates that the principal is temporarily not 
listening for media from the other party. It is RECOMMENDED for the 
parties to handle informational <hold/> messages as follows (where the 
holdee is the party that receives the hold message and the holder is the 
party that sends the hold message):

   *  The holdee SHOULD stop sending media.
   *  The holdee MUST keep accepting media (this ensures that the holder 
can immediately start sending media again when switching back from hold 
to active, or can send hold music or other media).
   *  The holder MAY continue to send media (e.g. hold music).
   *  The holder MAY silently drop all media that it receives from the 
holdee.

###

- http://xmpp.org/extensions/xep-0167.html#info-hold

> Is it formally equivalent to "initiator" on every
> media session?

Hmm, not quite, because either party can send a hold payload, and the 
semantics of the hold depend on who is sending it.

In any case, as I recall from the discussion in Vancouver, we were 
trying to formulate a recommended approach based on the behavior of 
existing Jingle implementations. I think we still need to do a bit of 
field research to figure out what's most prevalent (e.g., using 
'senders' or the informational hold message).

Emil, what does Jitsi do? Are you aware of how other implementations behave?

Peter