Re: [Bug 20816] "Hold" unspecified

On 04/19/2013 03:31 PM, Olle E. Johansson wrote:
>
> 19 apr 2013 kl. 15:16 skrev Harald Alvestrand <harald@alvestrand.no 
> <mailto:harald@alvestrand.no>>:
>
>> On 04/19/2013 03:04 PM, José Luis Millán wrote:
>>> Hi,
>>>
>>>
>>>
>>>     Engineering-wise:
>>>
>>>     1) Do you have a definition of what "on hold" means that we can
>>>     refer to? The term does not occur in
>>>     draft-ietf-rtcweb-use-cases-and-requirements.
>>>
>>>     2) Do you know of a consistent specification for how SDP is used
>>>     to achieve "on hold" in other systems, for instance SIP? If so,
>>>     can you point us to that specification?
>>>
>>>     At the moment, I'm not even sure what "on hold" means in terms
>>>     of what media flows cease; in a JS-centric world, another
>>>     implementation that somewhat matches what you describe might be:
>>>
>>>     1) Alice calls "disable" on her outgoing audio and video
>>>     MediaStreamTracks.
>>>
>>>     2) Alice sends a message to Bob informing him that he's on hold
>>>     (through signalling, which is not standardized in WebRTC or RTCWEB).
>>>
>>>     3) Bob calls "disable" on his outgoing audio and video
>>>     MediaStreamTracks.
>>>
>>>
>>>
>>> SDP needs to be mangled to do this AFAIK since not even the W3C 
>>> specification defines how this is done at RTCPeerConnection level.
>>
>> Well, the first thing to define is what needs to be done, and why. In 
>> the sentence above, it's not clear what "this" refers to, even though 
>> you use the word twice.
>>
>> A major reason RTCPeerConnection handles don't exist is because we 
>> don't have a clear specification of what we need handles for.
>>
>> So first:
>>
>> - What do you mean by "hold"?
>> - Where is the specification of how other people are using SDP to 
>> achieve the thing you mean?
>>
>> It's the job of people who want to use SDP mechanisms to achieve 
>> "hold" to make these things clear.
>>
>>
>
> Hold is defined as this in RFC 5359:
>    In this scenario, Alice calls Bob, then Bob places the call on hold.
>     Bob then takes the call off hold, then Alice hangs up the call.  Note
>     that hold is unidirectional in nature.  However, a UA that places the
>     other party on hold will generally also stop sending media, resulting
>     in no media exchange between the UAs.  Older UAs may set the
>     connection address to 0.0.0.0 when initiating hold.  However, this
>     behavior has been deprecated in favor or using the a=inactive SDP
>     attribute if no media is sent, or the a=sendonly attribute if media
>     is still sent.
>
>
> We signal that with a=sendonly/a=recvonly/a=inactive/a=sendrecv in the 
> sdp per stream.

Thanks - so in this definition, "Bob places Alice on hold" means "Bob 
requires Alice to stop sending media to Bob, while Bob may continue to 
send media to Alice".


>
>
> It's documented in RFC 3264 - offer/answer - section 5.1

for "it" = "a=sendonly" and friends - the "hold" mechanism is in section 8.4

>
> There are signalling examples for the SIP protocol in RFC 5359, 
> section 2.1 Call Hold.
>
> RFC 3264 talks about unicast streams:
> 5.1 Unicast Streams
>
>     If the offerer wishes to only send media on a stream to its peer, it
>     MUST mark the stream as sendonly with the "a=sendonly" attribute.  We
>     refer to a stream as being marked with a certain direction if a
>     direction attribute was present as either a media stream attribute or
>     a session attribute.  If the offerer wishes to only receive media
>     from its peer, it MUST mark the stream as recvonly.  If the offerer
>     wishes to communicate, but wishes to neither send nor receive media
>     at this time, it MUST mark the stream with an "a=inactive" attribute.
>     The inactive direction attribute is specified in RFC 3108 [3].  Note
>     that in the case of the Real Time Transport Protocol (RTP) [4], RTCP
>     is still sent and received for sendonly, recvonly, and inactive
>     streams.  That is, the directionality of the media stream has no
>     impact on the RTCP usage.  If the offerer wishes to both send and
>     receive media with its peer, it MAY include an "a=sendrecv"
>     attribute, or it MAY omit it, since sendrecv is the default.
>
> I wonder how this would affect a bundled stream.

Me too. Are there use cases in present deployments where Bob requests 
Alice to stop one or more, but not all streams, and refers to that 
process as "on hold"?

>
> /O