From nobody Mon Mar 2 14:42:53 2020
Return-Path:
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 8BE9E3A131E for ; Mon, 2 Mar 2020 14:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 3HIZ53QK5_yZ for ; Mon, 2 Mar 2020 14:42:47 -0800 (PST)
Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 DA2773A131A for ; Mon, 2 Mar 2020 14:42:46 -0800 (PST)
Received: by mail-yw1-xc2c.google.com with SMTP id x184so1509757ywd.6 for ; Mon, 02 Mar 2020 14:42:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oT8aWt45McTDTnyms9wznWORsRdjNUzhmdSL8BPCrNU=; b=aw2l7eRKWsOBhis83e2XPn/yUnw2ZKk2z/Zxmki31RfynSPusq0ZMvXe7RIbwglLMS 5fxgZUaadAIYcXXPZDMlTOzVYT1Y5kUW2+Td2Qv9CeziQWjI5C1V0wNxxiRCDF9rjsdd uwvLwN+bF0A4SgXzUgtwN1iZXS0xRiTun7Z4ZUGw2GbyfXc1ruJBmTIQP+JURJaVtqfh Wmnmb2GGsxHFqJsIXzH2ewYgUuIj5iFnd48BMtO2Gscckq8Xpd+1F8KoGgZcs/4Rrohr g59711KQqNIZ0zrDsbdViHKLsU3UCGQEjsV+2EUxHXlYjYQp7HAa5tYn1Vp+nhtWzi1m kDfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oT8aWt45McTDTnyms9wznWORsRdjNUzhmdSL8BPCrNU=; b=DEeUHb2ClwF1DZjReDTQVjSITpekG7G3tlxSneH6uDyABJmD63XNGaKoyztMwfsNJA C3Emsiq00+F8Q/Bttmjg7AQFLb9SXIa6/KmGUCpY9+zUZVo8kBwLMX6AcDMau061jBOD 49emfBplkZK6KL99jbfsCEZ+ZcoPhYwkep1+DRM0vxaEgrypzPRBae6csI+kQVnl2cNg eNILjmPC2B3o3gT6LBchLIeK4SoI7TQU74LjUmO/BJn73sfD3eIiJZ0CLfzk5Ogl5ROj c3gpjiSPKG97fa8lrbgL6O3Pe4xmkOUHa6CrlCq7wDHM4fGeqW8L78CtZkuBnlizw9gJ 7aoA==
X-Gm-Message-State: ANhLgQ1djCyu7hS6EM7Gh07J8rV1baSAGtlZksPY+VxbnRMUSQ5d2BVn J0Q9D2J4cIV30JhVUuxTQjJ8rzDG3xw=
X-Google-Smtp-Source: ADFU+vvmINZaiXJURMbSupbacu0D4bYhXQvo/cStTv8PU7D8oiiawFKyMlTo3vrDGELiNYkqtgCcKQ==
X-Received: by 2002:a25:3187:: with SMTP id x129mr1274998ybx.397.1583188965921; Mon, 02 Mar 2020 14:42:45 -0800 (PST)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id f205sm6356379ywa.2.2020.03.02.14.42.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 14:42:45 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Brian Rosen
In-Reply-To: <629ab9cb-7487-f05e-e06a-57dc9ae551e7@alum.mit.edu>
Date: Mon, 2 Mar 2020 17:42:42 -0500
Cc: rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net> <629ab9cb-7487-f05e-e06a-57dc9ae551e7@alum.mit.edu>
To: Paul Kyzivat
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At:
Subject: Re: [Rum] draft-ietf-rum-rue-02.txt
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 02 Mar 2020 22:42:51 -0000
Inline
> On Feb 25, 2020, at 12:01 PM, Paul Kyzivat =
wrote:
>=20
> Brian,
>=20
> responses inline...
>=20
> On 2/24/20 12:53 PM, Brian Rosen wrote:
>> Inline
>>> On Feb 19, 2020, at 2:24 PM, Paul Kyzivat > wrote:
> [snip]
>>> My point in general though is that most of these protocols specify =
differing behavior on the two ends of a connection. Sometimes this is =
UAC vs. UAS, but not always. So at least I think we need to profile what =
part each end must support.
>>>=20
>>> For instance:
>>>=20
>>> - when outbound is in use, the roles of the RUE and the provider are =
clearly distinct. E.g. the RUE is responsible for setting of the =
connections to the server, and keeping them up as long as it wants the =
possibility of receiving a call.
>>>=20
>>> - for MWI the RUE is always the subscriber and the provider is =
always the publisher.
>>>=20
>>> - for location information I should probably have called out RFC6881 =
rather than RC6442. The RUE will be the one including geoloc info, and =
the provider acting on it. I don't think there is any requirement or =
expectation that geoloc info flows from the provider to the RUE.
>> But ISTM that all we need do it say that conformance to the =
appropriate standards is required. Those standards specify what each =
end has to do. Our document doesn=E2=80=99t need to specify.
>=20
> I'll have to review 6881 so see if it will be clear which end is which =
in our context.
Ok
>=20
>>>> There are some differences, but I=E2=80=99d prefer to use =E2=80=9CUA=
C and =E2=80=9CUAS=E2=80=9D as the terms.
>>>=20
>>> Rarely is that the proper distinction for this. E.g., for MWI the =
RUE is the UAC for subscriptions, but is UAS for the notifications.
>> I think that is one of the few exceptions. We can use =E2=80=9Cclient=E2=
=80=9D and =E2=80=9Cserver=E2=80=9D when we need to.
>=20
> Currently UAC and UAS aren't used. So I guess I'll have to wait to see =
what works.
OK
>=20
>>>>> Section 5.2.1 now says:
>>>>>=20
>>>>> The all outbound calls MUST be routed through an outbound proxy =
if
>>>>> configured.
>>>>>=20
>>>>> (It previously specified the RUE.) IIUC this really does only =
apply to the RUE. AFAIK we don't specify any configuration for the =
provider, and presumably providers can do whatever they want that works. =
(Also, the language is a bit messed up.)
>>>> Yes, but doesn=E2=80=99t the text read correctly?
>>>=20
>>> IMO the old way was right. ("The RUE MUST route all calls through =
the outbound proxy ...")
>>>=20
>>> This of course depends on what you mean by an outbound call. A call =
*to* a particular RUE in inbound from the RUE perspective, but what is =
it from the perspective of the interpreter at the provider that is =
initiating it?
>> I don=E2=80=99t think in this document we are concerned about what =
the interpreter is sitting in front of. I=E2=80=99d like it to be a =
RUE, but it doesn=E2=80=99t have to be (unless the regulator says it has =
to be). All that we are concerned with here is the interface between =
the RUE and the rest of the ecosystem, which will have providers, other =
RUE devices and some non-RUE devices we want to be backwards compatible =
with.
>=20
> The tricky part is that rtcweb is defining behavior when establishing =
media between two conforming endpoints. In RUM, we will sometimes have =
calls where only one of the endpoint is conforming. The provider may =
then act as a bridge to the non-conforming device. While we don't need =
to say how that is done, we ought to take into account what the =
challenges will be and that we are confident that this can be done in a =
practical sense.
Agree. I do think we mostly want to be forward looking, taking WebRTC =
as the IETF=E2=80=99s current best practice, with whatever seems =
reasonable for backwards compatibility. I don=E2=80=99t want to mandate =
a lot of old stuff, recognizing that implementers are free to add more =
backwards compatibility as they see fit. Take for example, the INFO =
package for full screen refresh. I would not want to mandate that in =
rum. But there are older devices that still use that.
>=20
> But this is wandering from my issue with this section. My concern was =
whether the wording ("The all outbound calls MUST be routed") is clear =
regarding which calls it applies to. The old wording ("The RUE MUST =
route all calls") was crystal clear. The new wording is clear when read =
in the context of RFC5626. If the reader isn't thinking in that context, =
and especially if the reader is thinking about it from the point of view =
of a provider planning the implementation of his servers, they this =
might not be so clear.
In this case, we could explicitly say that (reference 5826).
>=20
> It isn't a big issue, but it just seems to me the change was =
unnecessary and didn't improve anything.
>=20
> [snip]
>=20
>>>>> This section also uses "client" and "server" to refer to the RUE =
and Provider sides of a RUE Interface. This differs from using "client" =
to refer to UAC and "server" for UAS.
>>>> I=E2=80=99ll change to UAC/UAS
>>>=20
>>> I don't think that works. UAC pertains only to a particular message. =
Both RUE and provider take both roles at various times. IIUC Additional =
Data is only ever sent in requests, not responses, so of course it will =
be a UAC that is sending. What is really important here is that it is =
the RUE that is sending the Additional Data.
>> Actually, the provider is most often the entity that sends Additional =
Data. The RUE might also, but the provider always does so.
>=20
> Then I guess I'm confused. Can you explain more? What is the use case =
for this. My quick rescan of 5626 confirms my impression that this is =
data flowing from the originator of the emergency call subsequent to the =
establishment of the call. For instance, a change in location.
All providers add the Service Environment, Service Type, Service =
Mobility, Type of Provider, and the data provider block. They may add =
the subscriber block. The device may add the device and subscriber =
blocks.
>=20
> Also, it appears that additional data can be transmitted in both sip =
requests and responses, so by both UAC and UAS.
It could be, but the use case is not in the initial emergency call. In =
that use case, it=E2=80=99s only sent by the caller.
>=20
> If the RUE can receive additional data, then isn't there some need to =
specify what it is expected to do with it?
It won=E2=80=99t ever get it.
>=20
> [snip]
>=20
>>> Or, we could mandate VP8 support by providers on the RUE interface =
without requiring that RUEs support it. That would allow new RUE =
implementations that support VP8, but would still allow RUE =
implementations without it so that old devices can be supported. (In =
particular, the potential upgrading of existing provider supplied =
equipment.)
>> =E2=80=9CBy the providers=E2=80=9D could be interpreted in several =
ways. One is that the interface supports VP8. I certainly hope =
that=E2=80=99s a requirement. Another is that an endpoint that the =
provider has, specifically, the CA=E2=80=99s workstation, or the =
videomail endpoint, supports VP8. I wouldn=E2=80=99t have any text in =
our document that would require that. As a practical matter, what that =
means is that if two RUE devices on different providers negotiated VP8, =
that it would work, but if we looked at the offer from, say, the CA, we =
may or may not see VP8. Does that make sense? Is that okay?
>=20
> I think it is ok. I'm not certain if the providers would be happy even =
with that. IIUC, Sorenson is capable of negotiating e2e media between =
two RUEs, using ICE, and so would probably be able to do this. I think =
some of the others still always proxy the media. I don't know if they =
are able to proxy media using codecs they don't support.
>=20
> The provider profile only specifies the connections between providers. =
It doesn't specify at all how the signaling between RUE and provider =
relates to what the provider passes along to either another provider or =
to another RUE connected to the same provider. I think RUM will of =
necessity cause us to define some of that. We need to think about that =
part. This is probably only so for p2p calls between RUM-compliant RUEs. =
How much we need to specify for relay calls or video mail answered calls =
is a whole different question.
Agree, but does that change any text?
>=20
>>> This requires further discussion of what we are trying to =
accomplish.
>>>=20
>>>>> Section 8:
>>>>>=20
>>>>> IIUC this means that the provider may or may not include a "mwi" =
entry in the configuration, but if it is configured that both sides are =
required to support it as specified.
>>>> Yeah, although I have a pretty hard time not mandating MWI. I =
really don=E2=80=99t think there is a reasonable way to build a client =
without supporting MWI, since there is no other interface to support the =
function.
>>>=20
>>> IIUC (I might not) at least some providers now provide a non-SIP =
mechanism for retrieving video mail. (A web interface?)
>> A web interface is fine, and I=E2=80=99m not arguing for mandating =
any particular way to retrieve VM, but I think it=E2=80=99s pretty =
important that the UI of a RUE be able to show that there is VM waiting, =
and I think MWI is the only standards based way to provide an interface =
that would let it do that.
>=20
> ISTM that if the provider stores messages for retrieval by the VRS =
user then there must be some way for the standard RUE to retrieve them. =
If this is a web interface, then do we need to specify that all RUEs =
have a browser UI?
I=E2=80=99m not really arguing that the RUE has to retrieve. I=E2=80=99m =
only arguing that it has to be able to tell you that you have a VM.
>=20
> Alternately, retrieval can be by calling a special number.
>=20
> ISTM that at the very least, we would want to ensure that that RUE has =
some standard way to learn that there are messages waiting, to notify =
the user of that, and to provide the user with a way to retrieve those =
messages.
I think retrieval may be more that we can reasonably require, but I=E2=80=99=
m willing to talk about it. Indication seems to me to be a requirement.
>=20
> It seems important that this continues to work when the RUE gets =
service from a different provider.
Well, I don=E2=80=99t think you mean that one provider supports another =
providers VM. Even with MWI, if you change providers, the new one =
isn=E2=80=99t going to tell you that you still have VM in the old one. =
Once you port, you usually can=E2=80=99t get at the old provider=E2=80=99s=
resources. What has to happen is that the device shows you that you =
have VM on the new provider.
>=20
> [snip]
>=20
>>> We can check, but I suspect that *every* provider has video mail. If =
so, they making this MTI makes sense to me.
>>>=20
>>>>> Section 9.1:
>>>>>=20
>>>>> This makes it optional for a RUE to make the choice of provider =
available to the user. Is that what we want?
>>>>>=20
>>>> Hmmm. Is that a UI issue, and thus beyond scope, or an interface =
issue and in scope?
>>>=20
>>> We can specify the need to provide the feature without specifying =
what it looks like in the UI. This is analogous the requiring the =
support of MWI.
>>>=20
>>> It seems likely to me that the providers will provide a RUE =
implementation that runs on some of their already deployed hardware. =
They most likely won't want to enable it to choose another provider. We =
need to decide if that is ok or not. Or we can leave it to the FCC to =
decide.
>> I think the interface (in this case, I think this is a json object in =
a file) has to support it. I don=E2=80=99t know if we need to go any =
farther.
>=20
> Just to be clear: The RUE will need to *know* what providers to =
attempt to register with. The interface that returns the list of =
providers, coupled with some UI the presents that to the user, is one =
way of accomplishing that. Another way is a UI that allows the user to =
manually configure the provider. And preconfiguring the RUE before =
delivering it to the user, with no user override, is yet another way. We =
need to decide if there are any of these that we want to mandate be =
available. Or we might want to define some *optional* specs for one or =
more of these that are then available for a regulatory agency to call =
out if they wish.
Right now, I=E2=80=99m thinking standardize a file format and a =
mechanism to retrieve it. Do we need anything else?
>=20
> [snip]
>=20
> Thanks,
> Paul
>=20
> --=20
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum