Subject: [Rum] Comments on draft-ietf-rum-rue-05

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Jul 2021 15:28:37 -0400

I reviewed this version in whole, from scratch rather than simply 
reviewing diffs from prior versions. (I find it helpful to do this now 
and then to get a fresh holistic view.)

It seems to generally in pretty good shape. But I do have several points 
to consider. Some of these are new while I think I have mentioned with 
prior versions.

* Section 1, Intro:

I don't think the following:

    While there are some
    accommodations in this document to maximize backwards compatibility
    with devices and services that conform to this document, ...

says quite what you meant. I suggest:

    While there are some
    accommodations in this document to maximize backwards compatibility
    with other devices and services that have been used to provide
    VRS service,

* Section 2, Dial-around call:

The definition provided:

    Dial-around call: A relay call where the subscriber specifies the use
    of a VRS provider other than the default VRS provider. ...

actually describes *outbound dial-around*. Inbound dial-around is also a 
possibility (though I think rarely used), where the hearing caller 
chooses the provider.

Inbound dial-around isn't discussed in this document. I think that is 
probably ok since there isn't any obvious special treatment required for 
the RUE in this case.

* Section 2, P2P Call:

The definition for P2P Call:

    Point-to-Point Call (P2P Call): A call between two
    RUEs, without including a CA.

is run in to the preceding definition of FIR. Just a typo.

* Section 2, Relay-to-relay call:

I think we can remove this definition. The only place it is used is a 
couple of lines down in the definition of Relay Service. It doesn't 
affect anything.

* Section 2, RUE:

I suggest a small tweak to the following:

    Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra
    features to support a subscriber in requesting and using relay calls.

s/requesting and using/requesting, receiving, and using/

* Section 4, IPv6:

Seems like we are lacking any corresponding discussion of support for 
IPv4/IPv6 in media, and how that correlates with the signaling. If 
signaling for the two protocols is via separate servers, then perhaps 
there should be a requirement that the servers support the same IP 
version for media.

This is less critical if ICE is used. But even then there is a question 
of what goes into the c= lines.

* Section 5.1, multiple registrations

This section says:

    Support for multiple simultaneous registrations is OPTIONAL.

and then goes on to discuss registration with multiple providers, which 
is fine. But earlier it said:

    If the configuration
    (please refer to Section 11) contains multiple "outbound-proxies",
    then the RUE MUST use them as specified in [RFC5626] to establish
    multiple flows.

That also requires multiple simultaneous registrations. And that *isn't* 
optional. To clarify this, I suggest modifying the above statement with:

    Support by the RUE for simultaneous registrations with multiple
    providers is OPTIONAL.

It might be good to further restructure this section to emphasize the 
distinctions between these cases:

  - outbound multiple flows. Provider gets to decide whether to
    support. If provider configures it then the RUE must do it.

  - support for multiple concurrent providers by a single RUE.
    Optional for a RUE. Provider has no say and can't tell it is
    happening.

  - multiple RUEs registering concurrently with same provider account.
    User chooses to do this. Provider can tell and should support but
    may restrict.

* Section 5.2.1, Normal Call Origination:

I don't know how to interpret the following:

    The same exceptions apply, including anonymous calls.

Same as what?

* Section 5.2.2, title

This section is titled "One-Stage Dial-Around Origination" but actually 
contains instructions for both one- and two-stage dial-around. Either 
the title should be changed (e.g., to simply "Dial-around") or else 
split into two sections.

* Section 5.2.2, two stage dial around

I am confused by the following:

    In two-stage dial-around, the To URI is the
    URI of the dial-around Provider and the domain of the URI is the
    Provider domain from the configuration.

Do you mean that the RUE allows the user to choose a dial-around 
provider from the provider list and then fetches a configuration in 
order to obtain the frontDoor URI? In that case the URI already has a 
domain, so setting the domain separately makes no sense.

Alternatively, the configuration for the frontDoor could be changed to 
include a dial string instead of a URI. With that change the above makes 
sense.

