Re: [maitai] Roles of Sender and Receiver

Peter Musgrave <peter.musgrave@magorcorp.com> Tue, 07 December 2010 15:08 UTC

Return-Path: <peter.musgrave@magorcorp.com>
X-Original-To: maitai@core3.amsl.com
Delivered-To: maitai@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661613A67F3 for <maitai@core3.amsl.com>; Tue, 7 Dec 2010 07:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.407
X-Spam-Level:
X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 gyVo-EVvZa1P for <maitai@core3.amsl.com>; Tue, 7 Dec 2010 07:08:39 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5FE0E3A67F1 for <maitai@ietf.org>; Tue, 7 Dec 2010 07:08:39 -0800 (PST)
Received: by ywk9 with SMTP id 9so3652ywk.31 for <maitai@ietf.org>; Tue, 07 Dec 2010 07:09:56 -0800 (PST)
Received: by 10.101.106.1 with SMTP id i1mr4908238anm.178.1291734596713; Tue, 07 Dec 2010 07:09:56 -0800 (PST)
Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id x31sm6756181ana.9.2010.12.07.07.09.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Dec 2010 07:09:55 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Peter Musgrave <peter.musgrave@magorcorp.com>
In-Reply-To: <C4064AF1C9EC1F40868C033DB94958C703507EF0@XMB-RCD-111.cisco.com>
Date: Tue, 07 Dec 2010 10:09:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <95E0BE2D-41B0-4FA4-9634-05D2141186D1@magorcorp.com>
References: <928969B1-F60B-47B8-A526-676E86BA7061@magorcorp.com><4CF9975D.4060903@cisco.com><F7377176-D185-4FC6-B012-C776783D5871@magorcorp.com><9ECCF01B52E7AB408A7EB853526421410242061C@ftrdmel0.rd.francetelecom.fr> <89B356FD-0D42-4C8B-B48F-7D70FF4E6E8F@magorcorp.com> <C4064AF1C9EC1F40868C033DB94958C703507EF0@XMB-RCD-111.cisco.com>
To: "Mike Hammer (hmmr)" <hmmr@cisco.com>
X-Mailer: Apple Mail (2.1082)
Cc: maitai@ietf.org
Subject: Re: [maitai] Roles of Sender and Receiver
X-BeenThere: maitai@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-stream Attributes for Improving Telepresence Application Interoperability <maitai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/maitai>, <mailto:maitai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/maitai>
List-Post: <mailto:maitai@ietf.org>
List-Help: <mailto:maitai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/maitai>, <mailto:maitai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 15:08:40 -0000

Nope. 

I think there are several bridges. The first is the initial call setup and mapping streams. The second is adding/removing/making changes as the meeting proceeds and the need for specific stream content changes...

Peter

On 2010-12-07, at 10:01 AM, Mike Hammer (hmmr) wrote:

> Better to use a new attribute than overload an existing attribute.
> 
> But, this also assumes we are using SDP and SIP to provide dynamic
> controls during call.
> Have we crossed that bridge yet?
> 
> Mike
> 
> 
> -----Original Message-----
> From: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On Behalf
> Of Peter Musgrave
> Sent: Tuesday, December 07, 2010 6:07 AM
> To: bruno.chatras@orange-ftgroup.com
> Cc: maitai@ietf.org
> Subject: Re: [maitai] Roles of Sender and Receiver
> 
> I think this causes confusion with hold/resume. I can have a camera and
> display but choose not to receive your video temporarily as I e.g. use
> the display to look at something else. 
> 
> Hence I don't see it a suitable for describing the static endpoint
> physical configuration. 
> 
> In principle a new SDP attribute could be used (e.g. a=device:camera)
> but this will cause all kinds of backwards compatibility issues with
> calls to devices which do not understand this. I suspect some use of the
> SDP grouping framework might come into play here...
> 
> Peter
> 
> 
> On 2010-12-07, at 3:49 AM, <bruno.chatras@orange-ftgroup.com> wrote:
> 
>>> 
>>> In fact in the first exchange we also need to provide some 
>>> information about media asymmetry (e.g. I may have three 
>>> screens, but 4 cameras or three screens and two cameras). so 
>>> my video m lines do not necessarily imply anything my ability 
>>> to send that many videos....
>>> 
>> 
>> Why can't we use one m= line per unidirectional stream and use
>> a=sendonly/a=recvonly to discrimate between screens and cameras?
> 
> _______________________________________________
> maitai mailing list
> maitai@ietf.org
> https://www.ietf.org/mailman/listinfo/maitai