IETF Logo Mail Archive

Re: [MMUSIC] comments on draft-even-mmusic-application-token-01

"Roni Even" <ron.even.tlv@gmail.com> Thu, 31 October 2013 16:40 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 6DB3211E8117 for <mmusic@ietfa.amsl.com>; Thu, 31 Oct 2013 09:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level:
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 XWad9KlWE1xd for <mmusic@ietfa.amsl.com>; Thu, 31 Oct 2013 09:40:53 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1121F9DCF for <mmusic@ietf.org>; Thu, 31 Oct 2013 09:40:52 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id c11so2959523wgh.2 for <mmusic@ietf.org>; Thu, 31 Oct 2013 09:40:51 -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:thread-index :content-language; bh=AKrM17EqjZjhWUOObfIZSTt/fZp+KU5+ceetjZfDZfo=; b=OsWqRcUEljZlTWoPEFJHsDvFMskDCyEfVx1LPceJYrXKYhlbIi4rujQuDKV4f0xC46 D6qO0zH4gscCWyLjHdopbrrFmyHNGBXSU9S+V3admN6UVSP2m+1XEi7qF3nq49xFZUJZ SuEADtQgPRnpjaz8F2ux4XARFqB38ku3VamlVU28vuqMgEsYr/hNrhFqEkc1LwIJmYXR JWQQmeNi6Fnj0ZQ+9Q+hCYzyAiNr9Gcl34iZUkO/I9Hi6p0TxRllw72aMA1gPAxw4tRS 9CiRXzk+GL9CMuSPUUfUQ0oy5rEwV6yspy2UhSBSJl7YzAuEk3zk/2dbQ0N/xN05aF1w uRzQ==
X-Received: by 10.180.90.177 with SMTP id bx17mr142321wib.55.1383237651756; Thu, 31 Oct 2013 09:40:51 -0700 (PDT)
Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id b7sm8425515wiz.8.2013.10.31.09.40.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Oct 2013 09:40:51 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Martin Thomson' <martin.thomson@gmail.com>, 'Jonathan Lennox' <jonathan@vidyo.com>
References: <526D5CDD.40805@alum.mit.edu> <CABkgnnVekG9bDbO7mvNPcKHH1w3JmvKTcT2K=D1-ERW-vr2GLA@mail.gmail.com> <526D8FA3.1030503@alum.mit.edu> <CABkgnnXTYCx8uWZPUq7KgGdSr1w64kq_SCTDVP56p5DEjaYj3g@mail.gmail.com> <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com> <CABkgnnVFkay_iM2_O9xdfm8ZVxgKX3Etk272Hv0VTKhTEZCYng@mail.gmail.com> <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com> <CABkgnnXWEEC2LigE+CnEL6rdM5TLeNX_+JV0i4r_oiEh_gqJLw@mail.gmail.com>
In-Reply-To: <CABkgnnXWEEC2LigE+CnEL6rdM5TLeNX_+JV0i4r_oiEh_gqJLw@mail.gmail.com>
Date: Thu, 31 Oct 2013 18:37:35 +0200
Message-ID: <00c901ced657$83b6fef0$8b24fcd0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6iXv0c6W9apn1bzhH/0GpTiVp7gIEvfvRAp4w7t8B8NJj/gJe/nO0Al9VIzsCUToXgQLiKcF3Aw7IiD4Bss3UqZgNXkLQ
Content-Language: en-us
Cc: mmusic@ietf.org, 'Paul Kyzivat' <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
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: Thu, 31 Oct 2013 16:40:53 -0000

Hi guys,
I am not sure about having the same appId for multiple media streams
One example you gave is FEC. Assume that we have a "unified" offer with a simulcast source with two simulcast configuration (low res and high res) each will have a different appId and one repair stream for both. What appID to use.
Same applies for layered codec when you have a base layer enhancement layer and one repair stream (this is even more realistic than the simulcast case)
Roni

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: 30 October, 2013 12:01 AM
> To: Jonathan Lennox
> Cc: Paul Kyzivat; Roni Even; <mmusic@ietf.org>
> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
> 
> On 29 October 2013 14:34, Jonathan Lennox <jonathan@vidyo.com> wrote:
> >> - at any point in time each appid token maps to at most  one stream
> >> (SSRC) within the session.
> >
> > This one isn't right.  An appid maps to at most one *source* -- but in
> situations where multiple streams (SSRCs) make up one source, in some cases
> we'll want them to be associated by having them have the same appid.
> 
> Thanks Jonathan, I had hoped that this was the intended answer.  It's the only
> one that makes any sense.
> 
> > In particular, I think, RTX and single-stream-repair FEC streams
> > should probably be associated to their primary stream using appid.
> > (Multi-stream-repair FEC is more complicated, as the draft discusses.
> > Yes, we probably shouldn't have jumped to the more complicated case so
> > quickly in the examples.)
> 
> The SDES extension or RTP extension could identify an SSRC as contributing to
> multiple sources in those complicated scenarios.  The simple case is where
> each SSRC contributes to just a single source.
> Maybe that's too much information for an RTP extension, in which case you
> could send the appid indications for each source a) when the contribution
> commences - i.e., at the start of transmission; and b) interleaved when there is
> more than one appid.  That assumes that the SSRC can't ever stop contributing
> to a given source, which I think is a safe assumption.

v2.23.0 | Report a Bug | By Email