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

[Paul Kyzivat <[e-mail]>]

Brian,

Followups inline.

On 2/17/20 7:08 PM, Brian Rosen wrote:
> Inline
> 
>> On Jan 30, 2020, at 1:00 PM, Paul Kyzivat <[e-mail]> 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.

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.

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

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?

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

OK

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

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

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

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.

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

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.

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

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.

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

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.

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

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

	Thanks,
	Paul