Subject: Re: [Rum] draft-ietf-rum-rue-02.txt

From: Brian Rosen <[email-masked]>
Date: Mon, 17 Feb 2020 19:08:00 -0500

Inline

> On Jan 30, 2020, at 1:00 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Here are some further comments on -02:
> 
> This update has largely expunged separate specifications for the RUE and the provider server the RUE connects to in favor of talking about the RUE Interface that both are required to implement. In some cases that makes sense because the requirements are the same on both sides. In other cases it seems to dodge the issue that the two sides have different roles and responsibilities. For instance: RFC5626 (outbound), RFC6665 (events), RFC6442 (geoloc).
You might be right about Outbound, but only in the sense that the providers don’t have to implement it at all, but if they do, then they have to do what 5656 says.
Events is sort of the same way, depending on what the final text on MWI says.
Geoloc isn’t: the provider must accept and pass Geoloc to maintain 6881 conformance.

There are some differences, but I’d prefer to use “UAC and “UAS” as the terms.

> 
> Section 5.2.1 now says:
> 
>   The all outbound calls MUST be routed through an outbound proxy if
>   configured.
> 
> (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’t the text read correctly?

> 
> Section 5.2.3 says:
> 
>   To identify the owner of a RUE, the initial INVITE for a call from a
>   RUE, or the 200 OK accepting a call by a RUE, identifies the owner by
>   sending a Call-Info header with a purpose parameter of "rue-owner".
> 
> This new purpose parameter needs to be registered with IANA. It currently isn't mentioned in section 11.
Yes, need to do that.

> 
> Section 5.2.5 says:
> 
>   The implementations comply with [RFC6881] for handling of emergency
>   calls.
> 
> This is not a normative statement. AFAICT there is no normative requirement to support this. And this is another asymmetric case. (IIUC the provider need not include GeoLoc in outbound calls to the RUE.)
Missing the MUST.  It has to be normative (among other things, NG9-1-1 in the US requires it).

> 
> 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’ll change to UAC/UAS
> 
> Section 5.5 and elsewhere use the following construction:
> 
>   Implementations MUST conform to ... with the understanding that ...
> 
> That language seems a bit vague to me. Is this relaxing any normative statements in the reference, or simply stating that only a subset of the standard will be used in practice? I'd like to see this tightened up normatively.
Could you suggest language.  I agree with you.
> 
> Section 6.3:
> 
> I think this is saying that RUEs MUST support VP8 unless they can't, while providers MUST *support* VP8 but need not use it in every call, such as when connecting to another endpoint that doesn't. I get the spirit, but it fails to make clear when an implementation is non-conforming.
> 
> For instance, is it acceptable for a provider's interpreters to use non-RUE devices that don't support VP8? Is it acceptable for the provider video-mail server to not support VP8?
I think those questions are more a regulator issue.  UACs must offer VP8.  UASs must support VP8 if both ends support VP8.  I don’t think this doc should mandate what a VideoMail server does, because that’s outside the scope (VM servers may or may not conform to this doc).  

Language suggestions welcome!
> 
> Section 8:
> 
> 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’t think there is a reasonable way to build a client without supporting MWI, since there is no other interface to support the function.

> 
> Section 9.1:
> 
> This makes it optional for a RUE to make the choice of provider available to the user. Is that what we want?
> 
Hmmm. Is that a UI issue, and thus beyond scope, or an interface issue and in scope?

> Section 9.3:
> 
> These schemas use the [JCR] notation. This dates back to the early versions of this document several years ago. At the time there was single accepted schema notation for JSON. JCR was under development at the time. I haven't kept up with what has been happening with JSON schemas. I just looked and it appears that draft-newton-json-content-rules-09 is the latest version of JCR. I don't know if that means it was abandoned in favor of something else. We need to investigate this.\\
Yeah, I’m pretty heavily dealing with this in other venues.  I think we want json schemas.  I’ll do that next rev.

> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Feb 2020 14:24:11 -0500

Brian,

Followups inline.

> Geoloc isn’t: the provider must accept and pass Geoloc to maintain 6881 conformance.

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.

For instance:

- 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.

- for MWI the RUE is always the subscriber and the provider is always 
the publisher.

- 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.

> There are some differences, but I’d prefer to use “UAC and “UAS” as the terms.

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.

> Yes, but doesn’t the text read correctly?

IMO the old way was right. ("The RUE MUST route all calls through the 
outbound proxy ...")

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?

>> This new purpose parameter needs to be registered with IANA. It currently isn't mentioned in section 11.

OK

> Missing the MUST.  It has to be normative (among other things, NG9-1-1 in the US requires it).

OK

>> 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 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.

> Could you suggest language.  I agree with you.

There are three usages of this language, in 5.5, 6.1, and 6.6. These 
refer respectively to rtcweb-transports, rtcweb-rtp-usage, rtcweb-jsep.

I started looking at rtcweb-transports to see how to rewrite it. It 
isn't written in a way that makes it easy to adopt for our needs. I'm 
not sure it is possible without violating some of its normative 
statements. I think we may need to go through it almost line by line to 
see if we can make it work.

I didn't look at the others in detail yet.

I think this may be a significant effort. We may find that we simply 
have to copy and modify some text with these, and discuss how that will 
facilitate interop with rtcweb.

We need to start a separate thread focused on this.

> Language suggestions welcome!

IIUC you are suggesting that H.264 is MTI by both provider and RUE. 
Beyond that it isn't clear.

We could just leave it at that, and leave it to the FCC to mandate VP8 
if they want.

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.)

This requires further discussion of what we are trying to accomplish.

> Yeah, although I have a pretty hard time not mandating MWI.  I really don’t think there is a reasonable way to build a client without supporting MWI, since there is no other interface to support th…

IIUC (I might not) at least some providers now provide a non-SIP 
mechanism for retrieving video mail. (A web interface?)

However, that might not be accessible to users with a conforming RUE. 
Potentially they could simply say they don't support receiving video 
mail via SIP. In the past we had some language that said if the RUE spec 
makes a feature optional, they a provider MUST provide it if they have a 
comparable proprietary feature.

We can check, but I suspect that *every* provider has video mail. If so, 
they making this MTI makes sense to me.

> Hmmm. Is that a UI issue, and thus beyond scope, or an interface issue and in scope?

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.

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.

> Yeah, I’m pretty heavily dealing with this in other venues.  I think we want json schemas.  I’ll do that next rev.

Sounds like you are more up to speed than I am.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 24 Feb 2020 12:53:09 -0500

Inline

> On Feb 19, 2020, at 2:24 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Brian,
> 
> Followups inline.
> 
> 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.
> 
> For instance:
> 
> - 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.
> 
> - for MWI the RUE is always the subscriber and the provider is always the publisher.
> 
> - 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’t need to specify.

> 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 “client” and “server” when we need to.

> IMO the old way was right. ("The RUE MUST route all calls through the outbound proxy ...")
> 
> 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’t think in this document we are concerned about what the interpreter is sitting in front of.  I’d like it to be a RUE, but it doesn’t 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.
> 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.

> There are three usages of this language, in 5.5, 6.1, and 6.6. These refer respectively to rtcweb-transports, rtcweb-rtp-usage, rtcweb-jsep.
> 
> I started looking at rtcweb-transports to see how to rewrite it. It isn't written in a way that makes it easy to adopt for our needs. I'm not sure it is possible without violating some of its normative statements. I think we may need to go through it almost line by line to see if we can make it work.
> 
> I think this may be a significant effort. We may find that we simply have to copy and modify some text with these, and discuss how that will facilitate interop with rtcweb.
> 
Okay

> IIUC you are suggesting that H.264 is MTI by both provider and RUE. Beyond that it isn't clear.
I think a conforming interface has to support 264, and VP8 is optional. 
> 
> We could just leave it at that, and leave it to the FCC to mandate VP8 if they want.
Adam suggested that given the realities, H.264 as MTI is acceptable.  That’s okay with me.
> 
> 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.)
“By the providers” could be interpreted in several ways.  One is that the interface supports VP8.  I certainly hope that’s a requirement.  Another is that an endpoint that the provider has, specifically, the CA’s workstation, or the videomail endpoint, supports VP8.  I wouldn’t 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?

