Re: [dispatch] Introducing ViPR: a new federation technology - VIDEO

Paul Kyzivat <pkyzivat@cisco.com> Tue, 10 November 2009 20:52 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1853A6900 for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 12:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.295
X-Spam-Level:
X-Spam-Status: No, score=-8.295 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjbnuGZsyijD for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 12:52:00 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DF5703A68ED for <dispatch@ietf.org>; Tue, 10 Nov 2009 12:51:59 -0800 (PST)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArACAMFh+UpAZnwMgWdsb2JhbACcBgEBFiSqPZg7hD4E
X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="scan'208";a="54102678"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 20:52:25 +0000
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAKqPPE001850; Tue, 10 Nov 2009 20:52:25 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:52:25 -0500
Received: from [161.44.182.192] ([161.44.182.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:52:25 -0500
Message-ID: <4AF9D289.2000603@cisco.com>
Date: Tue, 10 Nov 2009 15:52:25 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Bernard Aboba <bernarda@microsoft.com>
References: <F839FBA415E97B4DBD5BA437162E0603201E993A@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <F839FBA415E97B4DBD5BA437162E0603201E993A@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 10 Nov 2009 20:52:25.0151 (UTC) FILETIME=[B4F314F0:01CA6247]
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Introducing ViPR: a new federation technology - VIDEO
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 20:52:01 -0000

Bernard Aboba wrote:

> [BA] The question in my mind is whether video really is “special” (in 
> the IM&P sense) or not.  That is, today we accept the idea that anyone 
> should be able to complete a phone call to anyone else.  We also accept 
> this for SMS.  However, we don’t accept that idea for Instant Messaging 
> (which typically requires being in the buddy list). Do we accept that 
> principle for video?  I’m not sure.  There are some inherent 
> disadvantages to accepting video calls from anywhere even if we have a 
> verified phone number on the other end.  

I don't think this has much of anything to do with buddy lists.
Even when my mother calls, whether I want to transmit video will vary 
depending on current state. (Am I dressed, is there anything/anybody in 
sight that I don't want her to see, ...)

There are mechanisms and conventions yet to be developed around this. 
There has been little motivation to do it so far because there has not 
been use cases that demand it.

It seems very likely to me that a simple answer is that a video phone 
will typically *answer* in video recvonly mode, and require some manual 
intervention to start transmitting. And when initiating a call from a 
video phone there of course must also be options as to whether to 
transmit by default.

Other more sophisticated features can evolve. But I think they are all 
compatible with a "call anybody" model.

It may however put more of a premium on accurate callerid and calleeid 
information.

	Thanks,
	Paul