Re: [maitai] Roles of Sender and Receiver

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 07 December 2010 15:42 UTC

Return-Path: <keith.drage@alcatel-lucent.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 3D8A63A69A3 for <maitai@core3.amsl.com>; Tue, 7 Dec 2010 07:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.562
X-Spam-Level:
X-Spam-Status: No, score=-105.562 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 S5SVfjRK99+A for <maitai@core3.amsl.com>; Tue, 7 Dec 2010 07:42:40 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 4000B3A6995 for <maitai@ietf.org>; Tue, 7 Dec 2010 07:42:38 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oB7FhAqs008663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Dec 2010 16:43:59 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 7 Dec 2010 16:43:57 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Mike Hammer (hmmr)" <hmmr@cisco.com>, Peter Musgrave <peter.musgrave@magorcorp.com>, "bruno.chatras@orange-ftgroup.com" <bruno.chatras@orange-ftgroup.com>
Date: Tue, 07 Dec 2010 16:41:46 +0100
Thread-Topic: [maitai] Roles of Sender and Receiver
Thread-Index: AcuV/uKTfDV8wGJcR1iyI6iYYielZgAIIkfgAAFwN/A=
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE21E3D609B@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.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>
In-Reply-To: <C4064AF1C9EC1F40868C033DB94958C703507EF0@XMB-RCD-111.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "maitai@ietf.org" <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:42:48 -0000

I dont think we have, and if we go that way, that implies to me that BFCP should have also gone the same way - which it did not.

Keith 

> -----Original Message-----
> From: maitai-bounces@ietf.org 
> [mailto:maitai-bounces@ietf.org] On Behalf Of Mike Hammer (hmmr)
> Sent: Tuesday, December 07, 2010 3:01 PM
> To: Peter Musgrave; bruno.chatras@orange-ftgroup.com
> Cc: maitai@ietf.org
> Subject: Re: [maitai] Roles of Sender and Receiver
> 
> 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
> _______________________________________________
> maitai mailing list
> maitai@ietf.org
> https://www.ietf.org/mailman/listinfo/maitai
>