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

Peter Saint-Andre <stpeter@stpeter.im> Thu, 20 March 2014 03:39 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650111A07FF for <stox@ietfa.amsl.com>; Wed, 19 Mar 2014 20:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFB7rWh9TpR6 for <stox@ietfa.amsl.com>; Wed, 19 Mar 2014 20:39:11 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 98F651A0496 for <stox@ietf.org>; Wed, 19 Mar 2014 20:39:11 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22D3E4032A; Wed, 19 Mar 2014 21:39:02 -0600 (MDT)
Message-ID: <532A62D5.3060200@stpeter.im>
Date: Wed, 19 Mar 2014 21:39:01 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, stox@ietf.org
References: <E44893DD4E290745BB608EB23FDDB7620A17DC34@008-AM1MPN1-043.mgdnok.nokia.com> <52CEDF2D.9090607@alum.mit.edu>
In-Reply-To: <52CEDF2D.9090607@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/Qce3YB5jynQWojV3ftah38rg5VE
Subject: Re: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 03:39:14 -0000

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