Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast
Bernard Aboba <bernard_aboba@hotmail.com> Tue, 03 December 2013 02:14 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116481AE00B for <mmusic@ietfa.amsl.com>; Mon, 2 Dec 2013 18:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.7
X-Spam-Level: *
X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufxBSbVc-nYf for <mmusic@ietfa.amsl.com>; Mon, 2 Dec 2013 18:14:35 -0800 (PST)
Received: from blu0-omc1-s3.blu0.hotmail.com (blu0-omc1-s3.blu0.hotmail.com [65.55.116.14]) by ietfa.amsl.com (Postfix) with ESMTP id 892141ADFAD for <mmusic@ietf.org>; Mon, 2 Dec 2013 18:14:35 -0800 (PST)
Received: from BLU169-W50 ([65.55.116.7]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 18:14:33 -0800
X-TMN: [aWpbpCq3UnuBXxNSgexZra1yTqI8pswN5Pa9y3vudTY=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W50E9616D0C637AE556A30793D50@phx.gbl>
Content-Type: multipart/alternative; boundary="_0f31c3b4-696b-4482-a758-6954e2600409_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Bo Burman <bo.burman@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Mon, 02 Dec 2013 18:14:32 -0800
Importance: Normal
In-Reply-To: <BLU169-W1237C68C1A3C558FB55021D93D50@phx.gbl>
References: <BLU169-W11468829F05B411E43D51E693EE0@phx.gbl>, , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, <BLU169-W119ED7AA7ACE6A2FC53A4CE93E80@phx.gbl>, <BBE9739C2C302046BD34B42713A1E2A22E061AB2@ESESSMB105.ericsson.se>, <BLU169-W1237C68C1A3C558FB55021D93D50@phx.gbl>
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Dec 2013 02:14:33.0550 (UTC) FILETIME=[682DF6E0:01CEEFCD]
Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 02:14:37 -0000
Bo Burman said: "Should a simulcast-capable endpoint be restricted to be a simulcast-sender-only or a simulcast-receiver-only, or do we envision endpoints that are capable of both sending and receiving simulcast? One example would be if simulcast streams are to be forwarded between different SFU (using Bernard’s terminology below). If so and assuming that we define a new 5888-type simulcast grouping, do we need separate groupings for send direction simulcast and receive direction simulcast, or is a=sendonly and a=recvonly information for simulcast-grouped media blocks fully sufficient? Also, I think the way to use this approach for simulcast in combination with multiple separate media sources (like multiple cameras) or media sinks (like multiple displays) would be pretty straightforward; just add one simulcast grouping per media source/sink." [BA] In the case where parallel simulcast streams are being both sent and received (e.g. between SFUs), there wouldn't be a need for a=sendonly or a=recvonly lines; each m=line would apply to both sending and receiving. So it seems like a single simulcast group would suffice. If you have multiple sources or sinks, then yes, I believe you would have one simulcast grouping per media source/sink. A simple SFU1-SFU2 exchange would look like this: Offer: v=0 o=SFU1 2362969037 2362969040 IN IP4 192.0.2.156 s=Simulcast Enabled SFU1 t=0 0 c=IN IP4 192.0.2.156 b=AS:665 a=group:SC S1 S2 m=video 49300 RTP/AVP 97 b=AS:520 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42c01e a=imageattr:97 send [x=640,y=360] a=mid:S1 m=video 49302 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42c01e a=imageattr:98 send [x=320,y=180] a=mid:S2 Answer: v=0 o=SFU2 823479283 1209384938 IN IP4 192.0.2.2 s=Answer to Simulcast Enabled SFU1 t=0 0 c=IN IP4 192.0.2.43 b=AS:665 a=group:SC S1 S2 m=video 48000 RTP/AVP 97 b=AS:520 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42c01e a=imageattr:97 recv [x=640,y=360] a=mid:S1 m=video 48002 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42c01e a=imageattr:98 recv [x=320,y=180] a=mid:S2
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bo Burman
- [MMUSIC] Simplifying draft-westerlund-avtcore-rtp… Bernard Aboba
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Christer Holmberg
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bernard Aboba
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Christer Holmberg
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bo Burman
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bernard Aboba
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bernard Aboba
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Christer Holmberg
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bernard Aboba
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bernard Aboba
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Paul Kyzivat
- Re: [MMUSIC] Simplifying draft-westerlund-avtcore… Bernard Aboba