[dispatch] Media Stream related signaling

Bo Burman <bo.burman@ericsson.com> Mon, 23 January 2012 15:50 UTC

From: Bo Burman <bo.burman@ericsson.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Date: Mon, 23 Jan 2012 16:50:24 +0100
Thread-Topic: Media Stream related signaling
Thread-Index: AczZ5rhYJCBqmo1vRaCfF/ps/EzATQ==
Message-ID: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dispatch] Media Stream related signaling
Precedence: list

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

[dispatch] Media Stream related signaling Bo Burman
Re: [dispatch] Media Stream related signaling Michael Hammer
Re: [dispatch] Media Stream related signaling Bo Burman
Re: [dispatch] Media Stream related signaling Roni Even
Re: [dispatch] Media Stream related signaling : W… Magnus Westerlund
Re: [dispatch] Media Stream related signaling Harald Alvestrand