[Rum] Notes from today's side meeting

["A. Jean Mahoney" <[e-mail]>]

Hi all,

Below are my summarized notes from today's meeting. Below the summary is 
more of a blow-by-blow transcript (missing pieces marked with *** or 
...). Corrections/additions welcome.

Thanks!

Jean

---------------------------------------------------------------------

RUM side meeting - IETF 104

2019 March 27, 11am - 12 pm, Paris meeting room

Chair: Brian Rosen

Agenda:

Continue discussions started in the earlier DISPATCH session regarding 
authentication issues.


Summary:

Charter should be approved shortly after the April 11 telechat.

Adam Roach, as AD, said that the working group will need to consider 
authentication issues, and added the following sentence to the charter: 
"The working group will consider issues related to authentication of the 
parties involved in the video relay call."

Chris Wendt mentioned STIR and SHAKEN for authentication mechanisms. 
Adam pointed out that once you have a human in the middle, it is hard to 
solve authentication issues. Ben Campbell said it could be done, via 
code words for instance, but the use experience would be awful. Trust 
relationships could be talked about. Eric Burger said that there were 
legal, contractual ways to enforce it in the US.

Regarding the current draft draft-rosen-rue, it was originally an effort 
to define the user-to-service interface in the US. It was written for a 
different audience and was going to be published in the Independent 
Stream, but the authors were were asked to go through the consensus 
process. The draft will be offered to the working group, but it's up to 
the WG to adopt it. The draft's US-specific solution needs to be 
expanded. If the draft is adopted, Brian will pass the editorship to 
Henning Schulzrinne since he cannot be both chair and editor.

There was a discussion of the solution covered in the draft, and the 
goal of moving from a proprietary user-to-service interface (UNI 
interface) to a standards based UNI interface that would allow a user to 
move to another service provider while keeping their device.

The current solution is a conventional video service with SIP REGISTER, 
and outbound call to outbound proxy. It has the notion of a default 
provider that the deaf user calls. An assigned interpreter places a call 
to the other end. The call from hearing person's point of view looks 
like it's from the deaf user.

The deaf person's device can be a smart phone, laptop or desktop. The 
device can be custom built hardware or it can be an application. The 
deaf community wants to add realtime text to their devices, and wants to 
be able to change providers without changing devices.

One solution would be for the user to have a WebRTC client and the 
server does the interwork to the profile. The G.711 audio codec has to 
be supported.

As for authentication, the leg from the interpreter to the called user 
is out of scope if the other leg is unknown tech. If the other leg has 
STIR credentials, those can be passed along. Adam recommended removing 
mention of MD5 from the draft.

As for provisioning, it is up to the working group to choose to pursue 
it. Adam suggested that text be added to the charter to make it less 
open ended, or RFC6011 and RFC 6080 could be analyzed, and if found 
insufficient, the WG could recharter. For configuration, Adam suggested 
the WG keep an eye on the jcard work being proposed.

For registration, Chris Wendt point out that mobile apps cannot 
constantly ping a service, but Brian pointed out that SIP Push was just 
finalized and could be used.

Brian asked if the draft was missing anything. If there is a required 
minimum frame rate, it would need to be captured in the draft. Adam said 
that once the WG started importing WebRTC information into the draft, 
they would find things to add. FEC for instance. Adam said he could be 
the WG contact for WebRTC information.

EOM

--------------------------------------------------------------------

RUM side meeting - IETF 104

2019 March 27, 11am - 12 pm, Paris meeting room

Chair: Brian Rosen

Attendees: Brian Rosen, Chris Wendt, Jean Mahoney, Eric Burger (remote), 
Andy Hutton, Adam Roach, Alan Ford, Ben Campbell. James Hamlin (remote), 
Stephen Botzko, John Martin (remote)

<setting up the bridge>

Brian Brian - Adam, when do you think chartering go through?

Adam Roach - I think it will sail through, shortly after next formal 
telechat (4/11) since it's noncontroversial.

Brian - I sent you a note regarding the issue raised during dispatch.

Adam - saw that.

Brian  - I'm looking at doing peer to peer.

adam - The working group will need to consider authentication issues.

Brian - Do you have something for us, Chris?

Chris Wendt - The idea is that you can verify other parties in the call.

Adam - Called Party ID.

Brian - Since this is explicitly Man-in-the-Middle (MitM), we want to 
know the ID of the two parties.

Adam - Once you have a human in the middle, an air gap, you can't easily 
solve that.

