[rtcweb] Cullen Notes from RTCWeb interim on June 18, 2015

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 18 June 2015 18:00 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AFD1B2B4A for <rtcweb@ietfa.amsl.com>; Thu, 18 Jun 2015 11:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.511
X-Spam-Level:
X-Spam-Status: No, score=-112.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 zLqRDL5XnrFN for <rtcweb@ietfa.amsl.com>; Thu, 18 Jun 2015 11:00:48 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23581B2B31 for <rtcweb@ietf.org>; Thu, 18 Jun 2015 11:00:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3140; q=dns/txt; s=iport; t=1434650448; x=1435860048; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2e5gz+/uqjkpbikrhp2hkQv9z5R54fN/74tw5ltb/dU=; b=YmWtp0WelHS6rkn6HcSdllEzD0ySDbDGpLzGGdq3u9DfMXYw830xJ5ki cm3J0pfHd+38YqLSfRpIKcQY/RN/bHUxdJTpODTr7Acexu7G9q5VQGvNi MyRwxaDZKZHDK08PvaBCw8tKoTLYOolKu+IXPlYUICjGk93rQbK9pzGA6 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AZBQADB4NV/4kNJK1cgxBUZb9chXyBPjwQAQEBAQEBAYEKhCUEOj8SAT5CJwQOiDQNxiMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI0Cg0mDHoEUBZNwAYRShniBNYcWj1smghiBYYI1gQIBAQE
X-IronPort-AV: E=Sophos;i="5.13,640,1427760000"; d="scan'208";a="4684746"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jun 2015 18:00:37 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5II0bXO019297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 18:00:37 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.175]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 13:00:37 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Cullen Notes from RTCWeb interim on June 18, 2015
Thread-Index: AQHQqfCtcbh3jP6YIUqueUzbk8fzYQ==
Date: Thu, 18 Jun 2015 18:00:36 +0000
Message-ID: <A725DB06-876C-46B2-BED0-94CD0CED11FC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DFF5DF75B0AB9B46BD76502B3CD64EC2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/EwFhJgoBvq_T8R1pG0oZBtsBYko>
Subject: [rtcweb] Cullen Notes from RTCWeb interim on June 18, 2015
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 18:00:50 -0000

These are just my rough notes and chairs will form minutes from everything we get



* make sure to add note well slide to slide deck 

LS Behavior 
- Magnus points out that if JSEP overrides 5888, we will have issue with legacy things
- Martin points needs more thought to make declarative groups
- Martin raised point that we might be able to add some extra signaling that indicates that we can support this declarative LS usage 

Conclusion: Magnus will dig into more analysis of options on this and send to list. No decision on Option 1,2 


ImageAttr specification (receiver)
- people are good on what we send (intersection)
- do need to talk more about  with receiving min or not 

b= slide 
- no issues

c= slide 
- no issue 
Note :: does not work in c line but the 0.0.0.0 does 

Moving on to Open Issue slides 

Issue #9 - changing b=
Do we need to deal with bs=RS/RR 

Magnus - reason to honor this... consider use case with middle box where middle box wants to tune RTCP to ensure the middle box gets enough feedback. 5% is a problem if you want rapid feedback and low bit rate media. So you might want to use this to up it. 

Randal - might want to be up this above 5% to improve bandwidth estimation

Magnus - thinks we need to be able to set them and have endpoint honor them 

Randal - use case is what if you want to send feedback on every frame of a video for some congestion control use case

Justin - hard to implement and not clear at this point

Randal - propose what we implement now is if you receive this, you will not go over the specified value (but does not mean that the implementation would necessarily send more)

Magnus propose. Browsers set it (at default 5% is fine). This allows middle boxes to change. And browsers interpret it and do not exceed it. 

Conclusion: browser need to be able to receive RS/RR and honor it 


#144 b= at session level
- no objections


#122 b=TIAS 
- OK with this 

#148/149 a=ssrc
- Question can we list both and switch ? 

- read more in https://tools.ietf.org/html/rfc7160

- HTA raise point that switching is not going to happen in a session with simulcast 

- HTA proposal, if on a session that is not simulcast, and you see a SSRC switch, just deal with it

Next steps: go study what this hybrid approach would look like 


# question on imageattr - what happens when rotate

Proposal: always send image attr in landscape and rely on CVO for rotations. We need to take this idea and circulate widely (such as 3GPP).

Randal - what if native is not rotated. 

CVO is Coordination of Video Orientation (CVO) section 7.4.5 of [TS26.114]

Probably needs some offline discussion. 

Magnus will see if he can get someone to explain where the 3GPP and related standards are on this. 


#16 Accessors 
- no comments

Skip forward to last slide on Upscaling video 

Conclusion:
- we add some sort of switch that sets if upscale is allowed or not
- default is to allow upscale