Re: [Rum] Outstanding Issues

James Hamlin <james.hamlin@purple.us> Wed, 17 March 2021 14:25 UTC

Return-Path: <james.hamlin@purple.us>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A593A0E1D for <rum@ietfa.amsl.com>; Wed, 17 Mar 2021 07:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jNtp8hfoBS0K for <rum@ietfa.amsl.com>; Wed, 17 Mar 2021 07:25:20 -0700 (PDT)
Received: from outbound-ip1b.ess.barracuda.com (outbound-ip1b.ess.barracuda.com [209.222.82.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893513A0E08 for <rum@ietf.org>; Wed, 17 Mar 2021 07:25:17 -0700 (PDT)
Received: from smtp.purple.us (unknown [208.17.91.144]) by mx-outbound17-95.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 17 Mar 2021 14:25:13 +0000
Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 Mar 2021 07:24:40 -0700
Received: from 1-WP-402-EXCH.purplenetwork.net ([::1]) by 1-wp-402-exch.purplenetwork.net ([fe80::58e8:f183:3575:4f60%27]) with mapi id 15.00.1263.000; Wed, 17 Mar 2021 07:24:40 -0700
From: James Hamlin <james.hamlin@purple.us>
To: Brian Rosen <br@brianrosen.net>, "rum@ietf.org" <rum@ietf.org>
Thread-Topic: [Rum] Outstanding Issues
Thread-Index: AQHXGxoVsTPryCNNx0G32s1cJr/VFA==
Date: Wed, 17 Mar 2021 14:24:40 +0000
Message-ID: <1615991079090.3921@purple.us>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.0.10.15]
Content-Type: multipart/alternative; boundary="_000_16159910790903921purpleus_"
MIME-Version: 1.0
X-BESS-ID: 1615991080-104447-5450-24125-9
X-BESS-VER: 2019.1_20210312.2105
X-BESS-Apparent-Source-IP: 208.17.91.144
X-BESS-Outbound-Spam-Score: 0.00
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230899 [from cloudscan8-142.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound
X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND
X-BESS-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/ImXeLE_50Vc9vxfBp5X0XjcLvMk>
Subject: Re: [Rum] Outstanding Issues
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Mar 2021 14:25:28 -0000

Hi


We support this. I can add:-

The requirement "MUST support IPv4 and IPv6" might be taken to mean that providers have to start listening for SIP on IPv6. There is no current business or regulatory requirement for this and so this specification should not try to force the progress to IPv6.

The FCC ruling (https://docs.fcc.gov/public/attachments/DA-17-76A1.pdf) only requires contact export from a provider and specifically in XCard format.

The requirement to support WebRTC codecs, except for "old" endpoints and PSTN, interferes with VRS providers freedom to use their own non-RUE endpoints. The minimum media codec requirement within the VRS industry, is defined in the

US VRS Provider Interoperability Profile (PIP) which mandates H.264 and G.711 only.


It is possible to demonstrate a SIP mobile app without push notifications, but not one which is genuinely usable.


Best regards


James



On 12/03/2021 15:27, Isaac Roach wrote:

Hi Brian,

As discussed during the IETF110 meeting, there are still concerns we have with the current version of the RUM Profile. These are the outstanding issues:

Section 4 - IPv6 was added as requirement for the RUE but it is not clear how this affects the interface between the RUE and the provider.

Section 5.2.5 - There is nothing indicating how registered location should be handled for 911 in the UI. We are required to maintain a registered address for the user. We use a device identifier to save one location for each device the user logs into. We need a method to identify multiple locations for multiple devices for a single user.

Section 6 - The providers have agreed to use SIP to ensure interoperability. WebRTC is out of scope and should not have been added. If the RUE implementor wants to use WebRTC it needs to also provide a WebRTC to SIP gateway.

Section 7.2 - XCard was changed to jCard. The FCC rules already require providers to support XCard. Requiring support for jCard is an unnecessary increase in scope; there is no reason why providers should have to support XCard and jCard.

Section 7.1 and 7.2 - Automatic contact export is not needed and should not have been added as it unnecessarily increased scope.

Section 8 - MWI should be removed as it is not a minimum requirement from the FCC, and providers shouldn't be limited to supporting MWI on a RUE in this one specific way.

Missing - There is nothing specified for push notifications to enable incoming calls which are now required for mobile.

These are issues we can help resolve but it will require a significant amount of time. Given that the FCC has suspended the VATRP project until there is an appropriately developed consensus standard, it doesn't seem like a good idea to me to rush this through.

Thanks,

Isaac


Isaac Roach
VP Engineering
P: 801-558-0814
E: iroach@sorenson.com


Sorenson Communications, LLC
4192 S. Riverboat Rd.
Salt Lake City, UT 84123
www.sorenson.com