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
- [dispatch] Introducing ViPR: a new federation tec… Jonathan Rosenberg
- Re: [dispatch] Introducing ViPR: a new federation… Richard Shockey
- Re: [dispatch] Introducing ViPR: a new federation… Kevin P. Fleming
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Henry Sinnreich
- Re: [dispatch] Introducing ViPR: a new federation… Jonathan Rosenberg
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Klaus Darilion
- Re: [dispatch] Introducing ViPR: a new federation… Klaus Darilion
- Re: [dispatch] Introducing ViPR: a new federation… Paul Kyzivat