Subject: [dispatch] Media Stream related signaling

From: Bo Burman <[email-masked]>
Date: Mon, 23 Jan 2012 16:50:24 +0100

Dispatch,

We have requested agenda time for the upcoming meeting to discuss the subject of Media Stream related signaling. From the feedback we got in AVTEXT WG on the discussion for a certain problem, the one related to pausing and resuming sender to middlebox media traffic, it is clear that a more high level discussion needs to happen.

We have two Internet drafts related to the issues we would like to discuss.
Media Stream Selection (MESS)
 - draft-westerlund-dispatch-stream-selection-00
RTP Media Stream Pause and Resume
 - draft-westerlund-avtext-rtp-stream-pause-00

The first one (MESS) proposes that for the general selection of media streams, an end-point within a centralized conferencing scenario desires to receive a media plane oriented rather than RTP/RTCP based signaling, which appears to have benefits as discussed in the draft.

As mentioned, the pause resume draft is targeted for a different use case where a media plane solution has potential for other benefits. This was discussed and the main outcome of that discussion was three quite different opinions;

a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-rate value to 0, which the current specs doesn't allow.

b) This should be done in signalling plane, RTP/RTCP shouldn't be bloated. (But I did interpret this as not necessarily needing to be SIP).

c) When it comes to pause/resume, unless it is done using SIP/SDP it will not work through any Session Border Gateway as the session will be torn down after n seconds.

Thus I think it important that we take a discussion around the use cases, existing solutions, limitations in those or the proposal to try to determine what is the most reasonable way of solving the problems and how to enable;

1) Receiver based selection of media streams from a larger set of streams, including different quality levels like video resolutions, in a centralized conferencing application.

2) Optimize the transport so that media streams currently not used can be turned off temporarily and then quickly resumed when someone determines a need for the media stream. For example using mechanism (1) but also for voice activity based, centrally controlled or other mechanisms to select which media streams are delivered to other session participants.

We are working to revise our Internet drafts. We seek as much input as possible into this prior to the meeting so that we can ensure that any discussion are as on topic and focused as possible.

Regards

Bo Burman & Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7141311
Färögatan 6                | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com
----------------------------------------------------------------------

---

From: Michael Hammer <[email-masked]>
Date: Mon, 23 Jan 2012 11:44:00 -0500

Bo,

Rather than "turning [the media] stream off temporarily", you should
consider putting the media stream into a low energy state, which would not
be bit rate = 0 but would have some limited keep-alive stream that the SBC
recognizes to keep the pinhole open.

There are probably multiple ways to make that happen.  Hope that is
semantically what you meant.

Mike

On Mon, Jan 23, 2012 at 10:50 AM, Bo Burman <[email-masked]> wrote:

> Dispatch,
>
> We have requested agenda time for the upcoming meeting to discuss the
> subject of Media Stream related signaling. From the feedback we got in
> AVTEXT WG on the discussion for a certain problem, the one related to
> pausing and resuming sender to middlebox media traffic, it is clear that a
> more high level discussion needs to happen.
>
> The first one (MESS) proposes that for the general selection of media
> streams, an end-point within a centralized conferencing scenario desires to
> receive a media plane oriented rather than RTP/RTCP based signaling, which
> appears to have benefits as discussed in the draft.
>
> As mentioned, the pause resume draft is targeted for a different use case
> where a media plane solution has potential for other benefits. This was
> discussed and the main outcome of that discussion was three quite different
> opinions;
>
> a) We already do this signaling using TMMBR (RFC 5104) by setting the
> bit-rate value to 0, which the current specs doesn't allow.
>
> b) This should be done in signalling plane, RTP/RTCP shouldn't be bloated.
> (But I did interpret this as not necessarily needing to be SIP).
>
> c) When it comes to pause/resume, unless it is done using SIP/SDP it will
> not work through any Session Border Gateway as the session will be torn
> down after n seconds.
>
> Thus I think it important that we take a discussion around the use cases,
> existing solutions, limitations in those or the proposal to try to
> determine what is the most reasonable way of solving the problems and how
> to enable;
>
> 1) Receiver based selection of media streams from a larger set of streams,
> including different quality levels like video resolutions, in a centralized
> conferencing application.
>
> 2) Optimize the transport so that media streams currently not used can be
> turned off temporarily and then quickly resumed when someone determines a
> need for the media stream. For example using mechanism (1) but also for
> voice activity based, centrally controlled or other mechanisms to select
> which media streams are delivered to other session participants.
>
> We are working to revise our Internet drafts. We seek as much input as
> possible into this prior to the meeting so that we can ensure that any
> discussion are as on topic and focused as possible.
>
> Regards
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Bo Burman <[email-masked]>
Date: Tue, 24 Jan 2012 09:22:22 +0100

Hi Mike,

yes, that is in principle what was intended with "pause" - something that is as low energy as possible but that is readily available and can be quickly and efficiently resumed when needed again.