In either case this implies that the RUE has a special UI for 
dial-around where the user *picks* a provider from the provider list. It 
would be helpful to mention that assumption.

Of course the user can simply *dial* the front door of the provider 
directly or via the address book. But we don't need special procedures 
for that.

* Section 5.2.2, Two-Stage Dial-Around

While I think the diagram shown is correct one, I think there is a bug 
in the message details. The Route header field needs to be changed to:

      Route: sip:red.example.net

This will then cause the RUE to send the request to red as shown, and 
will cause red to remove the route header as also shown.

I think this will cause a need to update the provider profile to cover 
this case. (I think there was such material in an early draft of the 
profile but it didn't make it into either official version.)

* Section 5.4, phone numbers:

By calling out numbers that "can be written as an E.164 formatted phone 
number", I presume you are calling for certain editing operations to be 
performed. It would be helpful to be explicit about which edits are 
expected. I presume you mean filling in missing prefixes - at least the 
country code and its leading "+". Anything else?

IIUC toll free numbers (e.g., 800...) are technically not E.164 numbers. 
Are they to be treated as E.164 numbers for this purpose?

* Section 6.6, todo:

I see you have a note here of work still to be done. Did you forget?

* Section 8, MWI:

I can see making support of video mail optional for providers. However, 
*if* they record video mail from callers then ISTM support for MWI and 
retrieval of video mail by RUEs should be required.

* Section 9.1, provider selection:

I have a nit about this:

    To allow the user to select a relay service, the RUE MAY obtain, on
    startup, a list of Providers that provide service in a country.

While its likely that the RUE might fetch this list on startup, it isn't 
limited to that. It can do it any time. So how about:

    To allow the user to select a relay service, the RUE MAY at any
    time obtain (typically at startup) a list of Providers that provide
    service in a country.

* Section 9.4, notation

I'm unfamiliar with the OpenAPI notation you are using, and I don't find 
a reference to a specification. Can you please supply a reference?

Also, while most of it is self explanatory I am confused about repeated 
objects. It appears that you assume some of them may be repeated while 
many probably shouldn't be repeated. For instance, I would expect that 
signup would be repeated in order to specify alternative language/uri 
pairs. Similarly for dialAround and helpDesk.

I'm looking for some indication (syntactic or comment) that indicates 
this distinction.

* Section 9.4, support of 1-stage dial-around:

I see that configuration schema of the one-stage dial-around URI is 
optional. Is that intended? ISTM that use of this should be user choice, 
not provider choice. And implementation work to support this is minimal. 
(It arguably will be slightly more work for the default provider to 
support forwarding the one-stage dial-around call. I don't see any 
normative language about that, one way or the other. So that is also 
needed.)

* Section 9.4, configured SIP URIs:

There are a couple of SIP URIs in the configuration that are intended to 
be called: frontDoor and helpDesk. But the document contains no 
procedures for calling a sip URI - only for calling a dial string.

I suggest either change the configuration to contain an E.164 number 
instead of a URI, or else add some text somewhere to cover calling a SIP 
URI.

* Section 9.4, configuration for subscribers vs non-subscribers

Both subscribers and non-subscribers may have reason to fetch a 
configuration from a provider. There is only one mechanism for both of 
these cases. I guess that the provider is supposed to distinguish these 
cases by authentication. A non-subscriber won't have credentials, will 
be surprised if asked to supply them, and won't know what to respond 
with. And the provider will want to respond to bad credentials with an 
error rather than the public subset of configuration info.

Hence ISTM there must be some difference in the request to distinguish 
these cases. There are many ways to resolve this. I suggest that the 
existing ConfigurationData be split into two different object, with 
separate requests to retrieve them. One containing the info needed by a 
subscriber and the other for that needed by a non-subscriber. Then the 
subscriber data can require credentials while the non-subscriber doesn't.

That's it.

	Thanks,
	Paul