Subject: [AVTCORE] FW: [dispatch] Media Stream related signaling

From: "Roni Even" <[email-masked]>
Date: Tue, 24 Jan 2012 11:43:34 +0200

Hi,
I would like to draw your attention to this email that was sent to DISPATCH
mailing list.
Please send any comments to dispatch in order to minimize duplication
Thanks
Roni Even
AVTcor co-chair

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

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch