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

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

> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2012 1:27 PM
> To: Dan Wing
> Cc: Jim Barnett; Stefan Hakansson LK; [e-mail]
> Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints [was RE:
> Use Case draft]
> 
> I agree with you in general, however, the link to your slides seems to
> be broken.

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

-d

> 
> 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:WEBRTC-
> [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
> 
>