The user surprise is problem is largely masked by the user preference problem so in practice it is not a big deal. Let me explain what I mean by this. I have a video phone on my desk and so does my boss and they are on the same "PBX" and can trivially do video between each other. However, when my boss calls the number of my video phone, he does not actually expect to get video. My preferences may have totally turned that off. I may have forwarded the phone to my cell phone. I may have just "muted" the camera because I am wearing a jacket and tie and would not want him to catch me in that. The call may go to voice mail because I was on another call. Users are not particularly surprised when the video is not there. Similarly, they are not very surprised when the audio quality is radically different than they might have hoped due to the other parties preference. My boss's phone and mine both do wideband audio but we are not surprised when we don't get that. Audio preferences included putting people on speaker phones, using just about mobile phone and so on, taking calls while riding a bike a nd so on. But let's not get too wrapped up in this. This whole topic is a non issue with a validation scheme that transferred some random secret in the first second of the PSTN call then did real time validation followed by moving the call (still in first few seconds of the call) from the PSTN to the IP network. One can imagine how to insert this into the audio by using watermarking or by fingerprinting existing media. A validation scheme like this is much better than the start/stop time based one proposed in the current vipr drafts but unfortunately it requires changing something in the media path at both ends and doing that takes longer to deploy. So the current validation scheme is pretty easy to get rolled out as everything was already collecting CDR in some form but a media path validation scheme could work in real time instead of waiting to the end of the PSTN call to validate. On Jul 6, 2010, at 9:00 AM, Peter Musgrave wrote: > Yeah. Sigh. > > I guess the issue then becomes whether this is enough of a step in right direction that it can be built on - and whether it's worth the effort. > > Cullen/Jonathan - can you speak to any of the operational issues w.r.t. 'failure surprise' in the existing implementation? > > Regards, > > Peter Musgrave > > On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach <adam@xxxxxxxxxxx> wrote: > On 7/6/10 7:20 AM, Peter Musgrave wrote: > From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a "good enough" level of authentication and security. > > > You're looking in the wrong place, then. > > The problem is that VIPR really provides something more like "random failure surprise," as some portion of the call attempts must go over the (non-video-capable) PSTN. The user doesn't have any idea about, or control over, when this will happen. So while it might be something you could use for personal purposes -- where frequent video call setup failures would be okay -- I doubt it's a viable video solution in a business environment. To run a business, you need something better than "random failure surprise". > > /a > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf