IETF Logo Mail Archive

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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 29 October 2013 15:36 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 7AF4521E8151 for <mmusic@ietfa.amsl.com>; Tue, 29 Oct 2013 08:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.06
X-Spam-Level:
X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
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 nGIIvdNRLqZv for <mmusic@ietfa.amsl.com>; Tue, 29 Oct 2013 08:36:02 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF2421E8160 for <mmusic@ietf.org>; Tue, 29 Oct 2013 08:36:01 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id j0Jf1m0040QuhwU513c0oc; Tue, 29 Oct 2013 15:36:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id j3c01m00V3ZTu2S3N3c0WW; Tue, 29 Oct 2013 15:36:00 +0000
Message-ID: <526FD5E0.6010202@alum.mit.edu>
Date: Tue, 29 Oct 2013 11:36:00 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>, 'Martin Thomson' <martin.thomson@gmail.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>
In-Reply-To: <023801ced464$91e97f60$b5bc7e20$@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383060960; bh=FZA5DWUqMnW4Jf6gJlBUr3h+8eJTPWVFplSsUFT3GQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g7M3dEq3mdPTElkPj3YuwDbSMBKyPr5fndai+M3KimOxwID6wXURb8U6UWXuhC+jP 5lCpdx8akoACcQ37M3a4qZR14bmfht6S0gumvmO3Zi8ia44KSUA6+EIgbn1bhW//kW ZvII1cm6Orh/DSZvp8pgaSTNNBXDD//nIAo4YaSedBdVaBSgcgKkOTlDuTS5jHHQVS 7y+qjwMRiRMaPganR/z4Zm2MDO6NyuzDBvDETJiA48fiF/XttzJTB679dqpOW8QIvI FX8j5CZMnUMWvY6yGrZ8zM2gNGITDDMd/sjwR5veN2os9cIVhbH0TXO+TohUZ4Gr88 aNZ8s+9gE3ICQ==
Cc: mmusic@ietf.org
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: Tue, 29 Oct 2013 15:36:07 -0000

Roni,

I'm still not sure I understand. I'm going to repeat my characterization 
about what I understand one more time:

- an RTP session MAY have one or more appid tokens
- at any point in time each appid token maps to at most
   one stream (SSRC) within the session.
- *new* appid:ssrc mappings MAY be initialized via SDP
- new appid:ssrc mappings MAY be initialized via receipt
   of the new RTPC SDES message or header extension
- existing appid:ssrc mappings MAY be updated via
   receipt of the new RTCP SDES message or header extension.

Can you either confirm the above is correct, or else update it so it is 
correct?

	Thanks,
	Paul


On 10/29/13 1:06 AM, Roni Even wrote:
> Martin,
> 1. My understanding that unified is only applicable to RTCweb but not a general MMUSIC solution. A singe media stream per m-line that may be grouped  is also a case for MMUSIC.
> 2. The motivation for appID is also having multiple media streams (each with a different SSRC) in a single m-line representing a media source. (unified).
> 3. The FEC example is more a corner case and a question I had about msid and unified but not the motivation for appID
> Roni
>
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: 28 October, 2013 7:17 PM
>> To: Roni Even
>> Cc: Paul Kyzivat; mmusic@ietf.org
>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
>>
>> On 28 October 2013 07:57, Roni Even <ron.even.tlv@gmail.com> wrote:
>>> there can be an m-line for RTP stream
>>
>> I have http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-
>> 3.3
>> bookmarked, strangely enough, and the third paragraph is fairly clear about
>> the desired configuration, which is that multiple SSRCs are grouped into the
>> same m-line.
>>
>> The issues regarding the use of a single FEC repair stream for multiple sources
>> is where the "can" part comes in, but I wouldn't have used that as the starting
>> position for this appid work.
>
>

v2.23.0 | Report a Bug | By Email