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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Mar 2014 21:39:01 -0600

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 25 Mar 2014 09:50:40 +0100

Hi,

On Mar 20, 2014, at 4:39 AM, Peter Saint-Andre wrote:

> 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:
> 

Hum. Actually the XEP does mention compatibility with SDP O/A model: 

"Which parties in the session will be generating content (i.e., the direction in which a Jingle session is active); the allowable values are "both", "initiator", "none", and "responder" (where the default is "both"). Note that the defined values of the 'senders' attribute in Jingle correspond to the SDP attributes of "sendrecv", "sendonly", "inactive", and "recvonly" defined in RFC 4566 [30] and used in the offer-answer model RFC 3264."

However that element is *optional* except for content-modify. IIRC we did discuss about recommended practices, since this didn't seem to be very used out there. FWIW, when I worked on the SIP-XMPP gateway functionality for SylkServer I relied solely on session-info with 'hold'. This does of course limit the possible translation scenarios (ie, starting a session with a=inactive) though.

--
Saúl Ibarra Corretgé
AG Projects