Re: [maitai] Roles of Sender and Receiver

Mary Barnes <mary.ietf.barnes@gmail.com> Tue, 07 December 2010 16:06 UTC

Return-Path: <mary.ietf.barnes@gmail.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 9D5FF3A697B for <maitai@core3.amsl.com>; Tue, 7 Dec 2010 08:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.141
X-Spam-Level:
X-Spam-Status: No, score=-103.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pSJk5+xA3cER for <maitai@core3.amsl.com>; Tue, 7 Dec 2010 08:06:29 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id 1D19C3A67B2 for <maitai@ietf.org>; Tue, 7 Dec 2010 08:06:29 -0800 (PST)
Received: by gxk8 with SMTP id 8so55331gxk.27 for <maitai@ietf.org>; Tue, 07 Dec 2010 08:07:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rZ29HzZPukaFI0F+HG184kxhUfc2gB/eoSMUnmDPls4=; b=yIPToGWvoN5bhOcv5zl1xshxuucD6dJnRln+8o9AMx4H+DAx+0/nYEDMkhbI2C9mql y7HlDTqTVSDvrgph/tIMYEqvOUR4aoyx60SykoNPGao09uqQtmloiUtSIr6c+y145KSI ZSOKj83PUh6xY58SOhtOcsFG9FHYJShgBi3cY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hp3OG4syEoYtOCtMAV0ELTOGsPk6HcV47IHHmRqcH/zoJXyoTztknaHemOsP8uI0JH 6+pKll/khWIBgFIW49zlrQuQZIh8+/657IxG7dZoQEQh8s8L/dHU6kvELp2GRnnSxJ36 mjJeuJJCxC9SzfWVl6Gsr+I6Zl3w8dFHYPLE0=
MIME-Version: 1.0
Received: by 10.151.48.7 with SMTP id a7mr2129582ybk.33.1291738074499; Tue, 07 Dec 2010 08:07:54 -0800 (PST)
Received: by 10.236.95.35 with HTTP; Tue, 7 Dec 2010 08:07:54 -0800 (PST)
In-Reply-To: <C4064AF1C9EC1F40868C033DB94958C703507F1E@XMB-RCD-111.cisco.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> <95E0BE2D-41B0-4FA4-9634-05D2141186D1@magorcorp.com> <C4064AF1C9EC1F40868C033DB94958C703507F1E@XMB-RCD-111.cisco.com>
Date: Tue, 07 Dec 2010 10:07:54 -0600
Message-ID: <AANLkTinyAaQuHr__QKVd9xt2BPppuZ61z88NdO-MXCFU@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Mike Hammer (hmmr)" <hmmr@cisco.com>
Content-Type: multipart/alternative; boundary="0015174c0df812cb560496d435a2"
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 16:06:30 -0000

Mike,

There is a problem statement and a use case document:
http://tools.ietf.org/id/draft-romanow-dispatch-telepresence-prob-statement-01.txt
http://tools.ietf.org/id/draft-romanow-dispatch-telepresence-use-cases-01.txt

Feedback on the use cases could be quite helpful at this stage rather than
diving into the protocol, as you suggest.  As well, starting to tease out
requirements would be quite helpful input into the WG when it is formed.
 The problem statement document is covered more or less by the charter,
although with a bit more detail that might fit into an Overview of an
architecture/framework document.

Regards,
Mary.

On Tue, Dec 7, 2010 at 9:23 AM, Mike Hammer (hmmr) <hmmr@cisco.com> wrote:

> Might be nice to have some sort of use cases, requirements, architecture
> documents first before diving into the protocols.
>
> Any wind is a good wind, if you don't know what direction to go.  :)
>
> Mike
>
>
> -----Original Message-----
> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
> Sent: Tuesday, December 07, 2010 10:10 AM
> To: Mike Hammer (hmmr)
> Cc: bruno.chatras@orange-ftgroup.com; maitai@ietf.org
> Subject: Re: [maitai] Roles of Sender and Receiver
>
> 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
>
> _______________________________________________
> maitai mailing list
> maitai@ietf.org
> https://www.ietf.org/mailman/listinfo/maitai
>