Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources

"Roni Even" <ron.even.tlv@gmail.com> Wed, 17 July 2013 05:36 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F94921F8925 for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 22:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Level:
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTezkAVyoHuS for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 22:36:24 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5822821F8904 for <mmusic@ietf.org>; Tue, 16 Jul 2013 22:36:24 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id ey16so4942211wid.15 for <mmusic@ietf.org>; Tue, 16 Jul 2013 22:36:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=LuqGbBAw/ExCOVV5awvgmAtmxNtz2KJ7i29qomlSZlI=; b=GlfE0Gp/SFfPJ89ZQpi2nq5aP7znks6pj7uPpIMkJ6buuBt9iEMx+OPVDnS75uhAhF wUEnuKXe1FaBHdzlPN2Xb5DAt2MM84prMZ6NCxiENGlsjqJo1d2q5jQcAkSpqvbmfOQh ttTjjO+GODQ4xsSQyj2SsanzgXQJ8qkcl96V5RvMHtZyoZ9WWm7t5ljUBLOjkSjDpQxW p5GrpzfqEEKKOBL8F4G2NuadTqC3Rk/KwAh/avjEKlqG2FIQ03oHvn2YW+A+rJa/TD0e Ay5AU3yBsFBCLj6XfDi7BBbYJ/ApD2x+3aFKG4Lh/US+iCT76tc5ko/gQ+Iz6rUrB4gU DhdQ==
X-Received: by 10.194.78.110 with SMTP id a14mr3543675wjx.84.1374039383453; Tue, 16 Jul 2013 22:36:23 -0700 (PDT)
Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id o10sm6983787wiz.5.2013.07.16.22.36.21 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 22:36:22 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Adam Roach' <adam@nostrum.com>
References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com>
In-Reply-To: <51E5C863.7000101@nostrum.com>
Date: Wed, 17 Jul 2013 08:34:34 +0300
Message-ID: <011301ce82af$534d5df0$f9e819d0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI2iPpx0KPLPKa3FH2FT2Jx+TgF4AKbyZlZmINoo1A=
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 17 Jul 2013 05:36:25 -0000

I think that the problem in bullet 2 of section 2  when reading bullet 1 is
that it is not clear. Bullet 1 says "nor may a single m-line    represent
multiple media stream tracks".  Since there is no definition of media stream
track in this document and of source I looked at section 2.3 of
http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01
which tries to clarify the terminology based on existing documents. 
To me even though bullet 2 says "in the absent of other signaled extension"
it will be not correct according to bullet 1 to have one m-line that have
multiple sources (according to my reading of the taxonomy source and media
stream track are equivalent)

As for "although senders can   switch between the SSRCs as frequently as
desired, only one    should be sent at any given time." It got me confused,
in simulcast  does it mean that a sender can send one packet of one
resolution followed by a packet of a second resolution each has a unique
SSRC but they should have a different timestamp. What is "at any given
time"?

Roni

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: 17 July, 2013 1:26 AM
> To: Roni Even
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media
> sources
> 
> On 7/16/13 16:48, Roni Even wrote:
> > Hi,
> > Some comments.
> > In section 2 bullet 2 is changing RFC 5576 semantics and not for good.
> > Why do you want more than one SSRC for m-line but allow only one at a
> > time, is this for the simulcast case?
> 
> No, simulcast is signaled explicitly (I will point out and emphasize the
phrase
> "absent any other signaled extension"). This is "default behavior" is
intended
> to accommodate MCUs that perform packet switching for RTP (and similar
> architectures that require different timing and/or sequence number spaces
> on a single stream).
> 
> > Others which are not on section 2
> >
> /a