Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt

Christian Groves <Christian.Groves@nteczone.com> Fri, 09 October 2015 02:55 UTC

Return-Path: <Christian.Groves@nteczone.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 528781B2C27 for <mmusic@ietfa.amsl.com>; Thu, 8 Oct 2015 19:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 toD6FDh-Djwt for <mmusic@ietfa.amsl.com>; Thu, 8 Oct 2015 19:55:04 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986D01B2C11 for <mmusic@ietf.org>; Thu, 8 Oct 2015 19:55:04 -0700 (PDT)
Received: from ppp118-209-33-227.lns20.mel4.internode.on.net ([118.209.33.227]:52614 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <Christian.Groves@nteczone.com>) id 1ZkNpl-002XsW-Kc for mmusic@ietf.org; Fri, 09 Oct 2015 13:55:01 +1100
To: mmusic@ietf.org
References: <20151006180954.4556.83199.idtracker@ietfa.amsl.com> <BBE9739C2C302046BD34B42713A1E2A22E7AC2B5@ESESSMB105.ericsson.se>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <56172C7F.6040802@nteczone.com>
Date: Fri, 9 Oct 2015 13:54:55 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <BBE9739C2C302046BD34B42713A1E2A22E7AC2B5@ESESSMB105.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/gHfZVBX7_9zhEy4og6YArmrR8ng>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 09 Oct 2015 02:55:07 -0000

Hello Bo,

I think the updated draft captures most of my earlier comments regarding 
the stream version/alternatives etc.
One place that may be worth updating still is cl.6.1.2. It talks about 
stream formats as being alternatives but does not talk about offerers or 
answerers being prepared to send/receive multiple concurrent streams.

Also just to reinforce the terminology it may be good to change the ABNF 
from "sc-dir-list" to "sc-str-list" indicate "simultaneous streams", eg.
sc-attr     = "a=simulcast:" 1*3( WSP sc-str-list )
sc-str-list = sc-dir WSP sc-id-type "=" sc-alt-list *( ";" sc-alt-list )

Nit: There a WSP that should be removed after the colon in all the 
figures with a=simulcast: .

Regards, Christian
On 8/10/2015 1:59 AM, Bo Burman wrote:
> The main update in this version is to introduce use of RTP stream ID (RID) as identifier in addition to SDP format (RTP payload type), and aligns its use in simulcast with that draft (draft-pthatcher-mmusic-rid-00).
>
> Summary of changes from -01:
>
>     o  Relying on the new RID solution for codec constraints and
>        configuration identification.  This has resulted in changes in
>        syntax to identify if pt or RID is used to describe the simulcast
>        stream.
>
>     o  Renamed simulcast version and simulcast version alternative to
>        simulcast stream and simulcast format respectively, and improved
>        definitions for them.
>
>     o  Clarification that it is possible to switch between simulcast
>        version alternatives, but that only a single one be used at any
>        point in time.
>
>     o  Changed the definition so that ordering of simulcast formats for a
>        specific simulcast stream do have a preference order.
>
>
> There are still a few open issues that need discussion (also included as editor's notes, except for the last one):
>
> 1) There is currently the possibility to set a simulcast as "sendrecv", but this is not a good match considering the uni-directionality of both PT and RID simulcast stream identifiers. I expect some complexity in this mismatch, requiring additional description, but was not able to investigate it further. It is also just an optimization to save a few bytes of SDP text in case simulcast send and receive direction is exactly the same for a certain simulcast stream identifier. I propose to remove "sendrecv" and just keep "send" and "recv", for simplicity.
>
> 2) There is a brief section on declarative use in SDP, but the RID specification currently lacks this, so it is not really possible to define in a good way. Should we add declarative use to RID, or should it be removed here?
>
> 3) With the chosen approach (only defining simulcast on SDP media level), it is not possible to spread simulcast streams onto different media transports, thus also making it impossible to use different flow-based QoS, or separate simulcast streams onto different multicast groups. Since this is described as being one potential motivation for using simulcast, either we have to state that the current solution deliberately does not deal with it, remove that motivation, or add the possibility for media transport separation of simulcast streams. The latter approach could possibly involve defining use of the simulcast attribute on SDP session level.
>
> 4) Since there are two alternative ways of identifying simulcast streams, should we require all implementations of simulcast to support both, or is one mandatory, and how is use of the optional one negotiated in that case?
>
> Cheers,
> Bo
>
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>> Sent: den 6 oktober 2015 20:10
>> To: i-d-announce@ietf.org
>> Cc: mmusic@ietf.org
>> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>   This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>>
>>          Title           : Using Simulcast in SDP and RTP Sessions
>>          Authors         : Bo Burman
>>                            Magnus Westerlund
>>                            Suhas Nandakumar
>>                            Mo Zanaty
>> 	Filename        : draft-ietf-mmusic-sdp-simulcast-02.txt
>> 	Pages           : 24
>> 	Date            : 2015-10-06
>>
>> Abstract:
>>     In some application scenarios it may be desirable to send multiple
>>     differently encoded versions of the same media source in different
>>     RTP streams.  This is called simulcast.  This document discusses the
>>     best way of accomplishing simulcast in RTP and how to signal it in
>>     SDP.  A solution is defined by making an extension to SDP, and using
>>     RTP/RTCP identification methods to relate RTP streams belonging to
>>     the same media source.  The SDP extension consists of a new media
>>     level SDP attribute that expresses capability to send and/or receive
>>     simulcast RTP streams.  RTP/RTCP identification using either payload
>>     types or a separately defined method for RTP stream configuration are
>>     defined.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-02
>>
>>
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are
>> available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>