We did think about what to send instead of the paused media. It is however not clear to us if it will be sufficient to use e.g. ICE or RTP-RTCP Mux as keepalive to make the SBC keep the pinhole, or if it will be necessary to use actual RTP media packets to create a keepalive stream. That is also the case when neither ICE nor RTP-RTCP Mux are used. Any ideas?

BR
/Bo

________________________________
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, January 23, 2012 5:44 PM
To: Bo Burman
Cc: [email-masked]
Subject: Re: [dispatch] Media Stream related signaling

Bo,

Rather than "turning [the media] stream off temporarily", you should consider putting the media stream into a low energy state, which would not be bit rate = 0 but would have some limited keep-alive stream that the SBC recognizes to keep the pinhole open.

There are probably multiple ways to make that happen.  Hope that is semantically what you meant.

Mike

On Mon, Jan 23, 2012 at 10:50 AM, Bo Burman <[email-masked]<mailto:[email-masked]>> wrote:
Dispatch,

Regards

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7141311<tel:%2B46%2010%207141311>
Färögatan 6                | Mobile +46 73 0949021<tel:%2B46%2073%200949021>
SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com<http://ericsson.com>
----------------------------------------------------------------------

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Roni Even" <[email-masked]>
Date: Tue, 24 Jan 2012 13:02:04 +0200

Hi,

About

I am not sure why? The text in 3.5.4 "The limit may change to any value
between zero and the session maximum, as negotiated during session
establishment
   signaling." And there is also the message format in section 4.2.1.1
allows the value of 0

Thanks
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bo Burman
> Sent: Monday, January 23, 2012 5:50 PM
> To: [email-masked]
> Subject: [dispatch] Media Stream related signaling
> 
> Dispatch,
> 
> pausing and resuming sender to middlebox media traffic, it is clear
> that a more high level discussion needs to happen.
> 
> streams, an end-point within a centralized conferencing scenario
> desires to receive a media plane oriented rather than RTP/RTCP based
> signaling, which appears to have benefits as discussed in the draft.
> 
> As mentioned, the pause resume draft is targeted for a different use
> case where a media plane solution has potential for other benefits.
> This was discussed and the main outcome of that discussion was three
> quite different opinions;
> 
> b) This should be done in signalling plane, RTP/RTCP shouldn't be
> bloated. (But I did interpret this as not necessarily needing to be
> SIP).
> 
> c) When it comes to pause/resume, unless it is done using SIP/SDP it
> will not work through any Session Border Gateway as the session will be
> torn down after n seconds.
> 
> Thus I think it important that we take a discussion around the use
> cases, existing solutions, limitations in those or the proposal to try
> to determine what is the most reasonable way of solving the problems
> and how to enable;
> 
> 1) Receiver based selection of media streams from a larger set of
> streams, including different quality levels like video resolutions, in
> a centralized conferencing application.
> 
> 2) Optimize the transport so that media streams currently not used can
> be turned off temporarily and then quickly resumed when someone
> determines a need for the media stream. For example using mechanism (1)
> but also for voice activity based, centrally controlled or other
> mechanisms to select which media streams are delivered to other session
> participants.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Jan 2012 13:42:44 +0100

>    signaling." And there is also the message format in section 4.2.1.1

Roni,

Our main argument is that the semantics of TMMBR is not generally
matching the one needed for pause an resume. As indicated in the AVTEXT
slides unless you are absolutely certain that there are no other RTP
entity on the path between the TMMBR issuing and the TMMBR responding
entity using it to set to 0 can cause significant issues for that other
party in that the stream is pause for that entity also.

Another problem with TMMBR is that is has the following NORMATIVE
requirement on how it goes about increasing the bit-rate:

   If the media sender concludes that it can increase the maximum total
   media bit rate value, it SHALL wait before actually doing so, for a
   period long enough to allow a media receiver to respond to the TMMBN
   if it determines that its tuple belongs in the bounding set.   This
   delay period is estimated by the formula:

      2 * RTT + T_Dither_Max,

Thus a receiver should not get media until 2*RTT + T_Dither_Max after it
request "RESUME". But following this clearly makes TMMBR unusable for
PAUSE RESUME. And this is required also in point to point:

   Even in
   point-to-point sessions, a media sender MUST obey the aforementioned
   rule, as it is not guaranteed that a participant is able to determine
   correctly whether all the sources are co-located in a single node,
   and are coordinated.

Thus at a minimum if one like to use TMMBR we need to redefine TMMBR
such that it allows for the functionality. That likely means separating
the two use cases from each other to avoid the risk of miss
classification of topologies. Which from my perspective means different
signalling code-points to make it clear to the end-points what to do.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Jan 2012 09:42:03 +0100

Note - a related draft is this one (expired):

draft-lennox-mmusic-sdp-source-selection-02.txt

It proposes an SDP-based mechanism for turning streams on and off.
This subject has also been discussed in RTCWEB, and may also be in scope 
for CLUE.

           Harald

On 01/23/2012 04:50 PM, Bo Burman wrote:
> Bo Burman&  Magnus Westerlund
>