IETF Logo Mail Archive

Re: [MMUSIC] Simulcast: Short timelines, draft impending

Harald Alvestrand <harald@alvestrand.no> Thu, 01 October 2015 12:05 UTC

Return-Path: <harald@alvestrand.no>
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 D67CC1A6F2B for <mmusic@ietfa.amsl.com>; Thu, 1 Oct 2015 05:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PCDvoVQk7xJA for <mmusic@ietfa.amsl.com>; Thu, 1 Oct 2015 05:05:48 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id BBC611A6EF2 for <mmusic@ietf.org>; Thu, 1 Oct 2015 05:05:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CCB7C7C5CFE for <mmusic@ietf.org>; Thu, 1 Oct 2015 14:05:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8Nn3mYKqhmG for <mmusic@ietf.org>; Thu, 1 Oct 2015 14:05:46 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1:7805:3513:e7d5:6ddf] (unknown [IPv6:2001:470:de0a:1:7805:3513:e7d5:6ddf]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3180D7C5CF5 for <mmusic@ietf.org>; Thu, 1 Oct 2015 14:05:46 +0200 (CEST)
To: mmusic@ietf.org
References: <5604B29B.9070005@nostrum.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <560D2199.5070607@alvestrand.no>
Date: Thu, 01 Oct 2015 14:05:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <5604B29B.9070005@nostrum.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/PW5MrtvjLb7yKeH66P8kREmNPEo>
Subject: Re: [MMUSIC] Simulcast: Short timelines, draft impending
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: Thu, 01 Oct 2015 12:05:50 -0000

While waiting for the draft, one thing that puzzled me on third reading
through this proposal:

On 09/25/2015 04:34 AM, Adam Roach wrote:
>
>  *
>
>    RIDs can be defined to be unidirectional, so as to allow
>    implementations to signal the ability to send a different number of
>    encodings than they can receive.
>
>  *
>
>    The values for each constraint can be specified to be different in
>    each direction.
>
>
>  *
>
>    The values (that is, identifiers) used for RID are proposed by the
>    offerer in a session, and are symmetric. The RID values in an answer
>    must be a subset of those present in the offer.

I'm a bit confused. How do we have unidirectional but symmetric RIDs?

If the answerer thinks that it is going to need more RIDs than the
offerer proposes, is he required to start a renegotiation to get what he
wants?

Spinoff from that: Is it, in general, possible to add more RIDs at
renegotiation time?

This may be obvious once the draft arrives.

v2.23.0 | Report a Bug | By Email