Brian - you have a chance of getting the signaling right, but not the 
media.

Ben Campbell - Do they get the translator or both?

Alan - is this considered a multi-party call?

Brian - It's two legs with human in between.

Ben - There are things you can do - you could exchange code words for 
instance - but the user experience would be awful. Just say that you 
don't want to go there.

Adam - I wanted to make the charter more open. Permission to look into 
these things, but not saying that you have to implement anything.

Ben - You can just state that the solution is fraught with 
authentication issues.

Eric Burger - we can acknowledge it. The conference case or PBX case 
would work in North America because you have registered entities that 
are doing the MitM. There are judicial ways to handle it, make it behave 
but not in the protocol.

Ben - talk about trust relationships.

Brian - what Eric says is USA specific.

James Hamlin - What's the agenda for this meeting?

Brian - We are continuing the dispatch discussion about authentication 
issues - whether it is possible for the two parties to be able to 
authenticate one another, when there is an explicit MitM. The IETF is 
concerned about that. The conclusion is that we'll look at it since no 
great solutions are coming to us right now.

*** - it's been discussed in a lot of forums - shaken, stir.

Brian - There are some things that we can use from that work. We'll look 
at it. We will have a working group week after next. The chairs are me 
and Paul. This meeting is subject to Note Well. Jean Mahoney is taking 
notes.

Eric - I can record this if you want.

Brian - not necessary.

John Martin - I've joined.

Brian - I don't have specific agenda. There's draft-rosen-rue. We'll 
offer it to the WG, but it's up to the WG to adopt it. Since I'm the 
co-chair of the WG, I can't be the editor of the document if it is 
adopted. Probably Henning Schulzrinne will become editor.

Ben - Does Henning have the bandwidth?

Brian - Yes, and Paul and I will be helping him. We want to pull other 
IETF work into this doc by reference - for instance, WebRTC media. Where 
do people want to go with this meeting?

Andy - I'm new to the discussion - How did we get here?

Brian - Relay is common across the world, but organized in different 
ways across the globe - government run, private run. No standards for 
the device interface. Interfaces are built on existing systems - based 
on SIP, H323. The user to service part of it is proprietary. There's a 
desire to have a consistent interface. There's an effort started in US 
to define the interface. Originally we wanted to publish in the 
Independent Stream, but we were asked to go through the consensus process.

Andy - you have a specific solution in mind?

Brian - we have a document that's US-specific, and will be expanded. 
There's a notion of a default provider, from there you can place a call 
by telephone number, to an interpreter, who places a call to the other 
end. The call from hearing person's point of view looks like it's from 
the deaf user.

Hard of hearing user -> interpreter -> receiver

Remote caller - ...

Brian - It's a very conventional video service. SIP REGISTER, outbound 
call to outbound proxy. an interpreter is assigned, they call the receiver.

Ben - It's a call into a call center.

Brian - Yes and calling the deaf user is also a call into the call center.

Andy - In the UK, it's not BT or Vodofone providing this.

Brian - in the US, there's an underlying service providing services.

Eric - There are contracts that put them into legal jurisdiction.

John - We are regulated by the FCC in the US.

Andy - Any requirements on the deaf user's device - can it be a laptop?

Brian -There's a variety devices - smart phones, laptops, desktops. The 
deaf community has desires on how this works - they want real-time text.

Ben - Are they generic clients or purpose built?

Brian - Runs the gamut. Custom built devices or apps.

Alan - We want to standardize the interface.

Brian - yes. There's no standard that lets the user keep their device 
right now.

Ben - they might have custom headers?

Brian - some do, some use SIP phones.

Chris - In some places we don't use SIP digest, I see lots of 
provisioning things here. Could this be a modern take on UNI interface?

Brian - That's up to the WG. Scope is always your friend. Saying that 
things are out of scope is your friend. I don't want to make this cover 
the most generic scope. In dispatch someone asked about using this for 
French to English translation.

Andy - The problem you are trying to solve is that the customer has a 
very expensive device and can't move it to different providers.

Ben - Downloading code to ... is common to WebRTC.

Brian - it would be great to build the interface from the WebRTC server. 
The user has a WebTRC client. The server does the interwork to the profile.

chis -  ...to UNI too.

Adam - you want the RTP stream going direct.

Chris - any of the ...

Brian - We have to support G.711.

Andy - We aren't trying to standardize the user interface?

Brian - No. Scope says UNI. others are saying NNI, don't want to get 
into that.

