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

[Brian Rosen <[e-mail]>]

Inline

> On Feb 25, 2020, at 12:01 PM, Paul Kyzivat <[e-mail]> wrote:
> 
> Brian,
> 
> responses inline...
> 
> On 2/24/20 12:53 PM, Brian Rosen wrote:
>> Inline
>>> On Feb 19, 2020, at 2:24 PM, Paul Kyzivat <[e-mail] <mailto:[e-mail]>> 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.
>>> 
>>> 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.
> 
> I'll have to review 6881 so see if it will be clear which end is which in our context.

Ok

> 
>>>> 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.
>> I think that is one of the few exceptions.  We can use “client” and “server” when we need to.
> 
> Currently UAC and UAS aren't used. So I guess I'll have to wait to see what works.

OK


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

Agree.  I do think we mostly want to be forward looking, taking WebRTC as the IETF’s current best practice, with whatever seems reasonable for backwards compatibility.  I don’t 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.

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

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

> 
> 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’s only sent by the caller.

> 
> 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’t ever get it.

> 
> [snip]
> 
>>> 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?
> 
> 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.
Agree, but does that change any text?

> 
>>> 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?)
>> 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?
I’m not really arguing that the RUE has to retrieve.  I’m only arguing that it has to be able to tell you that you have a VM.

> 
> 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.
I think retrieval may be more that we can reasonably require, but I’m willing to talk about it.  Indication seems to me to be a requirement.

> 
> It seems important that this continues to work when the RUE gets service from a different provider.
Well, I don’t think you mean that one provider supports another providers VM.  Even with MWI, if you change providers, the new one isn’t going to tell you that you still have VM in the old one.  Once you port, you usually can’t get at the old provider’s resources.  What has to happen is that the device shows you that you have VM on the new 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?
>>>>> 
>>>> 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.
>> 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.
Right now, I’m thinking standardize a file format and a mechanism to retrieve it.  Do we need anything else?


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