> 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’m not arguing for mandating any particular way to retrieve VM, but I think it’s 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.

> 
> However, that might not be accessible to users with a conforming RUE. Potentially they could simply say they don't support receiving video mail via SIP. In the past we had some language that said if the RUE spec makes a feature optional, they a provider MUST provide it if they have a comparable proprietary feature.
Yeah, I don’t want to see that kind of language in an IETF doc.  The regulator could say that, not us.
> 
> We can check, but I suspect that *every* provider has video mail. If so, they making this MTI makes sense to me.
> 
>>> Section 9.1:
>>> 
> 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.
> 
> 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’t know if we need to go any farther.

> Sounds like you are more up to speed than I am.
Yeah, probably

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2020 12:01:13 -0500

Brian,

responses inline...

On 2/24/20 12:53 PM, Brian Rosen wrote:
> Inline
> 
>> On Feb 19, 2020, at 2:24 PM, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
[snip]
>> UAC vs. UAS, but not always. So at least I think we need to profile 
>> what part each end must support.
>>
>> For instance:
>>
> 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’t need to specify.

I'll have to review 6881 so see if it will be clear which end is which 
in our context.

>> 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.

Currently UAC and UAS aren't used. So I guess I'll have to wait to see 
what works.

>>>> (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.)
>> 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’t think in this document we are concerned about what the 
> interpreter is sitting in front of.  I’d like it to be a RUE, but it 
> doesn’t 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.

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.

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.

It isn't a big issue, but it just seems to me the change was unnecessary 
and didn't improve anything.

[snip]

>>>> 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’ll change to UAC/UAS
>>
>> 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.

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.

Also, it appears that additional data can be transmitted in both sip 
requests and responses, so by both UAC and UAS.

If the RUE can receive additional data, then isn't there some need to 
specify what it is expected to do with it?

[snip]

> “By the providers” could be interpreted in several ways.  One is that 
> the interface supports VP8.  I certainly hope that’s a requirement. 
>   Another is that an endpoint that the provider has, specifically, the 
> CA’s workstation, or the videomail endpoint, supports VP8.  I wouldn’t 
> 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?

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.

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.

>>>> 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’t think there is a reasonable way to build a client without 
>>> supporting MWI, since there is no other interface to support the 
>>> function.
>>
> A web interface is fine, and I’m not arguing for mandating any 
> particular way to retrieve VM, but I think it’s 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.

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?

Alternately, retrieval can be by calling a special number.

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.

It seems important that this continues to work when the RUE gets service 
from a different provider.

[snip]

>> We can check, but I suspect that *every* provider has video mail. If 
>> so, they making this MTI makes sense to me.
>>
>>>> Section 9.1:
>>>>
>>>> This makes it optional for a RUE to make the choice of provider 
>>>> available to the user. Is that what we want?
>>>>
>> 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’t know if we need to go any farther.

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.

[snip]

	Thanks,
	Paul