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

[Marshall Eubanks <[e-mail]>]

On Wed, May 2, 2012 at 4:27 PM, Mary Barnes <[e-mail]> wrote:
> I agree with you in general, however, the link to your slides seems to be
> broken.
>

Mary;

http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

Marshall

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