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

[Mary Barnes <[e-mail]>]

I agree with you in general, however, the link to your slides seems to be
broken.

Mary.

On Wed, May 2, 2012 at 12:50 PM, Dan Wing <[e-mail]> wrote:

> > -----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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>