Ben - When we say PSTN, are we saying that it is not our problem?

Brian - Correct except for G.711. UNI interface from device to provider. 
What the provider does on the other side is out of scope. The WebRTC 
server is creating the UNI interface.

Chris - WebRTC doesn't create a ...

Adam - go direct, and the WebRTC media stack is the modern way that 
media should work.

Ben - So for the authentication cases - one end is completely out of scope.

Brian - In the media.

Ben - If the other leg is unknown tech.

Brian - We could say that, if the other leg has STIR credentials, we can 
pass along those credentials, provide a path.

adam - It can be SHAKEN compatible.

Brian -the charter doesn't restrict to just telephone numbers, but the 
common case is that both ends have TNs.

Alan - it's a 3-person conference, which doesn't map completely, but its 
like telemedicine. I don't know if that's in scope.

Brian - We want to maintain the scope that's in charter, but we also 
want the most general applicability we can get without going beyond scope.

Chris - Relay is about the 2 legs rather than a 3-way conference, it 
would add tons of requirements if we go toward conference.

Eric - We need to finish this.

Chris - We could use it for point-to-point video. That wouldn't add scope.

*** -

Brian - There's the case of a deaf person calling another deaf person.

Stephen - Are there two translators?

Brian - Try not to do that. There's a check the database for the 
telephone number to see if they are in the system, if so, they go point 
to point. Providers have different profiles. you -> your provider -> 
other provider -> other caller. The other profile is out of scope, scope 
is UNI. Any other issues or questions?

Andy - Is the management part staying in scope?

Brian - I would like to keep the provisioning part, but the WG may 
choose not to. Once we brought this into the consensus process, we lose 
control of the document. I wouldn't be surprised if it's cut.

Chris - It's an industry problem.

Adam - To address the charter comments - both Alissa and Benjamin of the 
IESG asked about provisioning. Can we add something to the charter to 
make it less open ended? I suspect if the text remains as is, there will 
be questions from the IESG.

Brian - The draft deals with contact issues and who's you provider.

Adam - use RFC... for this.

Brian - ... give you a piece of JSON, downloaded from provider

Adam - Sounds familiar - RFC6011 - there are candidate mechanisms.

Brian - no problem. Do a gap analysis and recharter if existing 
mechanisms are insufficient.

Chris - RFC 6080, download JSON

Brian - Where do you down load it from? Can add to the charter - We will 
consider existing mechanisms like 6080.

Adam - I don't see the text as problematic.

<the draft is displayed on the overhead>

Brian - This draft was done elsewhere, and written for a different 
audience. It is likely to change. The client has to implement these 
things, there are fewer requirements on the server. The client has to 
handle more variations from the providers. Client requires ICE and 
REFER, but providers don't.

Chris - On registration - are mobile apps desired? mobile apps can't 
constantly ping.

Brian - SIP push is there.

Chris - If SIP push is available, I'd advocate it.

Adam - Mentioning SIP MD5 in the draft is waving a red flag in front of 
the security guys. We don't want to create new mechanisms for MD5.

Ben - Removing MD5 cannot be left out of a bis document.

Brian - Section 6.2.2 is US-specific. We can talk about making it work. 
6.2.3 is something  the providers requested - up to us whether to keep 
it. Need to figure out how much backward compatibility to maintain, 
tolerate.

Stephen - I see a lot of MAYs. They don't seem necessary.

Brian - need to figure out what to do with those.

Andy - not going to find something that does both INFO and SRTCP

Adam - if you want to use JSON, you may want to keep an eye on the jcard 
work being proposed. Harmonizing with WebRTC, which uses FEC.

Brian - is there something missing?

Adam - once you start importing from WebRTC, you'll find things to add.

Stephen - the provider would have a minimum bandwidth they would want in 
order to do sign language translation.

Brian - they probably do have that.

Stephen Botzko  - would need know that those guys will participate.

Brian - The providers have some secret sauce. If you have a certain 
amount of bandwidth, frame rates change,...

*** - any modern codec would work here.

Brian - it will be a negotiation.

*** - if there's a desire for a minimum frame rate.

Brian - if there is, should be in here.

Adam - look at WebRTC for parameters to consider.

Brian - who should I ask for WebRTC insight?

Adam - I'm probably the contact. I've updated the charter and want to 
run by the group - "The working group will consider issues related to 
authentication of the parties involved in the video relay call."

Brian - sounds good.

EOM