Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum

[Brian Rosen <[e-mail]>]

> On Aug 29, 2019, at 3:02 PM, Paul Kyzivat <[e-mail]> wrote:
> 
> On 8/29/19 2:12 PM, Brian Rosen wrote:
>> Inline
>>> On Aug 29, 2019, at 2:06 PM, Paul Kyzivat <[e-mail]> wrote:
>>> 
>>> On 8/29/19 1:17 PM, Brian Rosen wrote:
>>>> I think we want a rum device to be able to be a good conference participant, but like nearly all conference participants, they only see a 2 party call and the bridge does the magic.
>>>> I don’t think we need to require anything else.  I think we want a bridge to be able to host a rum-compliant endpoint.
>>> 
>>> I agree conceptually. But we need to recognize that we are out ahead of VRS. Near term there is no way to get an audio/video/RTT bridge into a call with a VRS user. Because the bridge is not in the VRS iTRS it will only be able to get connected as an audio call with and interpreter
>> Both the user and the VRS CA become members of the conference, and they arrange for the user to see the CA in the “big window”.  We did this in the IVC work although the FCC provided the interpreters instead of a VRS service.  The bridge they used had a few issues but mostly it worked.
> 
> Is this deployed and in use with actual providers on real VRS calls?
Not that I know of.  It would require regulatory action dealing with compensation because the VRS CA isn’t in a 2 way call with the deaf/HoH person.  I’ve been in conferences where this was finessed by the deaf user.  He had two video devices.  He was in a VRS call with a CA who was audio dialed into the conference.  The same deaf participant was a video (and screen share) participant in the same conference.  I still don’t see any rum requirement.


> 
>>> The first form of conference is likely to be for emergency calls. But there isn't yet a specification of how to connect VRS to ng911 to get an audio/video/RTT emergency call.
>> That is incorrect.  It’s completely specified in NENA-STA-010
> 
> I haven't heard anything about this when working with providers on the VRS provider profile. But it doesn't show up on an interface between providers, so I guess there hasn't been any need for it to come up.
That is correct
> 
> But because this is limited to a private interface between the providers and NENA it isn't applicable to any other cases.
It directly affects the rum device.  The rue spec says the right thing (support RFC6881 and support REFER).
> 
>>> The other possibility is via Direct Video Calling using the VATRP system from Mitre. I guess in theory that is possible now. But it will currently have VRS users that use VRS Provider proprietary devices. Anything to support conferencing that requires extra signaling won't work until VRS users can actually use RUM-compliant RUEs. But that could work with vanilla RTT as long as the DVC device sets up the conferencing.
>> I still don’t think that surfaces any additional requirements for the rum-compatible device.
> 
> As long as no extra signaling is required. For instance, multiple RTT data channels signaled in SDP.
I don’t think so.  I think we’re headed towards a single RTT channel per participant using RFC4103.  A conference would need an RTT mixer.  Every participant has a single two way RTT channel to the bridge.  

Brian

> 
> 	Thanks,
> 	Paul