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(_at_)nostrum(_dot_)com>
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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf