[rtcweb] interworking with non-WEBRTC endpoints [was RE: Use Case draft]

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jim Barnett
> Sent: Wednesday, May 02, 2012 7:39 AM
> To: Stefan Hakansson LK; [e-mail]
> Subject: Re: [WEBRTC] Use Case draft
> 
> When I say that this use case may not add further requirements, I mean
> that it looks like it would be possible to implement it given the
> current definitions of the protocols.  However, the current use cases
> are all written in terms of "the browser", which is not further
> defined.
> But if "browser" means Mozilla, Chrome, etc., then I think it is
> important to add a use case in which one of the end points is not a
> browser, but an enterprise gateway (which will route the call to an
> employee of its choice, and may record the call, etc.) It is important
> to note that this is not a peer-to-peer use case; the gateway is not
> the
> caller's peer.  The employee that the caller ends up talking to may be
> considered a peer, but the webRTC call does not extend all the way to
> that employee - it stops at the gateway.
> 
> This is a very different use case from any in the current document.
> That's why it's important to add it, even though (as far as I can tell)
> it doesn't require us to change any of the work we've done.

Somewhere, we need consensus on a model for interworking WEBRTC 
endpoints with non-WEBRTC endpoints.  

The decision comes down to this:  

  1. encumber WEBRTC endpoints with the interworking 
     effort, or 
  2. encumber a separate interworking device with the 
     interworking effort.

I believe we have a better chance of success with (2), where 
possible to do (2).

