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

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

Old thread alert!

On 3/25/14 2:50 AM, Saúl Ibarra Corretgé wrote:
> Hi,
>
> On Mar 20, 2014, at 4:39 AM, Peter Saint-Andre wrote:
>
>> 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:
>>
>
> 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."

True.

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

In part it's optional because it has a default value of "both" (if the 
'senders' attribute is not included, "both" applies).

Looking at this again, I think the constraints that Jonathan mentions 
are fine, and of course they're consistent with RFC 3264, too.

The only tricky bit is how to handle the content-modify action in 
Jingle, since it could be used to do something like change 'senders' 
from "initiator" ( = sendonly) to "responder" ( = recvonly) and AFAIK 
that's not something you can do in offer/answer without sending a new 
offer (and in Jingle it can be done mid-session, not in response to the 
original offer).

Peter

-- 
Peter Saint-Andre
https://andyet.com/