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

Byron Campen <docfaraday@gmail.com> Thu, 01 October 2015 15:38 UTC

Return-Path: <docfaraday@gmail.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 E728D1B2D43 for <mmusic@ietfa.amsl.com>; Thu, 1 Oct 2015 08:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no
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 xEDE8FFllX37 for <mmusic@ietfa.amsl.com>; Thu, 1 Oct 2015 08:38:40 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC121B2D40 for <mmusic@ietf.org>; Thu, 1 Oct 2015 08:38:40 -0700 (PDT)
Received: by pablk4 with SMTP id lk4so77283798pab.3 for <mmusic@ietf.org>; Thu, 01 Oct 2015 08:38:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=/3UhAckT6xBTfsj3HTJLMLu/Obp9FVkFlR8+Sf53c0k=; b=iakTxOwdcguPhPR4cxSc8s9rgH4FqrA23SSzyaletBpyQqFLMYnz2UscxW7g16Xvxw ofpn4UI6VmDoVoBJ/3zXQRmi2grmgZYG+pQ14zXYgQndE8flC/sx27l88OYLzbWWVNOB e48p3E/Hc/SUTXhP86d+yvnBqrdqG8H0Vm/HCuewLVymwHjZebsry+SjfJx19idFT9eS i/UYD0uuUMNqdZvRWS5bgKosvLL8sKMRpwg6MoOby1kEkgNE6nnSqwhQqs/t4f2BMQ8P KqgNnh+n0BZ52RpAXsZB2z7it3IULGh7RYhgLjGAyLVN5tajIe7AzaXwAVofO3OHt6Ku UTvg==
X-Received: by 10.66.228.233 with SMTP id sl9mr13147272pac.139.1443713919717; Thu, 01 Oct 2015 08:38:39 -0700 (PDT)
Received: from ?IPv6:2602:306:83ae:c480:9120:cb64:72ec:e043? ([2602:306:83ae:c480:9120:cb64:72ec:e043]) by smtp.googlemail.com with ESMTPSA id zn9sm7365511pac.48.2015.10.01.08.38.37 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Oct 2015 08:38:38 -0700 (PDT)
To: mmusic@ietf.org
References: <5604B29B.9070005@nostrum.com> <560D2199.5070607@alvestrand.no>
From: Byron Campen <docfaraday@gmail.com>
Message-ID: <560D537D.9020405@gmail.com>
Date: Thu, 01 Oct 2015 10:38:37 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <560D2199.5070607@alvestrand.no>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/VW7UzU25Yb_WGQ7iOj0HvXRC6xk>
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 15:38:41 -0000

On 10/1/15 7:05 AM, Harald Alvestrand wrote:
> 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?
    Yes. If the offerer has offered to send 3 RIDs, there is no reason 
for the answerer to expect that 4 would be a possible value. Similarly, 
if the offerer has offered to receive 3 RIDs, there is no reason for the 
answerer to expect that 4 would be something that the offerer could make 
use of. The general pattern here is offer what you can send, and what 
you would like to receive, and the answerer can downnegotiate as it sees 
fit.
>
> Spinoff from that: Is it, in general, possible to add more RIDs at
> renegotiation time?
    Yes.

Best regards,
Byron Campen