For some decisions, such as Consent Freshness (previously called Voice 
Hammer Attack in http://tools.ietf.org/html/rfc5245#section-18.5.1),
non-WEBRTC endpoints need to respond to those ICE connectivity
checks or have a gateway in front of them that responds to those
connectivity checks on their behalf.  This means that WEBRTC
cannot work directly with some existing SIP equipment (because
a lot of SIP equipment does not support ICE).

For other decisions, such as if we disallow un-encrypted RTP by
WEBRTC endpoints, we create a requirement that some device does
the interworking between WEBRTC endpoints (which do only SRTP) 
and non-WEBRTC endpoints (which do RTP).  That means, for that
interworking, we would adopt the interworking model on slide 7 
that I presented at IETF83,
http://www.ietf.org/proceedings/83/slides/slides-83-WEBRTC-3.pdf

However, when I presented slide 7, there were objections at the 
microphone that this model 'is broken'.  I would like to understand 
the objections so we can reach consensus on how interworking from
WEBRTC to non-WEBRTC is expected to occur.

-d


> - Jim
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf
> Of Stefan Hakansson LK
> Sent: Wednesday, May 02, 2012 4:46 AM
> To: [e-mail]
> Subject: Re: [WEBRTC] Use Case draft
> 
> On 05/01/2012 02:05 PM, Jim Barnett wrote:
> > One way to describe the use case is to let the contact center's media
> > server/gateway serve as the webRTC endpoint.  Then all the issues of
> > call delivery, call monitoring, etc. disappear.  They are handled by
> > application software that sits behind the webRTC endpoint.  The
> > company I work for makes a good living selling software that deals
> > with all these issues - including bathroom breaks - and that's how we
> > would tend to think of this case.  To us, it's a new kind of
> > call/connection coming into the contact center, which we translate
> > into SIP at the border and then handle normally.
> >
> > It's not clear to me if this use case adds any extra requirements.
> 
> I think this is important to sort out. If the use case does not add any
> extra requirements, what's the point of adding it?
> 
> > We would just have to be careful not to assume that a webRTC endpoint
> > is always a person/browser-based user agent.  It may seem a bit
> > unsettling that the webRTC endpoint can distribute the call somewhere
> > else and let others listen in, but as far as I can tell that is
> > already the case.  If Bob calls Alice with full authentication and
> > security, he can be sure that he is connected to Alice's user agent
> > and that no one in between can listen in, but there's nothing
> stopping
> 
> > Alice from recording the audio, or forwarding it to a third party.
> So
> 
> > Bob could in fact be talking to Mary if that's how Alice wants to
> > arrange things (_behind_ her user agent).  In general, Bob is assured
> > only that he is talking to someone Alice wants him to talk to, and
> > that no one can snoop without Alice's permission.  That's very much
> > the way things work with the call center - you are sure that you are
> > 1) connected securely to your bank 2) talking to someone that the
> bank
> 
> > wants you to talk to 3) being recorded or snooped on only when the
> > bank explicitly chooses to do so.
> >
> > - Jim
> >
> > -----Original Message----- From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Marshall Eubanks Sent:
> > Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc:
> > [e-mail] Subject: Re: [WEBRTC] Use Case draft
> >
> > On Mon, Apr 30, 2012 at 2:31 PM, Hutton,
> > Andrew<[e-mail]>  wrote:
> >> Whether anybody has been successful in the past with this type of
> use
> 
> >> case is I think irrelevant.
> >>
> >>
> >>
> >> The enterprise call centre use case is I think a vital use case
> >> because it is a scenario in which one user is only concerned that
> >> they can securely reach an organization/domain and is not concerned
> >> about the individual within that domain  that they communicate with.
> 
> >> A suspect quite a large percentage of WEBRTC applications will be
> >> like this and it is not covered in the current use case draft.
> >
> > I agree that this is a very useful use case and one I think is going
> > to get a lot of traction. There is a very solid business case for
> > this.  However, I have a fair amount of experience with a video call
> > center for a client, and it is not as simple as it might seem.
> >
> > The essence of course is that you get the next available person,
> i.e.,
> 
> > it is anycast. Determining who the next available person is is not
> > trivial, nor is error recovery. (If I call you, and you don't answer
> > or the call drops or whatever,  I can leave a message or try later.
> If
> 
> > I call a help desk, and this happens, I want a new agent, ideally
> > automatically.) Call forwarding (e.g., first tier to second tier
> > technical support) is essential, and it may be anycast or directed.
> > There are also some security oddities  - if I am connecting from
> home,
> 
> > I may need to authenticate, use a credit card, etc. If I am
> connecting
> 
> > from inside a store, and providing in store video technical support
> is
> 
> > big part of the market, then the store authenticates me off line and
> > the call really should just be a button push, which implies that the
> > store has previously authenticated some sort of master session. In
> > addition, unlike most video calls, in the enterprise call center a
> > supervisor may need to be able to monitor (i.e., watch) a call, and
> in
> 
> > some circumstances (financial or medical calls, for example) there
> > will need to be third party recording. I believe that  these details
> > would be different from the typical WEBRTC scenario.
> >
> > Also, there will be a temptation to do the anycasting by the
> > techniques used to load balance servers in a data center, but I think
> > that may not be sufficient. The call "center" may in fact be spread
> > completely across the planet (daytime support in the US, nighttime
> > support in India, for example) and be on multiple autonomous systems
> > (and even from people's homes), which gives rise to some of the
> > transport issues NVO3 may face, but without any opportunity for
> packet
> 
> > tagging. Plus, there will complicated rules about who can be selected
> > next. WEBRTC shouldn't worry about the intricacies of bathroom break
> > policies; these complexities should be dealt with by an
> > enterprise-side database, which to me (together with some of the
> other
> 
> > issues above) suggests that this would probably benefit from API
> > support.
> >
> > Regards Marshall
> >
> >
> >>
> >>
> >>
> >> So I think we need it.
> >>
> >>
> >>
> >> Regards
> >>
> >> Andy
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Igor Faynberg Sent: 30 April 2012 17:41 To:
> >> [e-mail]
> >>
> >>
> >> Subject: Re: [WEBRTC] Use Case draft
> >>
> >>
> >>
> >> Without numbers it is impossible to argue, but, if we talk about the
> >> perceived need, I disagree.  Think of the people who travel abroad
> >> and cannot call the 800 number. (I routinely use Web interface for
> >> calls when traveling.)
> >>
> >>
> >>
> >> I am all for  the use case, as described by Jim.
> >>
> >> Igor
> >>
> >> On 4/30/2012 9:54 AM, Tim Panton wrote:
> >>
> >> ...
> >>
> >> I can't tell you the actual numbers, but when presented with the
> >> choice of calling a toll free number
> >>
> >> or clicking a button marked "free internet call" - almost no-one on
> a
> 
> >> real, busy site clicked the button.
> >>
> >> ( for every button click there were several orders of magnitude more
> >> 0800 calls from that page).
> >>
> >>
> >>
> >>
> >>
> >> So from my perspective this is a legacy interop use case with almost
> >> zero user acceptance.
> >>
> >>
> >>
> >> (as far as I can see no-one has made this use-case desirable in
> >> practice yet.)
> >>
> >> Tim.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> WEBRTC mailing list
> >>
> >> [e-mail]
> >>
> >> https://www.ietf.org/mailman/listinfo/WEBRTC
> >>
> >>
> >> _______________________________________________ WEBRTC mailing list
> >> [e-mail] https://www.ietf.org/mailman/listinfo/WEBRTC
> >>
> > _______________________________________________ WEBRTC mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/WEBRTC
> > _______________________________________________ WEBRTC mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/WEBRTC
> 
> _______________________________________________
> WEBRTC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/WEBRTC
> _______________________________________________
> WEBRTC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/WEBRTC