= IETF CLUE WG design team meeting, Sept. 11, 2012

P= articipants:=A0

------------=A0

Mary Barnes

P= aul Kyzivat

Espen Berger

Jonathon Lennox

Roni Even

<= br>

Recording:

----------

https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DM= C&rID=3D8183912&rKey=3D2b332cc41122e546

Notes by Mary

-------------------

<= br>

Reviewing call flow for telemedical use case per draft-kyziva= t-clue-telemedical-callflow-00.

Roni noted that yo= u can't say that advertise is different than INVITE=A0

Paul noted that you may send advertisement and SDP is a= lready right.

Espen: this is not always the case f= or BW. =A0

Jonathan: What's downside of offeri= ng the biggest configuration? Concerned about intermediaries?

Roni stated: Let's assume that all systems we build= will understand CLUE SDP for multiplexing. =A0In this case, you can be mor= e lenient about what you do in terms of SDP and advertisement. =A0Part of t= he reasons we have a problem is because we are trying to do SDP that will w= ork for non-CLUE endpoints with first O/A. =A0Information in final SDP and = advertisement must be related. =A0Need to be consistent. =A0We are talking = about two O/As due to interop problems.=A0

Paul: Two issues:

1) Interop - more extreme i= n this case. =A0Here, the likelihood that you will contact a non-CLUE EP is= very unlikely. =A0 Could send basic SDP or should assume that a non-CLUE E= P can just use what they need and not rollover. =A0

2)=A0

Roni: refers to email on MAXSSRC. =A0Yo= u get something that you can use to get understanding of type of system. = =A0 We need to look at what we want to achieve in both SDP and advertisemen= t, then we can figure out what we can send in first INVITE.=A0

Paul: unclear. =A0We could put unlimited amount of soph= istication that supports CLUE in SDP that would still be okay with a vanill= a SIP endpoint that is well behaved (i.e., ignores what it doesn't unde= rstand).=A0

Espen: for example we need to know re-INVITE is needed = (e.g., for BW). =A0

Roni: there is RTP header exte= nsion for RTP mapping to CLUE. If you don't put in first INVITE, then i= t needs to be in re-INVITE.

Mary: trying to summarize what is being said - i.e., th= at may not need re-invite (extreme case assume that you can't put anyth= ing CLUEy in 1st INVITE). Roni clarified that would still need a re-invite.= =A0

Paul: if we think no matter what, we need a re-invite, = then there's no point of getting too much extra in the first. =A0

Jonathan: if there are assumptions made about things li= ke BW (ie., total for sessions versus single channel), then might have prob= lems with how info about multi-sources are interpreted.

Roni: The major reason for 1st and 2nd invites, is due = to interop. Is there something we can get out of 1st exchange that will hel= p us get a better ADVERTISE?

Note, the above is a = general problem and not unique to this call flow, thus need to consider tha= t this stuff is already done and discuss details of this specific call flow= .=A0

Paul: assume advertisements and configurations have bee= n exchanged - everything is up. =A0Now, one side wants to change config. = =A0Need to consider whether we reserved enough BW initially. =A0

Espen: works if you are decreasing BW, for example. =A0Should al= low you to keep same SDP.

Situations where you can= 't keep same SDP:

- is this driven by new config?

- OR, if SDP is dependent only on advertisements, then can do things a diff= erent way.

Roni: you need to change if you are changing multiplex= ing.

Paul: either need to allow that possibility o= r disallow. =A0

Conclusion: assume that SDP can change in case of confi= g. =A0 But, can optimize.=A0

Jonathan: what is the= distinction between these cases? =A0 Is this an optimization or a fundamen= tally different req for a use case.=A0

Mary: you need to know data first. =A0

Paul: you put a bunch of stuff in advertisement, etc. and in SDP, = but you might figure out that is redundant.=A0

Esp= en: we have identified two cases of re-invite: BW and changing media sessio= ns. =A0If everyone won't do SSRC multiplexing, then need to consider. = =A0If we start with basic, then get consensus and then add more complex. = =A0In Stockholm, aiming for a solution that doesn't make re-invites are= not req'd. =A0..Don't understand re-invites in this call flow. =A0= Don't see any info in re-invite that is needed.=A0

Paul: was assuming worst case.

Espen: look at Rob/Allyn's call flow document. =A0

Roni: without real SDP and info, can't work really do this.

Paul: agree simple case, but need to consider more comp= lex. =A0Agree to do work to elaborate messages in a simpler call flow. =A0<= /div>

Simple MCU case and point to point. =A0

Espen: thinks MCU should send an advertisement that there is no = CLUE info.=A0

Paul: should it configure?

Espen: no. =A0It doesn't have media to send.

Paul: consequence is that it needs to send another advertise= ment when another party joins. =A0

Espen: if both = parties do SDP O/A and want to use =85

Roni: you p= resented it that MCU doesn't know anything. =A0It wouldn't open CLU= E channel.=A0

Paul: it should open channel even if it's not going= to send messages. Do you need to send a configure? =A0

Jonathan: what does it mean if you don't send a configure? =A0Or = maybe you send an empty configure?=A0

Paul: what if you get another advertisement and decide = not to send another configure.=A0

Jonathan; depend= s upon existing config - does it still work?

Espen= : exAMPLE, CLUe EP offers two captures and then changes to one. =A0If you r= emove something, you need to send another configure. =A0

Jonathan: if you ask for one and two and then two is re= moved, may not need to do anything. =A0

Paul: some= of this is existing O/A issue.

Jonathan: in SDP O= /A, always have to respond. =A0

Paul: there is a window where you're still getting = old.=A0

Jonathan: not sure this is properly writte= n down anywhere.

Espen: main thing is to make reco= mmendations, what you are expected to do if you receive a new advertisement= ? =A0

Paul: yes - like O/A. =A0CLUE first and then SDP? =A0

Espen: depends upon what you want to change.=A0

Haven't really resolved anything - more questions= (but that's okay=A0

Jonathan: clearly if you want to add a new 5 tuple, mus= t be done in SDP. If there is a way of saying in CLUE, we need to send this= capture in this media flow, you need a way to say that.=A0

Espen: if call flow could be updated with best case for MCU (ver= sus p2p in Allyn's call flow document)

Roni: e= ventually there may be a case if you are transcoding, as that may change it= thus for simplest case, assume it is not transcoding.=A0

Paul: IF simpler case is a two person conference? =A0 T= hen this flow is that, until you get a third participant.=A0

Conclusion: Start adding the detailed information to the flow - = also include text for the scenario along with assumptions (e.g., CLUE only = endpoint, etc.).=A0

=A0

--bcaec554daa2efbf8904c980f73d-- From mary.ietf.barnes@gmail.com Wed Sep 12 06:23:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3A221F854E for ; Wed, 12 Sep 2012 06:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[AWL=0.226, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkSpE5tLvCwK for ; Wed, 12 Sep 2012 06:23:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0921F854C for ; Wed, 12 Sep 2012 06:23:21 -0700 (PDT) Received: by lahm15 with SMTP id m15so1196886lah.31 for ; Wed, 12 Sep 2012 06:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g4Cysc0NFfTzFTS+4Cjer4966NDMXoIZZZ8SrqqBJOE=; b=outjzi7eo3xCXU1J1g4wDFZS+ZUPA2Ua+zNosrl7N+X0Hn3UMwBAmlFFt1vkQoyDh+ QavYKlfmjjhd+TcmYAvD75uowpZBErokUEbxrEtsOls+gBGiRlZCMbYr3mfw1S6yQhpI 3tq+cqHPNCRqPDl7sVkb32pifg24He4BRv/suJBkh1aF0hEzAzf1++Ahg02kDqhKpcU/ HW9ajXBWVfNuY17KY+ZeAACojY6WAgLwm17oI2yzUBucpptmEfAF8Fp8GRC3oB30BtaK SvwCrrba3Zd7XeDOuUF9qQDbJkg490DC36UkhCLk1vaqrlFS100RV02YyE2udYG2q0N0 liZQ== MIME-Version: 1.0 Received: by 10.112.23.36 with SMTP id j4mr5885920lbf.71.1347456200691; Wed, 12 Sep 2012 06:23:20 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Wed, 12 Sep 2012 06:23:20 -0700 (PDT) Date: Wed, 12 Sep 2012 08:23:20 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e0cb4efe30f23151c804c9811869 Subject: [clue] Reminder: CLUE Deadlines and other logistics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:23:23 -0000 --e0cb4efe30f23151c804c9811869 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The WG wiki contains all the necessary information for the meeting: http://trac.tools.ietf.org/wg/clue/trac/wiki As a reminder, the end of today is the deadline for drafts for the meeting. If you plan to submit something but may have an issue with this deadline, please let us know ASAP. The plan is to get a revised agenda out tomorrow which identifies relevant drafts, issue #s from the tracker and email threads for each agenda item. Also, as a reminder there is a doodle for dinner on Wed. night. If you plan to attend, then please fill out the doodle - the place I have chosen is Macaroni Grill (which has a GF menu). They should be able to accommodate any other dietary restrictions. As a note for those who have been able to attend the design team calls, you might find it very helpful to at least review the minutes and perhaps listen to some of the recordings to better understand the context for some of the topics that will be discussed next week. Please let me know if you have any other questions about the meeting. Thanks, Mary. --e0cb4efe30f23151c804c9811869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The WG wiki contains all the necessary informati= on for the meeting:

http://trac.tools.ietf.org/wg/clue/trac/wiki

As a reminder, the end of today is the deadline for drafts f= or the meeting. =A0If you plan to submit something but may have an issue wi= th this deadline, please let us know ASAP. =A0 The plan is to get a revised= agenda out tomorrow which identifies relevant drafts, issue #s from the tr= acker and email threads for each agenda item. =A0

Also, as a reminder there is a doodle for dinner on Wed= . night. =A0If you plan to attend, then please fill out the doodle - the pl= ace I have chosen is Macaroni Grill (which has a GF menu). =A0They should b= e able to accommodate any other dietary restrictions. =A0=A0

As a note for those who have been able to attend the de= sign team calls, you might find it very helpful to at least review the minu= tes and perhaps listen to some of the recordings to better understand the c= ontext for some of the topics that will be discussed next week.

Please let me know if you have any other question= s about the meeting.

Thanks,

Mary.=A0 --e0cb4efe30f23151c804c9811869-- From ron.even.tlv@gmail.com Thu Sep 13 06:22:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5823E21F8501 for ; Thu, 13 Sep 2012 06:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5buyBRgIdfav for ; Thu, 13 Sep 2012 06:22:48 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E754121F8433 for ; Thu, 13 Sep 2012 06:22:41 -0700 (PDT) Received: by bkty12 with SMTP id y12so515697bkt.31 for ; Thu, 13 Sep 2012 06:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=pyL2xDacNzeNPgToVh2ycWIfPJ2i81uNI041Icr7jVk=; b=qb755DWtmKdRfHgW6sNp7bb7j5eqpuX4GtzPJlFgJwdh2hnCClvEbTLywKdeCC2ba+ bwKIa5CJc1G2wVyt2r+KMOeIQ41nyGAZ8EyBuEMqxzakX77wyH18ucWNhxHIZYZAEpED dFWOBVRR4BsnzTNVBFKJBH63Ph+Nabym5VaQ4PwAQ4yL6sDnYkOL5ZnG0azdIKnx00YX Bk66GeO+GfelW68Xr1s4Nf4y4+fUxP5TXD4WuYmFdQ5D5QW41qpsd3Dud0V51kbDCDSn jnylWpKrlfJ7hsCXtY2t7OZhMDrbWqmwyodzCVESl9VsBd6m3dzpBQQ4i8pYrDTp1V3K U8BA== Received: by 10.205.123.10 with SMTP id gi10mr1079036bkc.9.1347542560695; Thu, 13 Sep 2012 06:22:40 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id he8sm14347792bkc.3.2012.09.13.06.22.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2012 06:22:38 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" , "Paul Kyzivat" References: In-Reply-To: Date: Thu, 13 Sep 2012 16:20:50 +0200 Message-ID: <004d01cd91ba$fcea4ad0$f6bee070$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01CD91CB.C073DE20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaNVfEc9Z0y6hNT4/6jpMDsqs7k5hvCohQ Content-Language: en-us Subject: Re: [clue] Reminder: CLUE Deadlines and other logistics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 13:22:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004E_01CD91CB.C073DE20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mary, There are two individual drafts that are not in the CLUE tools page http://tools.ietf.org/wg/clue/ They are both from Christian Groves https://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/ https://datatracker.ietf.org/doc/draft-groves-clue-scene-clarifications/ Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 12 September, 2012 3:23 PM To: CLUE Subject: [clue] Reminder: CLUE Deadlines and other logistics for Interim meeting Hi all, The WG wiki contains all the necessary information for the meeting: http://trac.tools.ietf.org/wg/clue/trac/wiki As a reminder, the end of today is the deadline for drafts for the meeting. If you plan to submit something but may have an issue with this deadline, please let us know ASAP. The plan is to get a revised agenda out tomorrow which identifies relevant drafts, issue #s from the tracker and email threads for each agenda item. Also, as a reminder there is a doodle for dinner on Wed. night. If you plan to attend, then please fill out the doodle - the place I have chosen is Macaroni Grill (which has a GF menu). They should be able to accommodate any other dietary restrictions. As a note for those who have been able to attend the design team calls, you might find it very helpful to at least review the minutes and perhaps listen to some of the recordings to better understand the context for some of the topics that will be discussed next week. Please let me know if you have any other questions about the meeting. Thanks, Mary. ------=_NextPart_000_004E_01CD91CB.C073DE20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary,

There are two individual drafts that are not in the CLUE tools = page http://tools.ietf.org/wg/clue/

They are both from Christian Groves

https://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/

https://datatracker.ietf.org/doc/draft-groves-clue-scene-clarifi= cations/

Roni

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 12 September, 2012 3:23 PM
To: = CLUE
Subject: [clue] Reminder: CLUE Deadlines and other = logistics for Interim meeting

Hi = all,

The WG wiki contains all the necessary information for = the meeting:

http://trac.tools.i= etf.org/wg/clue/trac/wiki

As a reminder, the end of today is the deadline for = drafts for the meeting. If you plan to submit something but may = have an issue with this deadline, please let us know ASAP. The = plan is to get a revised agenda out tomorrow which identifies relevant = drafts, issue #s from the tracker and email threads for each agenda = item.

Also, as a reminder there is a doodle for dinner on = Wed. night. If you plan to attend, then please fill out the doodle = - the place I have chosen is Macaroni Grill (which has a GF menu). = They should be able to accommodate any other dietary restrictions. =

As a note for those who have been able to attend the = design team calls, you might find it very helpful to at least review the = minutes and perhaps listen to some of the recordings to better = understand the context for some of the topics that will be discussed = next week.

Please let me know if you have any other questions = about the meeting.

Thanks,

Mary.

------=_NextPart_000_004E_01CD91CB.C073DE20-- From mary.ietf.barnes@gmail.com Thu Sep 13 10:42:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAB121F85DA for ; Thu, 13 Sep 2012 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.364 X-Spam-Level: X-Spam-Status: No, score=-103.364 tagged_above=-999 required=5 tests=[AWL=0.234, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyF7bhhX1I6z for ; Thu, 13 Sep 2012 10:42:36 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60DFA21F8450 for ; Thu, 13 Sep 2012 10:42:35 -0700 (PDT) Received: by lahm15 with SMTP id m15so2256791lah.31 for ; Thu, 13 Sep 2012 10:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7dqy+Q0tgfzs6Sd5lUy8JwItU1N+66HmEnYHAJYsZKI=; b=gFAM8jbWl6Evt87wOFL6DSY9j6AxZ40aTwGjh8XTP0WoNHF7lj/kxDr+t9Hw9FZpG7 dumV+L5xNvwdJxikuo8/zLxFZwEBjjUoHfpoObAfy0oKj8bnAdhHKq4BhvKoePDpdRPB 20+SRvfpQCTVH2nnRHkTc+6z9OuigN45MIMZ5dEaXdatw3tG5aofjBpkWJx1fOuklDSZ YG5LHzgA/OzLSMX+9Rp5/V+s4XAYHIa0QEADK8cvGS4c4APF/QsGykQAhyggFOmaZsir 6pszmw2/eWfHtVzDGY5c4DdsrinfEmICuFI4itWWHHfPpNkAwivlTl3gqnJdp+kRplWE mEiA== MIME-Version: 1.0 Received: by 10.152.110.40 with SMTP id hx8mr52674lab.9.1347558154250; Thu, 13 Sep 2012 10:42:34 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Thu, 13 Sep 2012 10:42:34 -0700 (PDT) In-Reply-To: <004d01cd91ba$fcea4ad0$f6bee070$@gmail.com> References: <004d01cd91ba$fcea4ad0$f6bee070$@gmail.com> Date: Thu, 13 Sep 2012 12:42:34 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=bcaec54ee71819286e04c998d570 Cc: Paul Kyzivat , CLUE Subject: Re: [clue] Reminder: CLUE Deadlines and other logistics for Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:42:36 -0000 --bcaec54ee71819286e04c998d570 Content-Type: text/plain; charset=ISO-8859-1 They are out there now. There is almost always a delay in information getting propagated to the tools pages as the info is not updated in realtime. Mary. On Thu, Sep 13, 2012 at 9:20 AM, Roni Even wrote: > Hi Mary,**** > > There are two individual drafts that are not in the CLUE tools page > http://tools.ietf.org/wg/clue/**** > > ** ** > > They are both from Christian Groves**** > > ** ** > > https://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/**** > > https://datatracker.ietf.org/doc/draft-groves-clue-scene-clarifications/** > ** > > ** ** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 12 September, 2012 3:23 PM > *To:* CLUE > *Subject:* [clue] Reminder: CLUE Deadlines and other logistics for > Interim meeting**** > > ** ** > > Hi all,**** > > ** ** > > The WG wiki contains all the necessary information for the meeting:**** > > http://trac.tools.ietf.org/wg/clue/trac/wiki**** > > ** ** > > As a reminder, the end of today is the deadline for drafts for the > meeting. If you plan to submit something but may have an issue with this > deadline, please let us know ASAP. The plan is to get a revised agenda > out tomorrow which identifies relevant drafts, issue #s from the tracker > and email threads for each agenda item. **** > > ** ** > > Also, as a reminder there is a doodle for dinner on Wed. night. If you > plan to attend, then please fill out the doodle - the place I have chosen > is Macaroni Grill (which has a GF menu). They should be able to > accommodate any other dietary restrictions. **** > > ** ** > > As a note for those who have been able to attend the design team calls, > you might find it very helpful to at least review the minutes and perhaps > listen to some of the recordings to better understand the context for some > of the topics that will be discussed next week.**** > > ** ** > > Please let me know if you have any other questions about the meeting.**** > > ** ** > > Thanks,**** > > Mary. **** > --bcaec54ee71819286e04c998d570 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable They are out there now. There is almost always a delay in information getti= ng propagated to the tools pages as the info is not updated in realtime.=A0=

Mary.=A0

On Thu, Sep = 13, 2012 at 9:20 AM, Roni Even <ron.even.tlv@gmail.com>= wrote:

Hi Mary,

There are two individual = drafts that are not in the CLUE=A0 tools page http://tools.ietf.org/wg/clue/

=A0<= /p>
They are both from Chr= istian Groves

=A0<= /p>
ht= tps://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/

https://datatracker.ietf.org/doc/draft-groves-clue-scene-clarifications/=

=A0<= /p>
Roni

=A0<= /p>
From: clue-bounces@ietf.org= [mailto:clu= e-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 12 September, 2012 3:23 PM
To: CLUE
Subject: [clue] Reminder: CLUE Deadlines and other logistics for Interim meeting<= u>
=A0<= /p>
Hi all,
=A0
The WG wiki contain= s all the necessary information for the meeting:

http://trac.tools.ietf.org/wg/clue/trac/wiki<= /u>
=A0
=

As a reminder, the end of today is the deadline for drafts for the meeting.= =A0If you plan to submit something but may have an issue with this deadlin= e, please let us know ASAP. =A0 The plan is to get a revised agenda out tom= orrow which identifies relevant drafts, issue #s from the tracker and email= threads for each agenda item. =A0

=A0
Also, as a reminder there is a doodle for dinner on Wed. nig= ht. =A0If you plan to attend, then please fill out the doodle - the place I= have chosen is Macaroni Grill (which has a GF menu). =A0They should be abl= e to accommodate any other dietary restrictions. =A0=A0

=A0
As a note for those who have been able to attend the design = team calls, you might find it very helpful to at least review the minutes a= nd perhaps listen to some of the recordings to better understand the contex= t for some of the topics that will be discussed next week.
=A0
Please let me know if you have any other questions abou= t the meeting.
= =A0

Thanks,
Mary.=A0

<= /blockquote>

--bcaec54ee71819286e04c998d570-- From espeberg@cisco.com Fri Sep 14 07:36:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718F521F850D for ; Fri, 14 Sep 2012 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o59NPBxxQ0za for ; Fri, 14 Sep 2012 07:36:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7143221F84DD for ; Fri, 14 Sep 2012 07:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6183; q=dns/txt; s=iport; t=1347633396; x=1348842996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aPoLPZ/8ZDkA9m8Re5LBH2s22Nk9eXW7f5j5UjsOEEU=; b=YKVN5xvHqJqdQ+FUGlLTi2TyryACTYX7zLswzzkLnuH0qLyrEFSQS3kx vQyHbfSnqOiHyy84ByMMnSjsNJksf13ddqmlxCMjMIZKGPXraHs1t02Dg LNt0/D14eVVlU8wfC37OCnIJmCcH15Y6H0aJfKiMc5ZtA9FcU7XTvsDsk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKg/U1CtJV2Z/2dsb2JhbABFDrtvgQeCIAEBAQMBAQEBDwEnLgMDCQIFBwQCAQgOAwQBAQEKFAkHJwsUCQgCBA4FCAEZh2UGC5suoBqLFYYIYAOWdY0kgWmCLDqCFw X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="118645058" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 14 Sep 2012 14:36:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8EEaZgJ013057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 14:36:35 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.118]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 14 Sep 2012 09:36:29 -0500 From: "Espen Berger (espeberg)" To: Paul Kyzivat Thread-Topic: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt Thread-Index: AQHNkDU9XyBWotZCBUOtPKYwFPhoaZeJ6rlg Date: Fri, 14 Sep 2012 14:36:28 +0000 Message-ID: References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> In-Reply-To: <504F5DE1.2020003@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.107] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--60.943600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:36:37 -0000 My main point is that the initial INVITE can be sufficient for a call with = CLUE negotiated media stream.=20 One of the exceptions we have discussed is the requirement to upgrade bandw= idth to allow for three camera/screen scenarios, which is typically not som= ething you allocate in the network before you really knows it's needed. In = this case the re-INVITE is optional and there a clear user story to explain= why and when we want to do it. I think necessary, and useful, to write down user stories to explain why a = SIP re-INVITE is needed. With user stories it's much easier to discuss how= to solve actual problems with protocols.=20 =20 Cheers=20 -Espen=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 11. september 2012 17:51 To: Espen Berger (espeberg) Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemed= ical-callflow-00.txt On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: > My comments > > * It's natural that the MCU send an empty advertisement when the classroo= m dials in as the first participant. If not, the classroom does not now if = the conference is empty. The configuration message can be delayed, since yo= u are mainly indicating that you do not want to receive media. That is a good idea. I'll do it. > * I think the MCU can delay its initial configure message until the class= room and surgery has done the configure message. With only two participant = in the conference, you do not have to configure each endpoint to send media= until the MCU knows someone request the media and also know the media rest= rictions. > > * What is the purpose for the second INVITE from the classroom, where the= text says 'to cover both configurations'. The initial SIP INVITE can be su= fficient for payload numbers, bw, codec-parameters. Based on the draft-roma= now-clue-call-flow document the main example for a re-invite is to increase= or decrease bandwidth allocation. I assumed a consistent approach to first invites - that they are vanilla an= d minimal, and so aren't sufficient to support the actual CLUE call. I have assumed that the invite with o/a to get things *right* is done *after* the Configure messages have been exchanged, when the needs are full= y known. There is a chance for glare here - with both sides trying to initi= ate the o/a. I assumed for this flow that this doesn't happen - either one = side waits for the other to go first, or else the timing results in one sid= e sending first and that this then causes the other side to omit its own at= tempt because it is no longer needed. Because the two sides make independent choices of what to receive, and thes= e may not be symmetric, it is necessary to consider both configurations to = decide what to offer. Or else, one side sends an offer sufficient for itsel= f, and then the other side may have to both answer and then make a new offe= r to add things it needs. This needs more discussion. I didn't sense any consensus or even common und= erstanding of the issues and tradeoffs. > * The expert endpoints does not send a Configure message to the MCU. Is t= his intentional or not? I'm having trouble remembering what I was thinking. :-) I think the note "D= efer config till get request" is a mistake, and the expert should go ahead = and send a Configure. I'll fix it. Thanks, Paul > Cheers > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 11. september 2012 00:52 > To: CLUE > Subject: Re: [clue] New Version Notification for=20 > draft-kyzivat-clue-telemedical-callflow-00.txt > > I just submitted in initial version of a new callflow draft. > A more useful link for it is: > > https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl > ow/ > > This is complementary to draft-romanow-clue-call-flow. > > I've focused on a particular use case rather than a generic one. I've cho= sen the telemedical use case, and a special case of that use case. > Some of the interesting things about this case are that it includes an=20 > MCU, and more than two endpoints. And those endpoints are not all=20 > identical. (The latter point won't have obvious impact until more=20 > detail is filled in.) > > And for now I've considered only the ladder diagram of sip and clue messa= ges. That leaves a lot out. I expect it to be expanded to include the conte= nt of those messages. But before getting to that there are already a bunch = of issues to sort out, that will impact what goes in those messages. > > I don't have any illusions that this version is "correct". It is just a s= tarting point to discuss the issues. So please send comments. Maybe we will= have time to talk about it at tomorrow's design team meeting, and/or at th= e interim next week. > > Thanks, > Paul > > On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >> >> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the=20 >> IETF repository. >> >> Filename: draft-kyzivat-clue-telemedical-callflow >> Revision: 00 >> Title: CLUE Telemedical Use Case Callflow >> Creation date: 2012-09-11 >> WG ID: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-= telemedical-callflow-00.txt >> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-tele= medical-callflow >> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-telemedic= al-callflow-00 >> >> >> Abstract: >> This is the beginning of an example call flow for an instantiation = of >> the use case described in the telemedical use case >> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >> later. >> >> >> >> >> The IETF Secretariat >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From espeberg@cisco.com Fri Sep 14 07:45:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1581421F8514 for ; Fri, 14 Sep 2012 07:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZJXYvTtMfhU for ; Fri, 14 Sep 2012 07:45:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3C85721F850D for ; Fri, 14 Sep 2012 07:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3245; q=dns/txt; s=iport; t=1347633953; x=1348843553; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xVqzS44zQ4RmK2i+Zf7T79Z8nAk55vQ/luBCSRWcwvc=; b=SNueotaDcXW88aP3rENVo7f8QXuASt4gJnbjEhFjiErewV1q0qU848eZ MQq8j8yCDV4a3ubT4zJo5nnRGy1uGrbjQMlIoSEGnrO1e2+Zr3nSAzEBM 0LfIiSxuv/u7AbEhicDWlCYOg/0JU/pxN8gjMnP0XU/hZsfhBRpdAFSGU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOpBU1CtJXG+/2dsb2JhbABFDrtvgQeCIAEBAQQBAQEPASc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgah2sLmzSgHYsVJIVkYAOWdY0kgWmCLDqCFw X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="121651739" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 14 Sep 2012 14:45:52 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8EEjqlO002487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 14:45:52 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 09:45:51 -0500 From: "Espen Berger (espeberg)" To: Roni Even , Paul Kyzivat , Roni Even Thread-Topic: [clue] Ticket #16: Need a term for a particular encoding of a capture Thread-Index: AQHNj4hEDH3Kh9UcMUyXPikWwz7jB5eEX3kAgAWPV/A= Date: Fri, 14 Sep 2012 14:45:51 +0000 Message-ID: References: <50477793.6050607@alum.mit.edu> <006f01cd8f7c$17c474c0$474d5e40$@gmail.com>, <504E3BA3.8000606@alum.mit.edu> <760B7D45D1EFF74988DBF5C2122830C205B442A1@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B442A1@szxpml504-mbx.exmail.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.107] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--43.876600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'CLUE' Subject: Re: [clue] Ticket #16: Need a term for a particular encoding of a capture X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:45:54 -0000 I like the srcname draft since its allow a producer to forward meta-informa= tion and attached it to an SSRC. The intent seems to be to be able to forwa= rd names like a capture name and a quality modifier. The example from the d= raft matched my suggestion to do a 'capture' .'encoding-quality'=20 However I do not think its represent a name for the actual encoded stream, = so I still like the capture encoding to represent a single media stream.=20 Cheers=20 =20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 10. september 2012 22:47 To: Paul Kyzivat; Roni Even Cc: 'CLUE' Subject: Re: [clue] Ticket #16: Need a term for a particular encoding of a = capture Paul, srcname describes a specific encoding by using a hierarchy tree. I am not s= ure what byou mean by a source but it can be used to describe a specific en= conding using the hierarchy. For example v1.hires and v1.lowres. Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Monday, September 10, 2012 10:12 PM To: Roni Even Cc: 'CLUE' Subject: Re: [clue] Ticket #16: Need a term for a particular encoding of a = capture On 9/10/12 1:45 PM, Roni Even wrote: > Hi, > Maybe we can use srcname as proposed in=20 > http://tools.ietf.org/id/draft-westerlund-avtext-rtcp-sdes-srcname-01. > txt > Roni IIUC, SRCNAME would correspond to what Jonathan has been calling a "source"= . But it wouldn't correspond to a Capture, or and Encoding, or an RTP strea= m that is the result of applying a particular encoding to a capture. So, while I think SRCNAME is useful, I don't see its applicability to ticke= t #16. Thanks, Paul > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 05 September, 2012 6:02 PM > To: CLUE > Subject: [clue] Ticket #16: Need a term for a particular encoding of a=20 > capture > > I am trying to kick off discussion to get this one resolved. > > Here is the description of the issue: > >> We keep encountering places where the term "capture" is used but=20 >> where what is meant is a specific encoding of a capture. >> (It is possible to request/send multiple encodings of the same >> capture.) >> >> We need a specific term, and definition, for this concept. >> This should be in the framework, and it and other documents should be=20 >> fixed to use this new term where appropriate. > > A few things come to mind: > > - "capture encoding" - the obvious choice > - "encoded capture" > - "capture rendition" > > Or any of the above with a "-" instead of the space. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Sep 14 07:50:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8276921F851A for ; Fri, 14 Sep 2012 07:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=0.255, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np-+EJYADBdd for ; Fri, 14 Sep 2012 07:50:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5D21F84A5 for ; Fri, 14 Sep 2012 07:50:45 -0700 (PDT) Received: by lbky2 with SMTP id y2so3023124lbk.31 for ; Fri, 14 Sep 2012 07:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hgb1iZXJQbpMg0Wmg854rtGdP1T+nwcMOR5243xMrr4=; b=l/hnLJNlQDvGBmwM5Ul5yBUNXTWJibg+H5XUtrTnthOIyAcs+wA2vUVFnB1TIaYwFw dbQc2UIa30tHdAm9SMi8A9/augt4Yd10tl68ArkK+XcOflvEtpi0zIeH1iSgvcTRas9D 0zXWfgciySn52T/sA/86K4Y0zWkUrZcJW4uogoiB0rZXes7T0c1l7tqPgKt1dT5aG8tt 4tdb3wmbF2J4UOkHBbqDhT+sLMEcf+qJQu46SVCsNfC/g6ZHLX6HgaV5b7FDIAZqkoHD OBqfwljPsJ460ImZrR638abo9tEqiRY30LF7lijbDGLNkW8sFaO3Y0k0g3W9YQQvR8rp fimg== MIME-Version: 1.0 Received: by 10.112.26.106 with SMTP id k10mr1175689lbg.100.1347634244320; Fri, 14 Sep 2012 07:50:44 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Fri, 14 Sep 2012 07:50:44 -0700 (PDT) In-Reply-To: References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> Date: Fri, 14 Sep 2012 09:50:44 -0500 Message-ID: From: Mary Barnes To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=bcaec554dbbe6b7d7404c9aa8c9e Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:50:50 -0000 --bcaec554dbbe6b7d7404c9aa8c9e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 14, 2012 at 9:36 AM, Espen Berger (espeberg) wrote: > My main point is that the initial INVITE can be sufficient for a call with > CLUE negotiated media stream. > > One of the exceptions we have discussed is the requirement to upgrade > bandwidth to allow for three camera/screen scenarios, which is typically > not something you allocate in the network before you really knows it's > needed. In this case the re-INVITE is optional and there a clear user story > to explain why and when we want to do it. > > I think necessary, and useful, to write down user stories to explain why a > SIP re-INVITE is needed. With user stories it's much easier to discuss how > to solve actual problems with protocols. > [MB] Absolutely. I think we need to start with what Alice and Bob want to do and then work down to what signaling is required to achieve that. [/MB] > > Cheers > > -Espen > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 11. september 2012 17:51 > To: Espen Berger (espeberg) > Cc: CLUE > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: > > My comments > > > > * It's natural that the MCU send an empty advertisement when the > classroom dials in as the first participant. If not, the classroom does not > now if the conference is empty. The configuration message can be delayed, > since you are mainly indicating that you do not want to receive media. > > That is a good idea. I'll do it. > > > * I think the MCU can delay its initial configure message until the > classroom and surgery has done the configure message. With only two > participant in the conference, you do not have to configure each endpoint > to send media until the MCU knows someone request the media and also know > the media restrictions. > > > > * What is the purpose for the second INVITE from the classroom, where > the text says 'to cover both configurations'. The initial SIP INVITE can be > sufficient for payload numbers, bw, codec-parameters. Based on the > draft-romanow-clue-call-flow document the main example for a re-invite is > to increase or decrease bandwidth allocation. > > I assumed a consistent approach to first invites - that they are vanilla > and minimal, and so aren't sufficient to support the actual CLUE call. > > I have assumed that the invite with o/a to get things *right* is done > *after* the Configure messages have been exchanged, when the needs are > fully known. There is a chance for glare here - with both sides trying to > initiate the o/a. I assumed for this flow that this doesn't happen - either > one side waits for the other to go first, or else the timing results in one > side sending first and that this then causes the other side to omit its own > attempt because it is no longer needed. > > Because the two sides make independent choices of what to receive, and > these may not be symmetric, it is necessary to consider both configurations > to decide what to offer. Or else, one side sends an offer sufficient for > itself, and then the other side may have to both answer and then make a new > offer to add things it needs. > > This needs more discussion. I didn't sense any consensus or even common > understanding of the issues and tradeoffs. > > > * The expert endpoints does not send a Configure message to the MCU. Is > this intentional or not? > > I'm having trouble remembering what I was thinking. :-) I think the note > "Defer config till get request" is a mistake, and the expert should go > ahead and send a Configure. I'll fix it. > > Thanks, > Paul > > > Cheers > > > > -Espen > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: 11. september 2012 00:52 > > To: CLUE > > Subject: Re: [clue] New Version Notification for > > draft-kyzivat-clue-telemedical-callflow-00.txt > > > > I just submitted in initial version of a new callflow draft. > > A more useful link for it is: > > > > https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl > > ow/ > > > > This is complementary to draft-romanow-clue-call-flow. > > > > I've focused on a particular use case rather than a generic one. I've > chosen the telemedical use case, and a special case of that use case. > > Some of the interesting things about this case are that it includes an > > MCU, and more than two endpoints. And those endpoints are not all > > identical. (The latter point won't have obvious impact until more > > detail is filled in.) > > > > And for now I've considered only the ladder diagram of sip and clue > messages. That leaves a lot out. I expect it to be expanded to include the > content of those messages. But before getting to that there are already a > bunch of issues to sort out, that will impact what goes in those messages. > > > > I don't have any illusions that this version is "correct". It is just a > starting point to discuss the issues. So please send comments. Maybe we > will have time to talk about it at tomorrow's design team meeting, and/or > at the interim next week. > > > > Thanks, > > Paul > > > > On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: > >> > >> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt > >> has been successfully submitted by Paul H. Kyzivat and posted to the > >> IETF repository. > >> > >> Filename: draft-kyzivat-clue-telemedical-callflow > >> Revision: 00 > >> Title: CLUE Telemedical Use Case Callflow > >> Creation date: 2012-09-11 > >> WG ID: Individual Submission > >> Number of pages: 8 > >> URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow-00.txt > >> Status: > http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow > >> Htmlized: > http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 > >> > >> > >> Abstract: > >> This is the beginning of an example call flow for an instantiation > of > >> the use case described in the telemedical use case > >> [I-D.xiao-clue-telemedical-use-case]. More detail will be added > >> later. > >> > >> > >> > >> > >> The IETF Secretariat > >> > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec554dbbe6b7d7404c9aa8c9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2012 at 9:36 AM, Espen Berger (espeberg) = <espeberg@cisco.= com> wrote:

My main point is that the initial INVITE can be sufficient for a call with = CLUE negotiated media stream.

One of the exceptions we have discussed is the requirement to upgrade bandw= idth to allow for three camera/screen scenarios, which is typically not som= ething you allocate in the network before you really knows it's needed.= In this case the re-INVITE is optional and there a clear user story to exp= lain why and when we want to do it.

I think necessary, and useful, to write down user stories to explain why a = SIP re-INVITE is needed. =A0With user stories it's much easier to discu= ss how to solve actual problems with protocols.
[MB] A= bsolutely. =A0I think we need to start with what Alice and Bob want to do a= nd then work down to what signaling is required to achieve that. =A0[/MB]

Cheers

-Espen

-----Original Message-----
From: Paul Kyzivat [mailto:pkyziva= t@alum.mit.edu]
Sent: 11. september 2012 17:51
To: Espen Berger (espeberg)

Cc: CLUE
Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemed= ical-callflow-00.txt

On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote:
> My comments
>
> * It's natural that the MCU send an empty advertisement when the c= lassroom dials in as the first participant. If not, the classroom does not = now if the conference is empty. The configuration message can be delayed, s= ince you are mainly indicating that you do not want to receive media.

That is a good idea. I'll do it.

> * I think the MCU can delay its initial configure message until the cl= assroom and surgery has done the configure message. With only two participa= nt in the conference, you do not have to configure each endpoint to send me= dia until the MCU knows someone request the media and also know the media r= estrictions.
>
> * What is the purpose for the second INVITE from the classroom, where = the text says 'to cover both configurations'. The initial SIP INVIT= E can be sufficient for payload numbers, bw, codec-parameters. Based on the= draft-romanow-clue-call-flow document the main example for a re-invite is = to increase or decrease bandwidth allocation.

I assumed a consistent approach to first invites - that they are vanilla an= d minimal, and so aren't sufficient to support the actual CLUE call.
I have assumed that the invite with o/a to get things *right* is done
*after* the Configure messages have been exchanged, when the needs are full= y known. There is a chance for glare here - with both sides trying to initi= ate the o/a. I assumed for this flow that this doesn't happen - either = one side waits for the other to go first, or else the timing results in one= side sending first and that this then causes the other side to omit its ow= n attempt because it is no longer needed.

Because the two sides make independent choices of what to receive, and thes= e may not be symmetric, it is necessary to consider both configurations to = decide what to offer. Or else, one side sends an offer sufficient for itsel= f, and then the other side may have to both answer and then make a new offe= r to add things it needs.

This needs more discussion. I didn't sense any consensus or even common= understanding of the issues and tradeoffs.

> * The expert endpoints does not send a Configure message to the MCU. I= s this intentional or not?

I'm having trouble remembering what I was thinking. :-) I think the not= e "Defer config till get request" is a mistake, and the expert sh= ould go ahead and send a Configure. I'll fix it.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Cheers
>
> -Espen
>
> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> Of Paul Kyzivat
> Sent: 11. september 2012 00:52
> To: CLUE
> Subject: Re: [clue] New Version Notification for
> draft-kyzivat-clue-telemedical-callflow-00.txt
>
> I just submitted in initial version of a new callflow draft.
> A more useful link for it is:
>
> https://datatracker.ietf.org/doc/draft-kyziv= at-clue-telemedical-callfl
> ow/
>
> This is complementary to draft-romanow-clue-call-flow.
>
> I've focused on a particular use case rather than a generic one. I= 've chosen the telemedical use case, and a special case of that use cas= e.
> Some of the interesting things about this case are that it includes an=
> MCU, and more than two endpoints. And those endpoints are not all
> identical. (The latter point won't have obvious impact until more<= br> > detail is filled in.)
>
> And for now I've considered only the ladder diagram of sip and clu= e messages. That leaves a lot out. I expect it to be expanded to include th= e content of those messages. But before getting to that there are already a= bunch of issues to sort out, that will impact what goes in those messages.=
>
> I don't have any illusions that this version is "correct"= ;. It is just a starting point to discuss the issues. So please send commen= ts. Maybe we will have time to talk about it at tomorrow's design team = meeting, and/or at the interim next week.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> On 9/10/12 6:34 PM, intern= et-drafts@ietf.org wrote:
>>
>> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.t= xt
>> has been successfully submitted by Paul H. Kyzivat and posted to t= he
>> IETF repository.
>>
>> Filename: =A0 =A0 draft-kyzivat-clue-telemedical-callflow
>> Revision: =A0 =A0 00
>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CLUE Telemedical Use Case Ca= llflow
>> Creation date: =A0 =A0 =A0 =A02012-09-11
>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Individual Submission
>> Number of pages: 8
>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflo= w-00.txt
>> Status: =A0 =A0 =A0 =A0 =A0http://datat= racker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow
>> Htmlized: =A0 =A0 =A0 =A0http://tools.iet= f.org/html/draft-kyzivat-clue-telemedical-callflow-00
>>
>>
>> Abstract:
>> =A0 =A0 =A0This is the beginning of an example call flow for an in= stantiation of
>> =A0 =A0 =A0the use case described in the telemedical use case
>> =A0 =A0 =A0[I-D.xiao-clue-telemedical-use-case]. =A0More detail wi= ll be added
>> =A0 =A0 =A0later.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec554dbbe6b7d7404c9aa8c9e-- From ron.even.tlv@gmail.com Fri Sep 14 08:17:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2930521F8514 for ; Fri, 14 Sep 2012 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnFN-MhYnyLm for ; Fri, 14 Sep 2012 08:17:16 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 959FD21F84F9 for ; Fri, 14 Sep 2012 08:17:15 -0700 (PDT) Received: by bkty12 with SMTP id y12so1223937bkt.31 for ; Fri, 14 Sep 2012 08:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=fkAoEOoDjgh5m/VlyKZQWrcdh6X9JDwencL7uOvatpE=; b=lOLnTAf+XEzpXhuENcGwGflVjgqflwJRuMjaF7cF66dCE/qlQKw8/lmRSuOZ7qBAZG JBX6brWrQ7BQ/6MIvaZNf0InsjvvPwkmUQsFCQ1dlTsLDZWPoVjd2bXdHOpQjn2Ay0ch qflXov5fG3PsD3KUgYqxTSPUpV0sHByAwp562yHIIicAcaKU6S2rOVcsU/hV64uMwgYI Gcs1HDaqW4Ry0JCvXTCYDBKUqx2lkPQsdV0ST+R8WVQzuwh036lhn5smpJXBbo+/Q0WT tUWvErdU2iKQ0MQspcGpe84hZbe2rPlouewOlSW4MlWDBu1IZ0IWERs+jkG7WJgVc+CD wglA== Received: by 10.204.157.22 with SMTP id z22mr1433612bkw.4.1347635834436; Fri, 14 Sep 2012 08:17:14 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id g6sm1422761bkg.2.2012.09.14.08.17.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 08:17:13 -0700 (PDT) From: "Roni Even" To: "'Espen Berger $espeberg$'" , "'Paul Kyzivat'" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> In-Reply-To: Date: Fri, 14 Sep 2012 18:15:25 +0200 Message-ID: <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2V0ZruT0VU3TL5YJEy+G6AcvvAJeBKjPAckOTB0CK35f6QHipvOUlqHICYA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:17:17 -0000 Hi Paul, Other examples 1. want to add a transport connection when adding a new RTP stream (example opening a presentation stream during the call or changing the presentation stream) will require a re-invite. In general every change in the transport connection whether adding a new one when not SSRC multiplexing or changing the connection (transfer the call or some of the media streams without the CLUE channel) 2. Changing the codec used (H.26 to H.264 or audio codec) may require a re-invite. 3. When an MCU wants to change the common mode of a call when a party is added or dropped. There are more use cases. I see there are two types of requirements for re-invite. The first is during call setup in a point to point and multipoint call where the first invite is used to negotiate CLUE support and address interoperability with non-CLUE systems. After going the negotiation of the CLUE state there will be a need for a re-invite to correlate the CLUE and SDP states. The second during the call is when there is a change in the CLUE state that MAY require a correlation with the SDP state or even just an SDP state change like changing codec or addressing network or application issues that do not change the CLUE state. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Espen Berger (espeberg) Sent: 14 September, 2012 4:36 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt My main point is that the initial INVITE can be sufficient for a call with CLUE negotiated media stream. One of the exceptions we have discussed is the requirement to upgrade bandwidth to allow for three camera/screen scenarios, which is typically not something you allocate in the network before you really knows it's needed. In this case the re-INVITE is optional and there a clear user story to explain why and when we want to do it. I think necessary, and useful, to write down user stories to explain why a SIP re-INVITE is needed. With user stories it's much easier to discuss how to solve actual problems with protocols. Cheers -Espen -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 11. september 2012 17:51 To: Espen Berger (espeberg) Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: > My comments > > * It's natural that the MCU send an empty advertisement when the classroom dials in as the first participant. If not, the classroom does not now if the conference is empty. The configuration message can be delayed, since you are mainly indicating that you do not want to receive media. That is a good idea. I'll do it. > * I think the MCU can delay its initial configure message until the classroom and surgery has done the configure message. With only two participant in the conference, you do not have to configure each endpoint to send media until the MCU knows someone request the media and also know the media restrictions. > > * What is the purpose for the second INVITE from the classroom, where the text says 'to cover both configurations'. The initial SIP INVITE can be sufficient for payload numbers, bw, codec-parameters. Based on the draft-romanow-clue-call-flow document the main example for a re-invite is to increase or decrease bandwidth allocation. I assumed a consistent approach to first invites - that they are vanilla and minimal, and so aren't sufficient to support the actual CLUE call. I have assumed that the invite with o/a to get things *right* is done *after* the Configure messages have been exchanged, when the needs are fully known. There is a chance for glare here - with both sides trying to initiate the o/a. I assumed for this flow that this doesn't happen - either one side waits for the other to go first, or else the timing results in one side sending first and that this then causes the other side to omit its own attempt because it is no longer needed. Because the two sides make independent choices of what to receive, and these may not be symmetric, it is necessary to consider both configurations to decide what to offer. Or else, one side sends an offer sufficient for itself, and then the other side may have to both answer and then make a new offer to add things it needs. This needs more discussion. I didn't sense any consensus or even common understanding of the issues and tradeoffs. > * The expert endpoints does not send a Configure message to the MCU. Is this intentional or not? I'm having trouble remembering what I was thinking. :-) I think the note "Defer config till get request" is a mistake, and the expert should go ahead and send a Configure. I'll fix it. Thanks, Paul > Cheers > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: 11. september 2012 00:52 > To: CLUE > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > I just submitted in initial version of a new callflow draft. > A more useful link for it is: > > https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl > ow/ > > This is complementary to draft-romanow-clue-call-flow. > > I've focused on a particular use case rather than a generic one. I've chosen the telemedical use case, and a special case of that use case. > Some of the interesting things about this case are that it includes an > MCU, and more than two endpoints. And those endpoints are not all > identical. (The latter point won't have obvious impact until more > detail is filled in.) > > And for now I've considered only the ladder diagram of sip and clue messages. That leaves a lot out. I expect it to be expanded to include the content of those messages. But before getting to that there are already a bunch of issues to sort out, that will impact what goes in those messages. > > I don't have any illusions that this version is "correct". It is just a starting point to discuss the issues. So please send comments. Maybe we will have time to talk about it at tomorrow's design team meeting, and/or at the interim next week. > > Thanks, > Paul > > On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >> >> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the >> IETF repository. >> >> Filename: draft-kyzivat-clue-telemedical-callflow >> Revision: 00 >> Title: CLUE Telemedical Use Case Callflow >> Creation date: 2012-09-11 >> WG ID: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow- 00.txt >> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow >> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >> >> >> Abstract: >> This is the beginning of an example call flow for an instantiation of >> the use case described in the telemedical use case >> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >> later. >> >> >> >> >> The IETF Secretariat >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Sep 14 08:32:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8621F84B8 for ; Fri, 14 Sep 2012 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcF-ywSwCoMM for ; Fri, 14 Sep 2012 08:32:11 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36121F84B6 for ; Fri, 14 Sep 2012 08:32:11 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id z1KG1j0020SCNGk593YCw5; Fri, 14 Sep 2012 15:32:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id z3YR1j00N3ZTu2S3V3YRCd; Fri, 14 Sep 2012 15:32:25 +0000 Message-ID: <50534DF8.5060402@alum.mit.edu> Date: Fri, 14 Sep 2012 11:32:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:32:12 -0000 On 9/14/12 10:36 AM, Espen Berger (espeberg) wrote: > My main point is that the initial INVITE can be sufficient for a call with CLUE negotiated media stream. > > One of the exceptions we have discussed is the requirement to upgrade bandwidth to allow for three camera/screen scenarios, which is typically not something you allocate in the network before you really knows it's needed. In this case the re-INVITE is optional and there a clear user story to explain why and when we want to do it. > > I think necessary, and useful, to write down user stories to explain why a SIP re-INVITE is needed. With user stories it's much easier to discuss how to solve actual problems with protocols. My thinking is that all of the reinvite/o/a's are potentially optional: if the existing SDP is compatible with new advertisement/configuration than the o/a can be omitted. But in principle the SDP might need to change. So to start I put those in. When the details are filled in the redundant ones can be omitted. But one thing I wanted to explore is the timing relationship between advertisements/configs and O/As. I see a number of possibilities: - each config *may* demand an SDP change. If so, we need to decide if: * the SDP change must precede the config change * the SDP change must follow the config change * additions to the SDP must precede the config change, and deletions from the SDP must follow the config change - config changes never require SDP changes because there is requirement that SDP be compatible with *any* possible configuration of the advertisement. Each advertisement *may* demand an SDP change. If so, we need to decide if: (alternatives analogous to those above) ISTM that different configurations of the same advertisement can demand widely divergent sets of resources. So I think it must be configurations that drive SDP changes. Thanks, Paul > Cheers > > -Espen > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 11. september 2012 17:51 > To: Espen Berger (espeberg) > Cc: CLUE > Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >> My comments >> >> * It's natural that the MCU send an empty advertisement when the classroom dials in as the first participant. If not, the classroom does not now if the conference is empty. The configuration message can be delayed, since you are mainly indicating that you do not want to receive media. > > That is a good idea. I'll do it. > >> * I think the MCU can delay its initial configure message until the classroom and surgery has done the configure message. With only two participant in the conference, you do not have to configure each endpoint to send media until the MCU knows someone request the media and also know the media restrictions. >> >> * What is the purpose for the second INVITE from the classroom, where the text says 'to cover both configurations'. The initial SIP INVITE can be sufficient for payload numbers, bw, codec-parameters. Based on the draft-romanow-clue-call-flow document the main example for a re-invite is to increase or decrease bandwidth allocation. > > I assumed a consistent approach to first invites - that they are vanilla and minimal, and so aren't sufficient to support the actual CLUE call. > > I have assumed that the invite with o/a to get things *right* is done > *after* the Configure messages have been exchanged, when the needs are fully known. There is a chance for glare here - with both sides trying to initiate the o/a. I assumed for this flow that this doesn't happen - either one side waits for the other to go first, or else the timing results in one side sending first and that this then causes the other side to omit its own attempt because it is no longer needed. > > Because the two sides make independent choices of what to receive, and these may not be symmetric, it is necessary to consider both configurations to decide what to offer. Or else, one side sends an offer sufficient for itself, and then the other side may have to both answer and then make a new offer to add things it needs. > > This needs more discussion. I didn't sense any consensus or even common understanding of the issues and tradeoffs. > >> * The expert endpoints does not send a Configure message to the MCU. Is this intentional or not? > > I'm having trouble remembering what I was thinking. :-) I think the note "Defer config till get request" is a mistake, and the expert should go ahead and send a Configure. I'll fix it. > > Thanks, > Paul > >> Cheers >> >> -Espen >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 11. september 2012 00:52 >> To: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I just submitted in initial version of a new callflow draft. >> A more useful link for it is: >> >> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl >> ow/ >> >> This is complementary to draft-romanow-clue-call-flow. >> >> I've focused on a particular use case rather than a generic one. I've chosen the telemedical use case, and a special case of that use case. >> Some of the interesting things about this case are that it includes an >> MCU, and more than two endpoints. And those endpoints are not all >> identical. (The latter point won't have obvious impact until more >> detail is filled in.) >> >> And for now I've considered only the ladder diagram of sip and clue messages. That leaves a lot out. I expect it to be expanded to include the content of those messages. But before getting to that there are already a bunch of issues to sort out, that will impact what goes in those messages. >> >> I don't have any illusions that this version is "correct". It is just a starting point to discuss the issues. So please send comments. Maybe we will have time to talk about it at tomorrow's design team meeting, and/or at the interim next week. >> >> Thanks, >> Paul >> >> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>> >>> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt >>> has been successfully submitted by Paul H. Kyzivat and posted to the >>> IETF repository. >>> >>> Filename: draft-kyzivat-clue-telemedical-callflow >>> Revision: 00 >>> Title: CLUE Telemedical Use Case Callflow >>> Creation date: 2012-09-11 >>> WG ID: Individual Submission >>> Number of pages: 8 >>> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow >>> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >>> >>> >>> Abstract: >>> This is the beginning of an example call flow for an instantiation of >>> the use case described in the telemedical use case >>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>> later. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From pkyzivat@alum.mit.edu Fri Sep 14 08:44:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE29721F8419 for ; Fri, 14 Sep 2012 08:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pqGpLEMI8j5 for ; Fri, 14 Sep 2012 08:44:30 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D055821F84FD for ; Fri, 14 Sep 2012 08:44:29 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id yz8D1j0030Fqzac593kWNc; Fri, 14 Sep 2012 15:44:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id z3kN1j00N3ZTu2S3U3kN3p; Fri, 14 Sep 2012 15:44:22 +0000 Message-ID: <505350D9.9070200@alum.mit.edu> Date: Fri, 14 Sep 2012 11:44:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> In-Reply-To: <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:44:30 -0000 I agree with this. One comment below. On 9/14/12 12:15 PM, Roni Even wrote: > Hi Paul, > Other examples > > 1. want to add a transport connection when adding a new RTP stream (example > opening a presentation stream during the call or changing the presentation > stream) will require a re-invite. In general every change in the transport > connection whether adding a new one when not SSRC multiplexing or changing > the connection (transfer the call or some of the media streams without the > CLUE channel) > 2. Changing the codec used (H.26 to H.264 or audio codec) may require a > re-invite. > 3. When an MCU wants to change the common mode of a call when a party is > added or dropped. > > There are more use cases. > > I see there are two types of requirements for re-invite. > > The first is during call setup in a point to point and multipoint call where > the first invite is used to negotiate CLUE support and address > interoperability with non-CLUE systems. After going the negotiation of the > CLUE state there will be a need for a re-invite to correlate the CLUE and > SDP states. > > The second during the call is when there is a change in the CLUE state that > MAY require a correlation with the SDP state or even just an SDP state > change like changing codec or addressing network or application issues that > do not change the CLUE state. I think we don't yet know if there will be anything that makes sense to change in SDP without some corresponding change in advertisement or config. If there is, it must be something for which there are alternative ways to accomplish the configuration. I'm not sure what that might be, but in principle I see it could happen. Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Espen Berger (espeberg) > Sent: 14 September, 2012 4:36 PM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > My main point is that the initial INVITE can be sufficient for a call with > CLUE negotiated media stream. > > One of the exceptions we have discussed is the requirement to upgrade > bandwidth to allow for three camera/screen scenarios, which is typically not > something you allocate in the network before you really knows it's needed. > In this case the re-INVITE is optional and there a clear user story to > explain why and when we want to do it. > > I think necessary, and useful, to write down user stories to explain why a > SIP re-INVITE is needed. With user stories it's much easier to discuss how > to solve actual problems with protocols. > > Cheers > > -Espen > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 11. september 2012 17:51 > To: Espen Berger (espeberg) > Cc: CLUE > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >> My comments >> >> * It's natural that the MCU send an empty advertisement when the classroom > dials in as the first participant. If not, the classroom does not now if the > conference is empty. The configuration message can be delayed, since you are > mainly indicating that you do not want to receive media. > > That is a good idea. I'll do it. > >> * I think the MCU can delay its initial configure message until the > classroom and surgery has done the configure message. With only two > participant in the conference, you do not have to configure each endpoint to > send media until the MCU knows someone request the media and also know the > media restrictions. >> >> * What is the purpose for the second INVITE from the classroom, where the > text says 'to cover both configurations'. The initial SIP INVITE can be > sufficient for payload numbers, bw, codec-parameters. Based on the > draft-romanow-clue-call-flow document the main example for a re-invite is to > increase or decrease bandwidth allocation. > > I assumed a consistent approach to first invites - that they are vanilla and > minimal, and so aren't sufficient to support the actual CLUE call. > > I have assumed that the invite with o/a to get things *right* is done > *after* the Configure messages have been exchanged, when the needs are fully > known. There is a chance for glare here - with both sides trying to initiate > the o/a. I assumed for this flow that this doesn't happen - either one side > waits for the other to go first, or else the timing results in one side > sending first and that this then causes the other side to omit its own > attempt because it is no longer needed. > > Because the two sides make independent choices of what to receive, and these > may not be symmetric, it is necessary to consider both configurations to > decide what to offer. Or else, one side sends an offer sufficient for > itself, and then the other side may have to both answer and then make a new > offer to add things it needs. > > This needs more discussion. I didn't sense any consensus or even common > understanding of the issues and tradeoffs. > >> * The expert endpoints does not send a Configure message to the MCU. Is > this intentional or not? > > I'm having trouble remembering what I was thinking. :-) I think the note > "Defer config till get request" is a mistake, and the expert should go ahead > and send a Configure. I'll fix it. > > Thanks, > Paul > >> Cheers >> >> -Espen >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 11. september 2012 00:52 >> To: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I just submitted in initial version of a new callflow draft. >> A more useful link for it is: >> >> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl >> ow/ >> >> This is complementary to draft-romanow-clue-call-flow. >> >> I've focused on a particular use case rather than a generic one. I've > chosen the telemedical use case, and a special case of that use case. >> Some of the interesting things about this case are that it includes an >> MCU, and more than two endpoints. And those endpoints are not all >> identical. (The latter point won't have obvious impact until more >> detail is filled in.) >> >> And for now I've considered only the ladder diagram of sip and clue > messages. That leaves a lot out. I expect it to be expanded to include the > content of those messages. But before getting to that there are already a > bunch of issues to sort out, that will impact what goes in those messages. >> >> I don't have any illusions that this version is "correct". It is just a > starting point to discuss the issues. So please send comments. Maybe we will > have time to talk about it at tomorrow's design team meeting, and/or at the > interim next week. >> >> Thanks, >> Paul >> >> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>> >>> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt >>> has been successfully submitted by Paul H. Kyzivat and posted to the >>> IETF repository. >>> >>> Filename: draft-kyzivat-clue-telemedical-callflow >>> Revision: 00 >>> Title: CLUE Telemedical Use Case Callflow >>> Creation date: 2012-09-11 >>> WG ID: Individual Submission >>> Number of pages: 8 >>> URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow- > 00.txt >>> Status: > http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow >>> Htmlized: > http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >>> >>> >>> Abstract: >>> This is the beginning of an example call flow for an instantiation > of >>> the use case described in the telemedical use case >>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>> later. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From pkyzivat@alum.mit.edu Fri Sep 14 08:48:15 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6FA21F84F8 for ; Fri, 14 Sep 2012 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuQFhQCsvyFo for ; Fri, 14 Sep 2012 08:48:15 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id DBECA21F84C4 for ; Fri, 14 Sep 2012 08:48:14 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id z2dq1j0010bG4ec5A3oJ6l; Fri, 14 Sep 2012 15:48:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id z3o61j00Z3ZTu2S3P3o73f; Fri, 14 Sep 2012 15:48:07 +0000 Message-ID: <505351BC.8000907@alum.mit.edu> Date: Fri, 14 Sep 2012 11:48:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <50534DF8.5060402@alum.mit.edu> In-Reply-To: <50534DF8.5060402@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:48:15 -0000 On 9/14/12 11:32 AM, Paul Kyzivat wrote: > On 9/14/12 10:36 AM, Espen Berger (espeberg) wrote: >> My main point is that the initial INVITE can be sufficient for a call >> with CLUE negotiated media stream. >> >> One of the exceptions we have discussed is the requirement to upgrade >> bandwidth to allow for three camera/screen scenarios, which is >> typically not something you allocate in the network before you really >> knows it's needed. In this case the re-INVITE is optional and there a >> clear user story to explain why and when we want to do it. >> >> I think necessary, and useful, to write down user stories to explain >> why a SIP re-INVITE is needed. With user stories it's much easier to >> discuss how to solve actual problems with protocols. I forgot to mention - yes, I agree that the callflow requires explanatory text for *why* the messages are there, and in the order they are. It was more than I had time to do in the first version. Thanks, Paul From ron.even.tlv@gmail.com Fri Sep 14 09:27:13 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C012021F8484 for ; Fri, 14 Sep 2012 09:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xr8i7YNVVya for ; Fri, 14 Sep 2012 09:27:13 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7511C21F845F for ; Fri, 14 Sep 2012 09:27:12 -0700 (PDT) Received: by bkty12 with SMTP id y12so1266515bkt.31 for ; Fri, 14 Sep 2012 09:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=1WhGo76Qh7aDRoiehrLbiN5hVaHwATTLC6aCV8wBy+4=; b=q+96P/LW+yf2BUODBlURDeRn/zbCWOhltJLi5GSBOUBBmU/9nINXEZbH00kKEsfoDe knDPkYY+8djHA7i41Y9xs0evoie5XMoGNTp1pU9GdV43PXODlp7M/I9Z0CGgJeyfnxI0 Gm1ZRv/agLWyfYdaT7p7J5k0DTO6s9FnNWJDTOLSaO+pTq94TFvdOEBON+8E8BIZitRI oK7rPOP9WJpEnhbY1SMLP11SfqpnuuI49DnhNR/GAYYL8Uy3Wd5ppl3wfo+eBk1+JYWN amG3RE6bvw4eEii0vGSoyFHMHgvif7JuRlT8QYAlUUcSgMsKGoa4l6pAq3uoWHHj5CXv Kmgw== Received: by 10.204.148.12 with SMTP id n12mr1645936bkv.6.1347640031176; Fri, 14 Sep 2012 09:27:11 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id f7sm1559099bkv.1.2012.09.14.09.27.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 09:27:09 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> In-Reply-To: <505350D9.9070200@alum.mit.edu> Date: Fri, 14 Sep 2012 19:25:19 +0200 Message-ID: <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2V0ZruT0VU3TL5YJEy+G6AcvvAJeBKjPAckOTB0CK35f6QHipvOUAmjyTpoBzzyP5ZaAHTjg Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 16:27:13 -0000 Paul, I can think of an example for SDP only with no CLUE but it depends how simulcast is implemented. A switch from high res to low res of the same capture (example room view) without a change in the CLUE Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 14 September, 2012 5:44 PM To: Roni Even Cc: 'Espen Berger (espeberg)'; 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt I agree with this. One comment below. On 9/14/12 12:15 PM, Roni Even wrote: > Hi Paul, > Other examples > > 1. want to add a transport connection when adding a new RTP stream > (example opening a presentation stream during the call or changing the > presentation > stream) will require a re-invite. In general every change in the > transport connection whether adding a new one when not SSRC > multiplexing or changing the connection (transfer the call or some of > the media streams without the CLUE channel) 2. Changing the codec used > (H.26 to H.264 or audio codec) may require a re-invite. > 3. When an MCU wants to change the common mode of a call when a party > is added or dropped. > > There are more use cases. > > I see there are two types of requirements for re-invite. > > The first is during call setup in a point to point and multipoint call > where the first invite is used to negotiate CLUE support and address > interoperability with non-CLUE systems. After going the negotiation of > the CLUE state there will be a need for a re-invite to correlate the > CLUE and SDP states. > > The second during the call is when there is a change in the CLUE state > that MAY require a correlation with the SDP state or even just an SDP > state change like changing codec or addressing network or application > issues that do not change the CLUE state. I think we don't yet know if there will be anything that makes sense to change in SDP without some corresponding change in advertisement or config. If there is, it must be something for which there are alternative ways to accomplish the configuration. I'm not sure what that might be, but in principle I see it could happen. Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Espen Berger (espeberg) > Sent: 14 September, 2012 4:36 PM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > My main point is that the initial INVITE can be sufficient for a call > with CLUE negotiated media stream. > > One of the exceptions we have discussed is the requirement to upgrade > bandwidth to allow for three camera/screen scenarios, which is > typically not something you allocate in the network before you really knows it's needed. > In this case the re-INVITE is optional and there a clear user story to > explain why and when we want to do it. > > I think necessary, and useful, to write down user stories to explain > why a SIP re-INVITE is needed. With user stories it's much easier to > discuss how to solve actual problems with protocols. > > Cheers > > -Espen > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 11. september 2012 17:51 > To: Espen Berger (espeberg) > Cc: CLUE > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >> My comments >> >> * It's natural that the MCU send an empty advertisement when the >> classroom > dials in as the first participant. If not, the classroom does not now > if the conference is empty. The configuration message can be delayed, > since you are mainly indicating that you do not want to receive media. > > That is a good idea. I'll do it. > >> * I think the MCU can delay its initial configure message until the > classroom and surgery has done the configure message. With only two > participant in the conference, you do not have to configure each > endpoint to send media until the MCU knows someone request the media > and also know the media restrictions. >> >> * What is the purpose for the second INVITE from the classroom, where >> the > text says 'to cover both configurations'. The initial SIP INVITE can > be sufficient for payload numbers, bw, codec-parameters. Based on the > draft-romanow-clue-call-flow document the main example for a re-invite > is to increase or decrease bandwidth allocation. > > I assumed a consistent approach to first invites - that they are > vanilla and minimal, and so aren't sufficient to support the actual CLUE call. > > I have assumed that the invite with o/a to get things *right* is done > *after* the Configure messages have been exchanged, when the needs are > fully known. There is a chance for glare here - with both sides trying > to initiate the o/a. I assumed for this flow that this doesn't happen > - either one side waits for the other to go first, or else the timing > results in one side sending first and that this then causes the other > side to omit its own attempt because it is no longer needed. > > Because the two sides make independent choices of what to receive, and > these may not be symmetric, it is necessary to consider both > configurations to decide what to offer. Or else, one side sends an > offer sufficient for itself, and then the other side may have to both > answer and then make a new offer to add things it needs. > > This needs more discussion. I didn't sense any consensus or even > common understanding of the issues and tradeoffs. > >> * The expert endpoints does not send a Configure message to the MCU. >> Is > this intentional or not? > > I'm having trouble remembering what I was thinking. :-) I think the > note "Defer config till get request" is a mistake, and the expert > should go ahead and send a Configure. I'll fix it. > > Thanks, > Paul > >> Cheers >> >> -Espen >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 11. september 2012 00:52 >> To: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I just submitted in initial version of a new callflow draft. >> A more useful link for it is: >> >> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >> l >> ow/ >> >> This is complementary to draft-romanow-clue-call-flow. >> >> I've focused on a particular use case rather than a generic one. I've > chosen the telemedical use case, and a special case of that use case. >> Some of the interesting things about this case are that it includes >> an MCU, and more than two endpoints. And those endpoints are not all >> identical. (The latter point won't have obvious impact until more >> detail is filled in.) >> >> And for now I've considered only the ladder diagram of sip and clue > messages. That leaves a lot out. I expect it to be expanded to include > the content of those messages. But before getting to that there are > already a bunch of issues to sort out, that will impact what goes in those messages. >> >> I don't have any illusions that this version is "correct". It is just >> a > starting point to discuss the issues. So please send comments. Maybe > we will have time to talk about it at tomorrow's design team meeting, > and/or at the interim next week. >> >> Thanks, >> Paul >> >> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>> >>> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt >>> has been successfully submitted by Paul H. Kyzivat and posted to the >>> IETF repository. >>> >>> Filename: draft-kyzivat-clue-telemedical-callflow >>> Revision: 00 >>> Title: CLUE Telemedical Use Case Callflow >>> Creation date: 2012-09-11 >>> WG ID: Individual Submission >>> Number of pages: 8 >>> URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-cal > lflow- > 00.txt >>> Status: > http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflo > w >>> Htmlized: > http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >>> >>> >>> Abstract: >>> This is the beginning of an example call flow for an >>> instantiation > of >>> the use case described in the telemedical use case >>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>> later. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From pkyzivat@alum.mit.edu Fri Sep 14 10:00:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5797321F851E for ; Fri, 14 Sep 2012 10:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_LOW=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL0X1eWJ+6d6 for ; Fri, 14 Sep 2012 10:00:56 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 1452321F851A for ; Fri, 14 Sep 2012 10:00:55 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id z0Rz1j0071YDfWL5950zBh; Fri, 14 Sep 2012 17:00:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id z50U1j0083ZTu2S3g50UaL; Fri, 14 Sep 2012 17:00:28 +0000 Message-ID: <505362C6.2040300@alum.mit.edu> Date: Fri, 14 Sep 2012 13:00:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> In-Reply-To: <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:00:57 -0000 On 9/14/12 1:25 PM, Roni Even wrote: > Paul, > I can think of an example for SDP only with no CLUE but it depends how > simulcast is implemented. A switch from high res to low res of the same > capture (example room view) without a change in the CLUE > Roni OK. I can sort of see that. Maybe. Does this fall into the category of something where there are alternatives within a single config? But I would have thought that the high and low res versions of the same capture would be represented in clue signaling by advertising two possible encodings for the same capture, and then configuring the capture with one or the other. If so, then there would be a config message associated with the change. Thanks, Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 5:44 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > I agree with this. One comment below. > > On 9/14/12 12:15 PM, Roni Even wrote: >> Hi Paul, >> Other examples >> >> 1. want to add a transport connection when adding a new RTP stream >> (example opening a presentation stream during the call or changing the >> presentation >> stream) will require a re-invite. In general every change in the >> transport connection whether adding a new one when not SSRC >> multiplexing or changing the connection (transfer the call or some of >> the media streams without the CLUE channel) 2. Changing the codec used >> (H.26 to H.264 or audio codec) may require a re-invite. >> 3. When an MCU wants to change the common mode of a call when a party >> is added or dropped. >> >> There are more use cases. >> >> I see there are two types of requirements for re-invite. >> >> The first is during call setup in a point to point and multipoint call >> where the first invite is used to negotiate CLUE support and address >> interoperability with non-CLUE systems. After going the negotiation of >> the CLUE state there will be a need for a re-invite to correlate the >> CLUE and SDP states. >> >> The second during the call is when there is a change in the CLUE state >> that MAY require a correlation with the SDP state or even just an SDP >> state change like changing codec or addressing network or application >> issues that do not change the CLUE state. > > I think we don't yet know if there will be anything that makes sense to > change in SDP without some corresponding change in advertisement or config. > If there is, it must be something for which there are alternative ways to > accomplish the configuration. I'm not sure what that might be, but in > principle I see it could happen. > > Thanks, > Paul > >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Espen Berger (espeberg) >> Sent: 14 September, 2012 4:36 PM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> My main point is that the initial INVITE can be sufficient for a call >> with CLUE negotiated media stream. >> >> One of the exceptions we have discussed is the requirement to upgrade >> bandwidth to allow for three camera/screen scenarios, which is >> typically not something you allocate in the network before you really > knows it's needed. >> In this case the re-INVITE is optional and there a clear user story to >> explain why and when we want to do it. >> >> I think necessary, and useful, to write down user stories to explain >> why a SIP re-INVITE is needed. With user stories it's much easier to >> discuss how to solve actual problems with protocols. >> >> Cheers >> >> -Espen >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 11. september 2012 17:51 >> To: Espen Berger (espeberg) >> Cc: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>> My comments >>> >>> * It's natural that the MCU send an empty advertisement when the >>> classroom >> dials in as the first participant. If not, the classroom does not now >> if the conference is empty. The configuration message can be delayed, >> since you are mainly indicating that you do not want to receive media. >> >> That is a good idea. I'll do it. >> >>> * I think the MCU can delay its initial configure message until the >> classroom and surgery has done the configure message. With only two >> participant in the conference, you do not have to configure each >> endpoint to send media until the MCU knows someone request the media >> and also know the media restrictions. >>> >>> * What is the purpose for the second INVITE from the classroom, where >>> the >> text says 'to cover both configurations'. The initial SIP INVITE can >> be sufficient for payload numbers, bw, codec-parameters. Based on the >> draft-romanow-clue-call-flow document the main example for a re-invite >> is to increase or decrease bandwidth allocation. >> >> I assumed a consistent approach to first invites - that they are >> vanilla and minimal, and so aren't sufficient to support the actual CLUE > call. >> >> I have assumed that the invite with o/a to get things *right* is done >> *after* the Configure messages have been exchanged, when the needs are >> fully known. There is a chance for glare here - with both sides trying >> to initiate the o/a. I assumed for this flow that this doesn't happen >> - either one side waits for the other to go first, or else the timing >> results in one side sending first and that this then causes the other >> side to omit its own attempt because it is no longer needed. >> >> Because the two sides make independent choices of what to receive, and >> these may not be symmetric, it is necessary to consider both >> configurations to decide what to offer. Or else, one side sends an >> offer sufficient for itself, and then the other side may have to both >> answer and then make a new offer to add things it needs. >> >> This needs more discussion. I didn't sense any consensus or even >> common understanding of the issues and tradeoffs. >> >>> * The expert endpoints does not send a Configure message to the MCU. >>> Is >> this intentional or not? >> >> I'm having trouble remembering what I was thinking. :-) I think the >> note "Defer config till get request" is a mistake, and the expert >> should go ahead and send a Configure. I'll fix it. >> >> Thanks, >> Paul >> >>> Cheers >>> >>> -Espen >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 11. september 2012 00:52 >>> To: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> I just submitted in initial version of a new callflow draft. >>> A more useful link for it is: >>> >>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >>> l >>> ow/ >>> >>> This is complementary to draft-romanow-clue-call-flow. >>> >>> I've focused on a particular use case rather than a generic one. I've >> chosen the telemedical use case, and a special case of that use case. >>> Some of the interesting things about this case are that it includes >>> an MCU, and more than two endpoints. And those endpoints are not all >>> identical. (The latter point won't have obvious impact until more >>> detail is filled in.) >>> >>> And for now I've considered only the ladder diagram of sip and clue >> messages. That leaves a lot out. I expect it to be expanded to include >> the content of those messages. But before getting to that there are >> already a bunch of issues to sort out, that will impact what goes in those > messages. >>> >>> I don't have any illusions that this version is "correct". It is just >>> a >> starting point to discuss the issues. So please send comments. Maybe >> we will have time to talk about it at tomorrow's design team meeting, >> and/or at the interim next week. >>> >>> Thanks, >>> Paul >>> >>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>> >>>> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt >>>> has been successfully submitted by Paul H. Kyzivat and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>> Revision: 00 >>>> Title: CLUE Telemedical Use Case Callflow >>>> Creation date: 2012-09-11 >>>> WG ID: Individual Submission >>>> Number of pages: 8 >>>> URL: >> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-cal >> lflow- >> 00.txt >>>> Status: >> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflo >> w >>>> Htmlized: >> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >>>> >>>> >>>> Abstract: >>>> This is the beginning of an example call flow for an >>>> instantiation >> of >>>> the use case described in the telemedical use case >>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>>> later. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > > From ron.even.tlv@gmail.com Fri Sep 14 11:38:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD9D21F8468 for ; Fri, 14 Sep 2012 11:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me17WdjXVMRX for ; Fri, 14 Sep 2012 11:38:58 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF51E21F847B for ; Fri, 14 Sep 2012 11:38:57 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2351950wgb.13 for ; Fri, 14 Sep 2012 11:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Qs+1st94jf3N5agEqd3RX/+5kD2jlVbor7VNpgr2+aM=; b=C0iVEdvVnblOoUy9CcfrF+PPwNSnW5QpEnEu7XvFNozav8nGEY0oH/FBZiET0yBXwL HSnAYErcRTBjeUnOcHcDB/TqytPeMmb/IdphpXh0OHfk2sR92scV+eR2KgRzS25GIg+O VgsvTMJ684iu/xnH9Gp8pZUxDK3a3T7MlqQhwlb91IK821ppRe21ib0FCajsA++nYVE2 E/9MimWiWSDjWhlE/ZCmYbUNHIXLUo1gBUlVrulE8lEGE7pLwlxLKE1T7qwwvGD+4XuH ATv2/xK5x6hV1dd3ctuhNriGoYn2Y+I2JHlFz9+kjiRlC6rNiZgbrj5F51mQWV7hTwEb HwCQ== Received: by 10.216.134.101 with SMTP id r79mr1924830wei.60.1347647936740; Fri, 14 Sep 2012 11:38:56 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id q4sm87327wix.9.2012.09.14.11.38.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 11:38:40 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> In-Reply-To: <505362C6.2040300@alum.mit.edu> Date: Fri, 14 Sep 2012 21:36:48 +0200 Message-ID: <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2V0ZruT0VU3TL5YJEy+G6AcvvAJeBKjPAckOTB0CK35f6QHipvOUAmjyTpoBzzyP5QJFPnmLAlH/9Y+WW4hWcA== Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 18:38:59 -0000 Paul, Try to analyze it assuming that each resolution is using a different transport address, so you must use SDP to switch in which case why not define simulcast in SDP and not in CLUE. Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 14 September, 2012 7:01 PM To: Roni Even Cc: 'Espen Berger (espeberg)'; 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt On 9/14/12 1:25 PM, Roni Even wrote: > Paul, > I can think of an example for SDP only with no CLUE but it depends how > simulcast is implemented. A switch from high res to low res of the > same capture (example room view) without a change in the CLUE Roni OK. I can sort of see that. Maybe. Does this fall into the category of something where there are alternatives within a single config? But I would have thought that the high and low res versions of the same capture would be represented in clue signaling by advertising two possible encodings for the same capture, and then configuring the capture with one or the other. If so, then there would be a config message associated with the change. Thanks, Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 5:44 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > I agree with this. One comment below. > > On 9/14/12 12:15 PM, Roni Even wrote: >> Hi Paul, >> Other examples >> >> 1. want to add a transport connection when adding a new RTP stream >> (example opening a presentation stream during the call or changing >> the presentation >> stream) will require a re-invite. In general every change in the >> transport connection whether adding a new one when not SSRC >> multiplexing or changing the connection (transfer the call or some of >> the media streams without the CLUE channel) 2. Changing the codec >> used >> (H.26 to H.264 or audio codec) may require a re-invite. >> 3. When an MCU wants to change the common mode of a call when a party >> is added or dropped. >> >> There are more use cases. >> >> I see there are two types of requirements for re-invite. >> >> The first is during call setup in a point to point and multipoint >> call where the first invite is used to negotiate CLUE support and >> address interoperability with non-CLUE systems. After going the >> negotiation of the CLUE state there will be a need for a re-invite to >> correlate the CLUE and SDP states. >> >> The second during the call is when there is a change in the CLUE >> state that MAY require a correlation with the SDP state or even just >> an SDP state change like changing codec or addressing network or >> application issues that do not change the CLUE state. > > I think we don't yet know if there will be anything that makes sense > to change in SDP without some corresponding change in advertisement or config. > If there is, it must be something for which there are alternative ways > to accomplish the configuration. I'm not sure what that might be, but > in principle I see it could happen. > > Thanks, > Paul > >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Espen Berger (espeberg) >> Sent: 14 September, 2012 4:36 PM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> My main point is that the initial INVITE can be sufficient for a call >> with CLUE negotiated media stream. >> >> One of the exceptions we have discussed is the requirement to upgrade >> bandwidth to allow for three camera/screen scenarios, which is >> typically not something you allocate in the network before you really > knows it's needed. >> In this case the re-INVITE is optional and there a clear user story >> to explain why and when we want to do it. >> >> I think necessary, and useful, to write down user stories to explain >> why a SIP re-INVITE is needed. With user stories it's much easier to >> discuss how to solve actual problems with protocols. >> >> Cheers >> >> -Espen >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 11. september 2012 17:51 >> To: Espen Berger (espeberg) >> Cc: CLUE >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>> My comments >>> >>> * It's natural that the MCU send an empty advertisement when the >>> classroom >> dials in as the first participant. If not, the classroom does not now >> if the conference is empty. The configuration message can be delayed, >> since you are mainly indicating that you do not want to receive media. >> >> That is a good idea. I'll do it. >> >>> * I think the MCU can delay its initial configure message until the >> classroom and surgery has done the configure message. With only two >> participant in the conference, you do not have to configure each >> endpoint to send media until the MCU knows someone request the media >> and also know the media restrictions. >>> >>> * What is the purpose for the second INVITE from the classroom, >>> where the >> text says 'to cover both configurations'. The initial SIP INVITE can >> be sufficient for payload numbers, bw, codec-parameters. Based on the >> draft-romanow-clue-call-flow document the main example for a >> re-invite is to increase or decrease bandwidth allocation. >> >> I assumed a consistent approach to first invites - that they are >> vanilla and minimal, and so aren't sufficient to support the actual >> CLUE > call. >> >> I have assumed that the invite with o/a to get things *right* is done >> *after* the Configure messages have been exchanged, when the needs >> are fully known. There is a chance for glare here - with both sides >> trying to initiate the o/a. I assumed for this flow that this doesn't >> happen >> - either one side waits for the other to go first, or else the timing >> results in one side sending first and that this then causes the other >> side to omit its own attempt because it is no longer needed. >> >> Because the two sides make independent choices of what to receive, >> and these may not be symmetric, it is necessary to consider both >> configurations to decide what to offer. Or else, one side sends an >> offer sufficient for itself, and then the other side may have to both >> answer and then make a new offer to add things it needs. >> >> This needs more discussion. I didn't sense any consensus or even >> common understanding of the issues and tradeoffs. >> >>> * The expert endpoints does not send a Configure message to the MCU. >>> Is >> this intentional or not? >> >> I'm having trouble remembering what I was thinking. :-) I think the >> note "Defer config till get request" is a mistake, and the expert >> should go ahead and send a Configure. I'll fix it. >> >> Thanks, >> Paul >> >>> Cheers >>> >>> -Espen >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 11. september 2012 00:52 >>> To: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> I just submitted in initial version of a new callflow draft. >>> A more useful link for it is: >>> >>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-call >>> f >>> l >>> ow/ >>> >>> This is complementary to draft-romanow-clue-call-flow. >>> >>> I've focused on a particular use case rather than a generic one. >>> I've >> chosen the telemedical use case, and a special case of that use case. >>> Some of the interesting things about this case are that it includes >>> an MCU, and more than two endpoints. And those endpoints are not all >>> identical. (The latter point won't have obvious impact until more >>> detail is filled in.) >>> >>> And for now I've considered only the ladder diagram of sip and clue >> messages. That leaves a lot out. I expect it to be expanded to >> include the content of those messages. But before getting to that >> there are already a bunch of issues to sort out, that will impact >> what goes in those > messages. >>> >>> I don't have any illusions that this version is "correct". It is >>> just a >> starting point to discuss the issues. So please send comments. Maybe >> we will have time to talk about it at tomorrow's design team meeting, >> and/or at the interim next week. >>> >>> Thanks, >>> Paul >>> >>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>> >>>> A new version of I-D, >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>> the IETF repository. >>>> >>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>> Revision: 00 >>>> Title: CLUE Telemedical Use Case Callflow >>>> Creation date: 2012-09-11 >>>> WG ID: Individual Submission >>>> Number of pages: 8 >>>> URL: >> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-ca >> l >> lflow- >> 00.txt >>>> Status: >> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl >> o >> w >>>> Htmlized: >> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >>>> >>>> >>>> Abstract: >>>> This is the beginning of an example call flow for an >>>> instantiation >> of >>>> the use case described in the telemedical use case >>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>>> later. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > > From pkyzivat@alum.mit.edu Fri Sep 14 12:13:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E8021F8476 for ; Fri, 14 Sep 2012 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LBt5M9G+DSn for ; Fri, 14 Sep 2012 12:13:11 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF9E21F8471 for ; Fri, 14 Sep 2012 12:13:09 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id yzUj1j0071wpRvQ5D7DDnk; Fri, 14 Sep 2012 19:13:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id z7SG1j00v3ZTu2S3e7SGYp; Fri, 14 Sep 2012 19:26:17 +0000 Message-ID: <505381C4.8080207@alum.mit.edu> Date: Fri, 14 Sep 2012 15:13:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> In-Reply-To: <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 19:13:14 -0000 On 9/14/12 3:36 PM, Roni Even wrote: > Paul, > Try to analyze it assuming that each resolution is using a different > transport address, so you must use SDP to switch in which case why not > define simulcast in SDP and not in CLUE. This is really into the "what goes where", which is a good discussion to have! I guess what you are describing means that there are two alternate encodings available for this capture. They could map to two different m-lines in sdp. But what would cause them both to be listed in the SDP? This can work if the SDP is determined by the advertisement, and covers all possible configurations that might be configured from that advertisement. So then, if both are in an SDP offer that corresponds to that advertisement, then the SDP answer can choose which of those to accept. That is in effect doing a configuration, or part of it. For that to work, the advertisement that explains what those mean would have to be sent before the SDP offer, so that it would be available to make the decision about what to accept in the answer. And then if later there is a desire to switch to the other resolution, then I guess an SDP offer would be sent in the other direction, changing which of the two m-lines has a non-zero port. It sounds like this can be made to work, though the devil is in the details. It will require a lot of analysis of when advertisements must be sent relative to offers. Based on above, an advertisement MAY/MUST? be followed by an offer. And apparently the offer must be sufficient for any configuration of that advertisement. I'm worried that this may require the offerer to consume more resources than are required for most configurations. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 7:01 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 1:25 PM, Roni Even wrote: >> Paul, >> I can think of an example for SDP only with no CLUE but it depends how >> simulcast is implemented. A switch from high res to low res of the >> same capture (example room view) without a change in the CLUE Roni > > OK. I can sort of see that. Maybe. > > Does this fall into the category of something where there are alternatives > within a single config? > > But I would have thought that the high and low res versions of the same > capture would be represented in clue signaling by advertising two possible > encodings for the same capture, and then configuring the capture with one or > the other. If so, then there would be a config message associated with the > change. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 5:44 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I agree with this. One comment below. >> >> On 9/14/12 12:15 PM, Roni Even wrote: >>> Hi Paul, >>> Other examples >>> >>> 1. want to add a transport connection when adding a new RTP stream >>> (example opening a presentation stream during the call or changing >>> the presentation >>> stream) will require a re-invite. In general every change in the >>> transport connection whether adding a new one when not SSRC >>> multiplexing or changing the connection (transfer the call or some of >>> the media streams without the CLUE channel) 2. Changing the codec >>> used >>> (H.26 to H.264 or audio codec) may require a re-invite. >>> 3. When an MCU wants to change the common mode of a call when a party >>> is added or dropped. >>> >>> There are more use cases. >>> >>> I see there are two types of requirements for re-invite. >>> >>> The first is during call setup in a point to point and multipoint >>> call where the first invite is used to negotiate CLUE support and >>> address interoperability with non-CLUE systems. After going the >>> negotiation of the CLUE state there will be a need for a re-invite to >>> correlate the CLUE and SDP states. >>> >>> The second during the call is when there is a change in the CLUE >>> state that MAY require a correlation with the SDP state or even just >>> an SDP state change like changing codec or addressing network or >>> application issues that do not change the CLUE state. >> >> I think we don't yet know if there will be anything that makes sense >> to change in SDP without some corresponding change in advertisement or > config. >> If there is, it must be something for which there are alternative ways >> to accomplish the configuration. I'm not sure what that might be, but >> in principle I see it could happen. >> >> Thanks, >> Paul >> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Espen Berger (espeberg) >>> Sent: 14 September, 2012 4:36 PM >>> To: Paul Kyzivat >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> My main point is that the initial INVITE can be sufficient for a call >>> with CLUE negotiated media stream. >>> >>> One of the exceptions we have discussed is the requirement to upgrade >>> bandwidth to allow for three camera/screen scenarios, which is >>> typically not something you allocate in the network before you really >> knows it's needed. >>> In this case the re-INVITE is optional and there a clear user story >>> to explain why and when we want to do it. >>> >>> I think necessary, and useful, to write down user stories to explain >>> why a SIP re-INVITE is needed. With user stories it's much easier to >>> discuss how to solve actual problems with protocols. >>> >>> Cheers >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 11. september 2012 17:51 >>> To: Espen Berger (espeberg) >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>> My comments >>>> >>>> * It's natural that the MCU send an empty advertisement when the >>>> classroom >>> dials in as the first participant. If not, the classroom does not now >>> if the conference is empty. The configuration message can be delayed, >>> since you are mainly indicating that you do not want to receive media. >>> >>> That is a good idea. I'll do it. >>> >>>> * I think the MCU can delay its initial configure message until the >>> classroom and surgery has done the configure message. With only two >>> participant in the conference, you do not have to configure each >>> endpoint to send media until the MCU knows someone request the media >>> and also know the media restrictions. >>>> >>>> * What is the purpose for the second INVITE from the classroom, >>>> where the >>> text says 'to cover both configurations'. The initial SIP INVITE can >>> be sufficient for payload numbers, bw, codec-parameters. Based on the >>> draft-romanow-clue-call-flow document the main example for a >>> re-invite is to increase or decrease bandwidth allocation. >>> >>> I assumed a consistent approach to first invites - that they are >>> vanilla and minimal, and so aren't sufficient to support the actual >>> CLUE >> call. >>> >>> I have assumed that the invite with o/a to get things *right* is done >>> *after* the Configure messages have been exchanged, when the needs >>> are fully known. There is a chance for glare here - with both sides >>> trying to initiate the o/a. I assumed for this flow that this doesn't >>> happen >>> - either one side waits for the other to go first, or else the timing >>> results in one side sending first and that this then causes the other >>> side to omit its own attempt because it is no longer needed. >>> >>> Because the two sides make independent choices of what to receive, >>> and these may not be symmetric, it is necessary to consider both >>> configurations to decide what to offer. Or else, one side sends an >>> offer sufficient for itself, and then the other side may have to both >>> answer and then make a new offer to add things it needs. >>> >>> This needs more discussion. I didn't sense any consensus or even >>> common understanding of the issues and tradeoffs. >>> >>>> * The expert endpoints does not send a Configure message to the MCU. >>>> Is >>> this intentional or not? >>> >>> I'm having trouble remembering what I was thinking. :-) I think the >>> note "Defer config till get request" is a mistake, and the expert >>> should go ahead and send a Configure. I'll fix it. >>> >>> Thanks, >>> Paul >>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: 11. september 2012 00:52 >>>> To: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> I just submitted in initial version of a new callflow draft. >>>> A more useful link for it is: >>>> >>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-call >>>> f >>>> l >>>> ow/ >>>> >>>> This is complementary to draft-romanow-clue-call-flow. >>>> >>>> I've focused on a particular use case rather than a generic one. >>>> I've >>> chosen the telemedical use case, and a special case of that use case. >>>> Some of the interesting things about this case are that it includes >>>> an MCU, and more than two endpoints. And those endpoints are not all >>>> identical. (The latter point won't have obvious impact until more >>>> detail is filled in.) >>>> >>>> And for now I've considered only the ladder diagram of sip and clue >>> messages. That leaves a lot out. I expect it to be expanded to >>> include the content of those messages. But before getting to that >>> there are already a bunch of issues to sort out, that will impact >>> what goes in those >> messages. >>>> >>>> I don't have any illusions that this version is "correct". It is >>>> just a >>> starting point to discuss the issues. So please send comments. Maybe >>> we will have time to talk about it at tomorrow's design team meeting, >>> and/or at the interim next week. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>> >>>>> A new version of I-D, >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>> the IETF repository. >>>>> >>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>> Revision: 00 >>>>> Title: CLUE Telemedical Use Case Callflow >>>>> Creation date: 2012-09-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 8 >>>>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-ca >>> l >>> lflow- >>> 00.txt >>>>> Status: >>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl >>> o >>> w >>>>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00 >>>>> >>>>> >>>>> Abstract: >>>>> This is the beginning of an example call flow for an >>>>> instantiation >>> of >>>>> the use case described in the telemedical use case >>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>>>> later. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> > > From ron.even.tlv@gmail.com Fri Sep 14 14:23:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8D21F8532 for ; Fri, 14 Sep 2012 14:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ducprj0u0Jyz for ; Fri, 14 Sep 2012 14:23:56 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8581721F8530 for ; Fri, 14 Sep 2012 14:23:55 -0700 (PDT) Received: by weyu54 with SMTP id u54so2870168wey.31 for ; Fri, 14 Sep 2012 14:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=66Jp+QYcBXDnufQlaoCxUC0Jwmjn3DjFsICCCn+k93E=; b=INMkbJjeSw1ftOOJi4AmmPAswIMU6FePp3gY7hOnsTtb9l/q1ZSsbeu9ZUq/M4jmLt HzKEwqtdjD6uGDrVITrcdCAFGSqYwGrPUZB4imorj/x0rg3h/3mNoJOws+rhBdae4bBR dVL0836X2bTNzhlMuSNXGSRVKEagvbr+R5Rvg/lh21mEKkzNlGxZ+bGPwmWqEGbnVUGB vLKkll5+oP9vBeRMSCqV2CTjbzUmh1ld3o7pLlUeOw3XU+x7s+66n0rbTG+2y2+cdj/r ps1jOGPtUUg4QwGbyvS16WOwEYie/jo+O2+hddHhMLC7OIlzWJp+zWok0FtPcfSjBRTV tckw== Received: by 10.180.98.200 with SMTP id ek8mr715031wib.0.1347657834581; Fri, 14 Sep 2012 14:23:54 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id t8sm922168wiy.3.2012.09.14.14.23.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 14:23:53 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> In-Reply-To: <505381C4.8080207@alum.mit.edu> Date: Sat, 15 Sep 2012 00:22:05 +0200 Message-ID: <010d01cd92c7$61e5a6c0$25b0f440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2V0ZruT0VU3TL5YJEy+G6AcvvAJeBKjPAckOTB0CK35f6QHipvOUAmjyTpoBzzyP5QJFPnmLAlH/9Y8BZnwB7AJs338Mlj0a4iA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:23:57 -0000 Hi Paul, http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01 describes how to do simulcast without CLUE. Now if you also describe in CLUE the encoding (which I am not sure is needed for this case) you should have the SDP correlated with CLUE, this will require the offer answer after the CLUE configuration like I proposed in previous email. If the SDP description is there you can switch with re-invite without CLUE (you will need to re-invite to signal the port) Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 14 September, 2012 9:13 PM To: Roni Even Cc: 'Espen Berger (espeberg)'; 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt On 9/14/12 3:36 PM, Roni Even wrote: > Paul, > Try to analyze it assuming that each resolution is using a different > transport address, so you must use SDP to switch in which case why not > define simulcast in SDP and not in CLUE. This is really into the "what goes where", which is a good discussion to have! I guess what you are describing means that there are two alternate encodings available for this capture. They could map to two different m-lines in sdp. But what would cause them both to be listed in the SDP? This can work if the SDP is determined by the advertisement, and covers all possible configurations that might be configured from that advertisement. So then, if both are in an SDP offer that corresponds to that advertisement, then the SDP answer can choose which of those to accept. That is in effect doing a configuration, or part of it. For that to work, the advertisement that explains what those mean would have to be sent before the SDP offer, so that it would be available to make the decision about what to accept in the answer. And then if later there is a desire to switch to the other resolution, then I guess an SDP offer would be sent in the other direction, changing which of the two m-lines has a non-zero port. It sounds like this can be made to work, though the devil is in the details. It will require a lot of analysis of when advertisements must be sent relative to offers. Based on above, an advertisement MAY/MUST? be followed by an offer. And apparently the offer must be sufficient for any configuration of that advertisement. I'm worried that this may require the offerer to consume more resources than are required for most configurations. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 7:01 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 1:25 PM, Roni Even wrote: >> Paul, >> I can think of an example for SDP only with no CLUE but it depends >> how simulcast is implemented. A switch from high res to low res of >> the same capture (example room view) without a change in the CLUE >> Roni > > OK. I can sort of see that. Maybe. > > Does this fall into the category of something where there are > alternatives within a single config? > > But I would have thought that the high and low res versions of the > same capture would be represented in clue signaling by advertising two > possible encodings for the same capture, and then configuring the > capture with one or the other. If so, then there would be a config > message associated with the change. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 5:44 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I agree with this. One comment below. >> >> On 9/14/12 12:15 PM, Roni Even wrote: >>> Hi Paul, >>> Other examples >>> >>> 1. want to add a transport connection when adding a new RTP stream >>> (example opening a presentation stream during the call or changing >>> the presentation >>> stream) will require a re-invite. In general every change in the >>> transport connection whether adding a new one when not SSRC >>> multiplexing or changing the connection (transfer the call or some >>> of the media streams without the CLUE channel) 2. Changing the codec >>> used >>> (H.26 to H.264 or audio codec) may require a re-invite. >>> 3. When an MCU wants to change the common mode of a call when a >>> party is added or dropped. >>> >>> There are more use cases. >>> >>> I see there are two types of requirements for re-invite. >>> >>> The first is during call setup in a point to point and multipoint >>> call where the first invite is used to negotiate CLUE support and >>> address interoperability with non-CLUE systems. After going the >>> negotiation of the CLUE state there will be a need for a re-invite >>> to correlate the CLUE and SDP states. >>> >>> The second during the call is when there is a change in the CLUE >>> state that MAY require a correlation with the SDP state or even just >>> an SDP state change like changing codec or addressing network or >>> application issues that do not change the CLUE state. >> >> I think we don't yet know if there will be anything that makes sense >> to change in SDP without some corresponding change in advertisement >> or > config. >> If there is, it must be something for which there are alternative >> ways to accomplish the configuration. I'm not sure what that might >> be, but in principle I see it could happen. >> >> Thanks, >> Paul >> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Espen Berger (espeberg) >>> Sent: 14 September, 2012 4:36 PM >>> To: Paul Kyzivat >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> My main point is that the initial INVITE can be sufficient for a >>> call with CLUE negotiated media stream. >>> >>> One of the exceptions we have discussed is the requirement to >>> upgrade bandwidth to allow for three camera/screen scenarios, which >>> is typically not something you allocate in the network before you >>> really >> knows it's needed. >>> In this case the re-INVITE is optional and there a clear user story >>> to explain why and when we want to do it. >>> >>> I think necessary, and useful, to write down user stories to explain >>> why a SIP re-INVITE is needed. With user stories it's much easier >>> to discuss how to solve actual problems with protocols. >>> >>> Cheers >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 11. september 2012 17:51 >>> To: Espen Berger (espeberg) >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>> My comments >>>> >>>> * It's natural that the MCU send an empty advertisement when the >>>> classroom >>> dials in as the first participant. If not, the classroom does not >>> now if the conference is empty. The configuration message can be >>> delayed, since you are mainly indicating that you do not want to receive media. >>> >>> That is a good idea. I'll do it. >>> >>>> * I think the MCU can delay its initial configure message until the >>> classroom and surgery has done the configure message. With only two >>> participant in the conference, you do not have to configure each >>> endpoint to send media until the MCU knows someone request the media >>> and also know the media restrictions. >>>> >>>> * What is the purpose for the second INVITE from the classroom, >>>> where the >>> text says 'to cover both configurations'. The initial SIP INVITE can >>> be sufficient for payload numbers, bw, codec-parameters. Based on >>> the draft-romanow-clue-call-flow document the main example for a >>> re-invite is to increase or decrease bandwidth allocation. >>> >>> I assumed a consistent approach to first invites - that they are >>> vanilla and minimal, and so aren't sufficient to support the actual >>> CLUE >> call. >>> >>> I have assumed that the invite with o/a to get things *right* is >>> done >>> *after* the Configure messages have been exchanged, when the needs >>> are fully known. There is a chance for glare here - with both sides >>> trying to initiate the o/a. I assumed for this flow that this >>> doesn't happen >>> - either one side waits for the other to go first, or else the >>> timing results in one side sending first and that this then causes >>> the other side to omit its own attempt because it is no longer needed. >>> >>> Because the two sides make independent choices of what to receive, >>> and these may not be symmetric, it is necessary to consider both >>> configurations to decide what to offer. Or else, one side sends an >>> offer sufficient for itself, and then the other side may have to >>> both answer and then make a new offer to add things it needs. >>> >>> This needs more discussion. I didn't sense any consensus or even >>> common understanding of the issues and tradeoffs. >>> >>>> * The expert endpoints does not send a Configure message to the MCU. >>>> Is >>> this intentional or not? >>> >>> I'm having trouble remembering what I was thinking. :-) I think the >>> note "Defer config till get request" is a mistake, and the expert >>> should go ahead and send a Configure. I'll fix it. >>> >>> Thanks, >>> Paul >>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: 11. september 2012 00:52 >>>> To: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> I just submitted in initial version of a new callflow draft. >>>> A more useful link for it is: >>>> >>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal >>>> l >>>> f >>>> l >>>> ow/ >>>> >>>> This is complementary to draft-romanow-clue-call-flow. >>>> >>>> I've focused on a particular use case rather than a generic one. >>>> I've >>> chosen the telemedical use case, and a special case of that use case. >>>> Some of the interesting things about this case are that it includes >>>> an MCU, and more than two endpoints. And those endpoints are not >>>> all identical. (The latter point won't have obvious impact until >>>> more detail is filled in.) >>>> >>>> And for now I've considered only the ladder diagram of sip and clue >>> messages. That leaves a lot out. I expect it to be expanded to >>> include the content of those messages. But before getting to that >>> there are already a bunch of issues to sort out, that will impact >>> what goes in those >> messages. >>>> >>>> I don't have any illusions that this version is "correct". It is >>>> just a >>> starting point to discuss the issues. So please send comments. Maybe >>> we will have time to talk about it at tomorrow's design team >>> meeting, and/or at the interim next week. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>> >>>>> A new version of I-D, >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>> the IETF repository. >>>>> >>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>> Revision: 00 >>>>> Title: CLUE Telemedical Use Case Callflow >>>>> Creation date: 2012-09-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 8 >>>>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c >>> a >>> l >>> lflow- >>> 00.txt >>>>> Status: >>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >>> l >>> o >>> w >>>>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-0 >>> 0 >>>>> >>>>> >>>>> Abstract: >>>>> This is the beginning of an example call flow for an >>>>> instantiation >>> of >>>>> the use case described in the telemedical use case >>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>>>> later. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> > > From ron.even.tlv@gmail.com Fri Sep 14 14:31:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE4721F84A6 for ; Fri, 14 Sep 2012 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaED1vcUg3xi for ; Fri, 14 Sep 2012 14:31:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3F3F21F846F for ; Fri, 14 Sep 2012 14:31:44 -0700 (PDT) Received: by weyu54 with SMTP id u54so2873370wey.31 for ; Fri, 14 Sep 2012 14:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=BhYb16ekVadgalrbI46PKnifzNoIBg9JbVVHBrXNOnM=; b=YgsdLo3Pm1tMNHcsDUznUW7y8hawuu+VpKVN0dHP6pqggBlbpu3HZndOSZgoFbJQhG H6IiuUrTZw+L8y5PTnYhPhTb4tCfe8iuVpzKQQy+5A1uPmeT/xS7BIFRhy0G9wMQ13KE m5cQVo9hUAJoz+CmJr/g/FlsLEtyJ8oLSuU7nLD6B+jZpkvhS1eJhrXFBOph/o+mci+W RgDj3jra/C4kUWN76LHXhKajZ5+bURaXbJawvpy+x9WO+DyKL/lebSwiSz14v0Xp3YN5 n319xiUlDvd/K7hVPf4rtALaqIm/VknymmlXVdWceFIxCzkboJMdDLjDKGlLYW3pp3pI Y1ew== Received: by 10.216.238.27 with SMTP id z27mr2094708weq.81.1347658303702; Fri, 14 Sep 2012 14:31:43 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id t8sm961113wiy.3.2012.09.14.14.31.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 14:31:42 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> In-Reply-To: <505381C4.8080207@alum.mit.edu> Date: Sat, 15 Sep 2012 00:29:55 +0200 Message-ID: <011101cd92c8$79949eb0$6cbddc10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2V0ZruT0VU3TL5YJEy+G6AcvvAJeBKjPAckOTB0CK35f6QHipvOUAmjyTpoBzzyP5QJFPnmLAlH/9Y8BZnwB7AJs338Mlj0cLZA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:31:46 -0000 Paul, One concern I have is that some of the usages like simulcast are not a CLUE issue but are relevant also for non CLUE solutions. So to resolve this use case we can mandate using CLUE (as a multi stream signaling) or resolve it using SDP. The worst case is if we have two ways to signal without defining the interoperability. I tried to provide in section 4.1 http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 a review of some of the signaling proposal from AVTcore, AVText and MMSUIC that can address some of the scenarios discussed in CLUE in order to have a full picture before deciding to put something in CLUE protocol. I hope that people will look at these documents . Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 14 September, 2012 9:13 PM To: Roni Even Cc: 'Espen Berger (espeberg)'; 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt On 9/14/12 3:36 PM, Roni Even wrote: > Paul, > Try to analyze it assuming that each resolution is using a different > transport address, so you must use SDP to switch in which case why not > define simulcast in SDP and not in CLUE. This is really into the "what goes where", which is a good discussion to have! I guess what you are describing means that there are two alternate encodings available for this capture. They could map to two different m-lines in sdp. But what would cause them both to be listed in the SDP? This can work if the SDP is determined by the advertisement, and covers all possible configurations that might be configured from that advertisement. So then, if both are in an SDP offer that corresponds to that advertisement, then the SDP answer can choose which of those to accept. That is in effect doing a configuration, or part of it. For that to work, the advertisement that explains what those mean would have to be sent before the SDP offer, so that it would be available to make the decision about what to accept in the answer. And then if later there is a desire to switch to the other resolution, then I guess an SDP offer would be sent in the other direction, changing which of the two m-lines has a non-zero port. It sounds like this can be made to work, though the devil is in the details. It will require a lot of analysis of when advertisements must be sent relative to offers. Based on above, an advertisement MAY/MUST? be followed by an offer. And apparently the offer must be sufficient for any configuration of that advertisement. I'm worried that this may require the offerer to consume more resources than are required for most configurations. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 7:01 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 1:25 PM, Roni Even wrote: >> Paul, >> I can think of an example for SDP only with no CLUE but it depends >> how simulcast is implemented. A switch from high res to low res of >> the same capture (example room view) without a change in the CLUE >> Roni > > OK. I can sort of see that. Maybe. > > Does this fall into the category of something where there are > alternatives within a single config? > > But I would have thought that the high and low res versions of the > same capture would be represented in clue signaling by advertising two > possible encodings for the same capture, and then configuring the > capture with one or the other. If so, then there would be a config > message associated with the change. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 5:44 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I agree with this. One comment below. >> >> On 9/14/12 12:15 PM, Roni Even wrote: >>> Hi Paul, >>> Other examples >>> >>> 1. want to add a transport connection when adding a new RTP stream >>> (example opening a presentation stream during the call or changing >>> the presentation >>> stream) will require a re-invite. In general every change in the >>> transport connection whether adding a new one when not SSRC >>> multiplexing or changing the connection (transfer the call or some >>> of the media streams without the CLUE channel) 2. Changing the codec >>> used >>> (H.26 to H.264 or audio codec) may require a re-invite. >>> 3. When an MCU wants to change the common mode of a call when a >>> party is added or dropped. >>> >>> There are more use cases. >>> >>> I see there are two types of requirements for re-invite. >>> >>> The first is during call setup in a point to point and multipoint >>> call where the first invite is used to negotiate CLUE support and >>> address interoperability with non-CLUE systems. After going the >>> negotiation of the CLUE state there will be a need for a re-invite >>> to correlate the CLUE and SDP states. >>> >>> The second during the call is when there is a change in the CLUE >>> state that MAY require a correlation with the SDP state or even just >>> an SDP state change like changing codec or addressing network or >>> application issues that do not change the CLUE state. >> >> I think we don't yet know if there will be anything that makes sense >> to change in SDP without some corresponding change in advertisement >> or > config. >> If there is, it must be something for which there are alternative >> ways to accomplish the configuration. I'm not sure what that might >> be, but in principle I see it could happen. >> >> Thanks, >> Paul >> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Espen Berger (espeberg) >>> Sent: 14 September, 2012 4:36 PM >>> To: Paul Kyzivat >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> My main point is that the initial INVITE can be sufficient for a >>> call with CLUE negotiated media stream. >>> >>> One of the exceptions we have discussed is the requirement to >>> upgrade bandwidth to allow for three camera/screen scenarios, which >>> is typically not something you allocate in the network before you >>> really >> knows it's needed. >>> In this case the re-INVITE is optional and there a clear user story >>> to explain why and when we want to do it. >>> >>> I think necessary, and useful, to write down user stories to explain >>> why a SIP re-INVITE is needed. With user stories it's much easier >>> to discuss how to solve actual problems with protocols. >>> >>> Cheers >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 11. september 2012 17:51 >>> To: Espen Berger (espeberg) >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>> My comments >>>> >>>> * It's natural that the MCU send an empty advertisement when the >>>> classroom >>> dials in as the first participant. If not, the classroom does not >>> now if the conference is empty. The configuration message can be >>> delayed, since you are mainly indicating that you do not want to receive media. >>> >>> That is a good idea. I'll do it. >>> >>>> * I think the MCU can delay its initial configure message until the >>> classroom and surgery has done the configure message. With only two >>> participant in the conference, you do not have to configure each >>> endpoint to send media until the MCU knows someone request the media >>> and also know the media restrictions. >>>> >>>> * What is the purpose for the second INVITE from the classroom, >>>> where the >>> text says 'to cover both configurations'. The initial SIP INVITE can >>> be sufficient for payload numbers, bw, codec-parameters. Based on >>> the draft-romanow-clue-call-flow document the main example for a >>> re-invite is to increase or decrease bandwidth allocation. >>> >>> I assumed a consistent approach to first invites - that they are >>> vanilla and minimal, and so aren't sufficient to support the actual >>> CLUE >> call. >>> >>> I have assumed that the invite with o/a to get things *right* is >>> done >>> *after* the Configure messages have been exchanged, when the needs >>> are fully known. There is a chance for glare here - with both sides >>> trying to initiate the o/a. I assumed for this flow that this >>> doesn't happen >>> - either one side waits for the other to go first, or else the >>> timing results in one side sending first and that this then causes >>> the other side to omit its own attempt because it is no longer needed. >>> >>> Because the two sides make independent choices of what to receive, >>> and these may not be symmetric, it is necessary to consider both >>> configurations to decide what to offer. Or else, one side sends an >>> offer sufficient for itself, and then the other side may have to >>> both answer and then make a new offer to add things it needs. >>> >>> This needs more discussion. I didn't sense any consensus or even >>> common understanding of the issues and tradeoffs. >>> >>>> * The expert endpoints does not send a Configure message to the MCU. >>>> Is >>> this intentional or not? >>> >>> I'm having trouble remembering what I was thinking. :-) I think the >>> note "Defer config till get request" is a mistake, and the expert >>> should go ahead and send a Configure. I'll fix it. >>> >>> Thanks, >>> Paul >>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: 11. september 2012 00:52 >>>> To: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> I just submitted in initial version of a new callflow draft. >>>> A more useful link for it is: >>>> >>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal >>>> l >>>> f >>>> l >>>> ow/ >>>> >>>> This is complementary to draft-romanow-clue-call-flow. >>>> >>>> I've focused on a particular use case rather than a generic one. >>>> I've >>> chosen the telemedical use case, and a special case of that use case. >>>> Some of the interesting things about this case are that it includes >>>> an MCU, and more than two endpoints. And those endpoints are not >>>> all identical. (The latter point won't have obvious impact until >>>> more detail is filled in.) >>>> >>>> And for now I've considered only the ladder diagram of sip and clue >>> messages. That leaves a lot out. I expect it to be expanded to >>> include the content of those messages. But before getting to that >>> there are already a bunch of issues to sort out, that will impact >>> what goes in those >> messages. >>>> >>>> I don't have any illusions that this version is "correct". It is >>>> just a >>> starting point to discuss the issues. So please send comments. Maybe >>> we will have time to talk about it at tomorrow's design team >>> meeting, and/or at the interim next week. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>> >>>>> A new version of I-D, >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>> the IETF repository. >>>>> >>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>> Revision: 00 >>>>> Title: CLUE Telemedical Use Case Callflow >>>>> Creation date: 2012-09-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 8 >>>>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c >>> a >>> l >>> lflow- >>> 00.txt >>>>> Status: >>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >>> l >>> o >>> w >>>>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-0 >>> 0 >>>>> >>>>> >>>>> Abstract: >>>>> This is the beginning of an example call flow for an >>>>> instantiation >>> of >>>>> the use case described in the telemedical use case >>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>>>> later. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> > > From pkyzivat@alum.mit.edu Fri Sep 14 14:45:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB18021F855E for ; Fri, 14 Sep 2012 14:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq-wvsVeknRI for ; Fri, 14 Sep 2012 14:45:25 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 966BD21F8554 for ; Fri, 14 Sep 2012 14:45:25 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id z60S1j0071ei1Bg549lUMa; Fri, 14 Sep 2012 21:45:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id z9lX1j00N3ZTu2S3k9lXJG; Fri, 14 Sep 2012 21:45:31 +0000 Message-ID: <5053A573.1040907@alum.mit.edu> Date: Fri, 14 Sep 2012 17:45:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> <010d01cd92c7$61e5a6c0$25b0f440$@gmail.com> In-Reply-To: <010d01cd92c7$61e5a6c0$25b0f440$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:45:27 -0000 On 9/14/12 6:22 PM, Roni Even wrote: > Hi Paul, > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01 > describes how to do simulcast without CLUE. Now if you also describe in CLUE > the encoding (which I am not sure is needed for this case) you should have > the SDP correlated with CLUE, this will require the offer answer after the > CLUE configuration like I proposed in previous email. > If the SDP description is there you can switch with re-invite without CLUE > (you will need to re-invite to signal the port) Maybe we are talking about different things. ISTM that offering multiple encodings for a capture is not the same as simulcasting the capture in multiple encodings. AFAIK the simulcast means that you are sending out both, and people can decide which they want to receive. The advertisement says you could send one or the other or both. The configure then determines which you actually send, which again could be one or the other or maybe both. ISTM you only have a simulcast situation when you advertise both and the receiver configures both. I guess simulcasting two resolutions is more expensive than sending just one. So I don't see why we would do it unless the receiver wants both. It would be helpful to have some discussion of where simulcast has a role within CLUE. Maybe as part of the RTP document you and Jonathan are working on. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 9:13 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 3:36 PM, Roni Even wrote: >> Paul, >> Try to analyze it assuming that each resolution is using a different >> transport address, so you must use SDP to switch in which case why not >> define simulcast in SDP and not in CLUE. > > This is really into the "what goes where", which is a good discussion to > have! > > I guess what you are describing means that there are two alternate encodings > available for this capture. They could map to two different m-lines in sdp. > But what would cause them both to be listed in the SDP? > > This can work if the SDP is determined by the advertisement, and covers all > possible configurations that might be configured from that advertisement. So > then, if both are in an SDP offer that corresponds to that advertisement, > then the SDP answer can choose which of those to accept. That is in effect > doing a configuration, or part of it. For that to work, the advertisement > that explains what those mean would have to be sent before the SDP offer, so > that it would be available to make the decision about what to accept in the > answer. > > And then if later there is a desire to switch to the other resolution, then > I guess an SDP offer would be sent in the other direction, changing which of > the two m-lines has a non-zero port. > > It sounds like this can be made to work, though the devil is in the details. > It will require a lot of analysis of when advertisements must be sent > relative to offers. Based on above, an advertisement MAY/MUST? > be followed by an offer. And apparently the offer must be sufficient for any > configuration of that advertisement. I'm worried that this may require the > offerer to consume more resources than are required for most configurations. > > Thanks, > Paul > >> Roni >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 7:01 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> On 9/14/12 1:25 PM, Roni Even wrote: >>> Paul, >>> I can think of an example for SDP only with no CLUE but it depends >>> how simulcast is implemented. A switch from high res to low res of >>> the same capture (example room view) without a change in the CLUE >>> Roni >> >> OK. I can sort of see that. Maybe. >> >> Does this fall into the category of something where there are >> alternatives within a single config? >> >> But I would have thought that the high and low res versions of the >> same capture would be represented in clue signaling by advertising two >> possible encodings for the same capture, and then configuring the >> capture with one or the other. If so, then there would be a config >> message associated with the change. >> >> Thanks, >> Paul >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 14 September, 2012 5:44 PM >>> To: Roni Even >>> Cc: 'Espen Berger (espeberg)'; 'CLUE' >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> I agree with this. One comment below. >>> >>> On 9/14/12 12:15 PM, Roni Even wrote: >>>> Hi Paul, >>>> Other examples >>>> >>>> 1. want to add a transport connection when adding a new RTP stream >>>> (example opening a presentation stream during the call or changing >>>> the presentation >>>> stream) will require a re-invite. In general every change in the >>>> transport connection whether adding a new one when not SSRC >>>> multiplexing or changing the connection (transfer the call or some >>>> of the media streams without the CLUE channel) 2. Changing the codec >>>> used >>>> (H.26 to H.264 or audio codec) may require a re-invite. >>>> 3. When an MCU wants to change the common mode of a call when a >>>> party is added or dropped. >>>> >>>> There are more use cases. >>>> >>>> I see there are two types of requirements for re-invite. >>>> >>>> The first is during call setup in a point to point and multipoint >>>> call where the first invite is used to negotiate CLUE support and >>>> address interoperability with non-CLUE systems. After going the >>>> negotiation of the CLUE state there will be a need for a re-invite >>>> to correlate the CLUE and SDP states. >>>> >>>> The second during the call is when there is a change in the CLUE >>>> state that MAY require a correlation with the SDP state or even just >>>> an SDP state change like changing codec or addressing network or >>>> application issues that do not change the CLUE state. >>> >>> I think we don't yet know if there will be anything that makes sense >>> to change in SDP without some corresponding change in advertisement >>> or >> config. >>> If there is, it must be something for which there are alternative >>> ways to accomplish the configuration. I'm not sure what that might >>> be, but in principle I see it could happen. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Espen Berger (espeberg) >>>> Sent: 14 September, 2012 4:36 PM >>>> To: Paul Kyzivat >>>> Cc: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> My main point is that the initial INVITE can be sufficient for a >>>> call with CLUE negotiated media stream. >>>> >>>> One of the exceptions we have discussed is the requirement to >>>> upgrade bandwidth to allow for three camera/screen scenarios, which >>>> is typically not something you allocate in the network before you >>>> really >>> knows it's needed. >>>> In this case the re-INVITE is optional and there a clear user story >>>> to explain why and when we want to do it. >>>> >>>> I think necessary, and useful, to write down user stories to explain >>>> why a SIP re-INVITE is needed. With user stories it's much easier >>>> to discuss how to solve actual problems with protocols. >>>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 11. september 2012 17:51 >>>> To: Espen Berger (espeberg) >>>> Cc: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>>> My comments >>>>> >>>>> * It's natural that the MCU send an empty advertisement when the >>>>> classroom >>>> dials in as the first participant. If not, the classroom does not >>>> now if the conference is empty. The configuration message can be >>>> delayed, since you are mainly indicating that you do not want to receive > media. >>>> >>>> That is a good idea. I'll do it. >>>> >>>>> * I think the MCU can delay its initial configure message until the >>>> classroom and surgery has done the configure message. With only two >>>> participant in the conference, you do not have to configure each >>>> endpoint to send media until the MCU knows someone request the media >>>> and also know the media restrictions. >>>>> >>>>> * What is the purpose for the second INVITE from the classroom, >>>>> where the >>>> text says 'to cover both configurations'. The initial SIP INVITE can >>>> be sufficient for payload numbers, bw, codec-parameters. Based on >>>> the draft-romanow-clue-call-flow document the main example for a >>>> re-invite is to increase or decrease bandwidth allocation. >>>> >>>> I assumed a consistent approach to first invites - that they are >>>> vanilla and minimal, and so aren't sufficient to support the actual >>>> CLUE >>> call. >>>> >>>> I have assumed that the invite with o/a to get things *right* is >>>> done >>>> *after* the Configure messages have been exchanged, when the needs >>>> are fully known. There is a chance for glare here - with both sides >>>> trying to initiate the o/a. I assumed for this flow that this >>>> doesn't happen >>>> - either one side waits for the other to go first, or else the >>>> timing results in one side sending first and that this then causes >>>> the other side to omit its own attempt because it is no longer needed. >>>> >>>> Because the two sides make independent choices of what to receive, >>>> and these may not be symmetric, it is necessary to consider both >>>> configurations to decide what to offer. Or else, one side sends an >>>> offer sufficient for itself, and then the other side may have to >>>> both answer and then make a new offer to add things it needs. >>>> >>>> This needs more discussion. I didn't sense any consensus or even >>>> common understanding of the issues and tradeoffs. >>>> >>>>> * The expert endpoints does not send a Configure message to the MCU. >>>>> Is >>>> this intentional or not? >>>> >>>> I'm having trouble remembering what I was thinking. :-) I think the >>>> note "Defer config till get request" is a mistake, and the expert >>>> should go ahead and send a Configure. I'll fix it. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Cheers >>>>> >>>>> -Espen >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: 11. september 2012 00:52 >>>>> To: CLUE >>>>> Subject: Re: [clue] New Version Notification for >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> >>>>> I just submitted in initial version of a new callflow draft. >>>>> A more useful link for it is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal >>>>> l >>>>> f >>>>> l >>>>> ow/ >>>>> >>>>> This is complementary to draft-romanow-clue-call-flow. >>>>> >>>>> I've focused on a particular use case rather than a generic one. >>>>> I've >>>> chosen the telemedical use case, and a special case of that use case. >>>>> Some of the interesting things about this case are that it includes >>>>> an MCU, and more than two endpoints. And those endpoints are not >>>>> all identical. (The latter point won't have obvious impact until >>>>> more detail is filled in.) >>>>> >>>>> And for now I've considered only the ladder diagram of sip and clue >>>> messages. That leaves a lot out. I expect it to be expanded to >>>> include the content of those messages. But before getting to that >>>> there are already a bunch of issues to sort out, that will impact >>>> what goes in those >>> messages. >>>>> >>>>> I don't have any illusions that this version is "correct". It is >>>>> just a >>>> starting point to discuss the issues. So please send comments. Maybe >>>> we will have time to talk about it at tomorrow's design team >>>> meeting, and/or at the interim next week. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>>> >>>>>> A new version of I-D, >>>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>>> Revision: 00 >>>>>> Title: CLUE Telemedical Use Case Callflow >>>>>> Creation date: 2012-09-11 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 8 >>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c >>>> a >>>> l >>>> lflow- >>>> 00.txt >>>>>> Status: >>>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >>>> l >>>> o >>>> w >>>>>> Htmlized: >>>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-0 >>>> 0 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This is the beginning of an example call flow for an >>>>>> instantiation >>>> of >>>>>> the use case described in the telemedical use case >>>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be > added >>>>>> later. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >>> >> >> > > From ron.even.tlv@gmail.com Fri Sep 14 15:01:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5821F84F6 for ; Fri, 14 Sep 2012 15:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGPpyMJJTL-L for ; Fri, 14 Sep 2012 15:01:52 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7C21F8444 for ; Fri, 14 Sep 2012 15:01:51 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so2546942wib.1 for ; Fri, 14 Sep 2012 15:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=OHPwc11l1ofzFgfy0KSxMTK0TjIDPiN8+MvnWqG0cXQ=; b=D0d/ii3FdJtG9EmejvJmxK5ypS9EP3AgLWUY+OL5aBqyVCFvDMk3ymoEkSWDe9ryul Jrmm9PQ1qzNRSUXLbTgVa0ZA2BOcdKDFhDgidJC9qc67oDIzd9o8P50c59Y4DKJ3Chbi WJ6L9ImPeUS/M/gwjAttuVkl3azFsZ/coGkQ0UkloISwZXC2iiogXIppdeCw5VOU16Fp BWPiS0ETjaGpzZK+DwP2IqLvKsM7EKwWAkQSREUljSBPnG7kg2e7AY3+IfxPA50rQaco WLLP1QPasw6t4oB8ipE+NiXUaeNK3fttnOUOZmGxnuO+lssDvJOelc2J/MkU6rvPISuP scRQ== Received: by 10.216.5.213 with SMTP id 63mr2252289wel.20.1347660110561; Fri, 14 Sep 2012 15:01:50 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id ct3sm1094807wib.5.2012.09.14.15.01.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 15:01:49 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> <010d01cd92c7$61e5a6c0$25b0f440$@gmail.com> <5053A573.1040907@alum.mit.edu> In-Reply-To: <5053A573.1040907@alum.mit.edu> Date: Sat, 15 Sep 2012 01:00:02 +0200 Message-ID: <011201cd92cc$ae852f00$0b8f8d00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2V0ZruT0VU3TL5YJEy+G6AcvvAJeBKjPAckOTB0CK35f6QHipvOUAmjyTpoBzzyP5QJFPnmLAlH/9Y8BZnwB7AJs338MAnbJUY8C7y+IYZYR9jcQ Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 22:01:53 -0000 Paul, Simulcast means that the sender can send one or more encodings of the same source depending on what the receiver wants. This is the issue that was raised in the discussion about individual encodes. Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 14 September, 2012 11:45 PM To: Roni Even Cc: 'Espen Berger (espeberg)'; 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt On 9/14/12 6:22 PM, Roni Even wrote: > Hi Paul, > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01 > describes how to do simulcast without CLUE. Now if you also describe > in CLUE the encoding (which I am not sure is needed for this case) you > should have the SDP correlated with CLUE, this will require the offer > answer after the CLUE configuration like I proposed in previous email. > If the SDP description is there you can switch with re-invite without > CLUE (you will need to re-invite to signal the port) Maybe we are talking about different things. ISTM that offering multiple encodings for a capture is not the same as simulcasting the capture in multiple encodings. AFAIK the simulcast means that you are sending out both, and people can decide which they want to receive. The advertisement says you could send one or the other or both. The configure then determines which you actually send, which again could be one or the other or maybe both. ISTM you only have a simulcast situation when you advertise both and the receiver configures both. I guess simulcasting two resolutions is more expensive than sending just one. So I don't see why we would do it unless the receiver wants both. It would be helpful to have some discussion of where simulcast has a role within CLUE. Maybe as part of the RTP document you and Jonathan are working on. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 9:13 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 3:36 PM, Roni Even wrote: >> Paul, >> Try to analyze it assuming that each resolution is using a different >> transport address, so you must use SDP to switch in which case why >> not define simulcast in SDP and not in CLUE. > > This is really into the "what goes where", which is a good discussion > to have! > > I guess what you are describing means that there are two alternate > encodings available for this capture. They could map to two different m-lines in sdp. > But what would cause them both to be listed in the SDP? > > This can work if the SDP is determined by the advertisement, and > covers all possible configurations that might be configured from that > advertisement. So then, if both are in an SDP offer that corresponds > to that advertisement, then the SDP answer can choose which of those > to accept. That is in effect doing a configuration, or part of it. For > that to work, the advertisement that explains what those mean would > have to be sent before the SDP offer, so that it would be available to > make the decision about what to accept in the answer. > > And then if later there is a desire to switch to the other resolution, > then I guess an SDP offer would be sent in the other direction, > changing which of the two m-lines has a non-zero port. > > It sounds like this can be made to work, though the devil is in the details. > It will require a lot of analysis of when advertisements must be sent > relative to offers. Based on above, an advertisement MAY/MUST? > be followed by an offer. And apparently the offer must be sufficient > for any configuration of that advertisement. I'm worried that this may > require the offerer to consume more resources than are required for most configurations. > > Thanks, > Paul > >> Roni >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 7:01 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> On 9/14/12 1:25 PM, Roni Even wrote: >>> Paul, >>> I can think of an example for SDP only with no CLUE but it depends >>> how simulcast is implemented. A switch from high res to low res of >>> the same capture (example room view) without a change in the CLUE >>> Roni >> >> OK. I can sort of see that. Maybe. >> >> Does this fall into the category of something where there are >> alternatives within a single config? >> >> But I would have thought that the high and low res versions of the >> same capture would be represented in clue signaling by advertising >> two possible encodings for the same capture, and then configuring the >> capture with one or the other. If so, then there would be a config >> message associated with the change. >> >> Thanks, >> Paul >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 14 September, 2012 5:44 PM >>> To: Roni Even >>> Cc: 'Espen Berger (espeberg)'; 'CLUE' >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> I agree with this. One comment below. >>> >>> On 9/14/12 12:15 PM, Roni Even wrote: >>>> Hi Paul, >>>> Other examples >>>> >>>> 1. want to add a transport connection when adding a new RTP stream >>>> (example opening a presentation stream during the call or changing >>>> the presentation >>>> stream) will require a re-invite. In general every change in the >>>> transport connection whether adding a new one when not SSRC >>>> multiplexing or changing the connection (transfer the call or some >>>> of the media streams without the CLUE channel) 2. Changing the >>>> codec used >>>> (H.26 to H.264 or audio codec) may require a re-invite. >>>> 3. When an MCU wants to change the common mode of a call when a >>>> party is added or dropped. >>>> >>>> There are more use cases. >>>> >>>> I see there are two types of requirements for re-invite. >>>> >>>> The first is during call setup in a point to point and multipoint >>>> call where the first invite is used to negotiate CLUE support and >>>> address interoperability with non-CLUE systems. After going the >>>> negotiation of the CLUE state there will be a need for a re-invite >>>> to correlate the CLUE and SDP states. >>>> >>>> The second during the call is when there is a change in the CLUE >>>> state that MAY require a correlation with the SDP state or even >>>> just an SDP state change like changing codec or addressing network >>>> or application issues that do not change the CLUE state. >>> >>> I think we don't yet know if there will be anything that makes sense >>> to change in SDP without some corresponding change in advertisement >>> or >> config. >>> If there is, it must be something for which there are alternative >>> ways to accomplish the configuration. I'm not sure what that might >>> be, but in principle I see it could happen. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Espen Berger (espeberg) >>>> Sent: 14 September, 2012 4:36 PM >>>> To: Paul Kyzivat >>>> Cc: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> My main point is that the initial INVITE can be sufficient for a >>>> call with CLUE negotiated media stream. >>>> >>>> One of the exceptions we have discussed is the requirement to >>>> upgrade bandwidth to allow for three camera/screen scenarios, which >>>> is typically not something you allocate in the network before you >>>> really >>> knows it's needed. >>>> In this case the re-INVITE is optional and there a clear user story >>>> to explain why and when we want to do it. >>>> >>>> I think necessary, and useful, to write down user stories to >>>> explain why a SIP re-INVITE is needed. With user stories it's much >>>> easier to discuss how to solve actual problems with protocols. >>>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 11. september 2012 17:51 >>>> To: Espen Berger (espeberg) >>>> Cc: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>>> My comments >>>>> >>>>> * It's natural that the MCU send an empty advertisement when the >>>>> classroom >>>> dials in as the first participant. If not, the classroom does not >>>> now if the conference is empty. The configuration message can be >>>> delayed, since you are mainly indicating that you do not want to >>>> receive > media. >>>> >>>> That is a good idea. I'll do it. >>>> >>>>> * I think the MCU can delay its initial configure message until >>>>> the >>>> classroom and surgery has done the configure message. With only two >>>> participant in the conference, you do not have to configure each >>>> endpoint to send media until the MCU knows someone request the >>>> media and also know the media restrictions. >>>>> >>>>> * What is the purpose for the second INVITE from the classroom, >>>>> where the >>>> text says 'to cover both configurations'. The initial SIP INVITE >>>> can be sufficient for payload numbers, bw, codec-parameters. Based >>>> on the draft-romanow-clue-call-flow document the main example for a >>>> re-invite is to increase or decrease bandwidth allocation. >>>> >>>> I assumed a consistent approach to first invites - that they are >>>> vanilla and minimal, and so aren't sufficient to support the actual >>>> CLUE >>> call. >>>> >>>> I have assumed that the invite with o/a to get things *right* is >>>> done >>>> *after* the Configure messages have been exchanged, when the needs >>>> are fully known. There is a chance for glare here - with both sides >>>> trying to initiate the o/a. I assumed for this flow that this >>>> doesn't happen >>>> - either one side waits for the other to go first, or else the >>>> timing results in one side sending first and that this then causes >>>> the other side to omit its own attempt because it is no longer needed. >>>> >>>> Because the two sides make independent choices of what to receive, >>>> and these may not be symmetric, it is necessary to consider both >>>> configurations to decide what to offer. Or else, one side sends an >>>> offer sufficient for itself, and then the other side may have to >>>> both answer and then make a new offer to add things it needs. >>>> >>>> This needs more discussion. I didn't sense any consensus or even >>>> common understanding of the issues and tradeoffs. >>>> >>>>> * The expert endpoints does not send a Configure message to the MCU. >>>>> Is >>>> this intentional or not? >>>> >>>> I'm having trouble remembering what I was thinking. :-) I think the >>>> note "Defer config till get request" is a mistake, and the expert >>>> should go ahead and send a Configure. I'll fix it. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Cheers >>>>> >>>>> -Espen >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: 11. september 2012 00:52 >>>>> To: CLUE >>>>> Subject: Re: [clue] New Version Notification for >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> >>>>> I just submitted in initial version of a new callflow draft. >>>>> A more useful link for it is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-ca >>>>> l >>>>> l >>>>> f >>>>> l >>>>> ow/ >>>>> >>>>> This is complementary to draft-romanow-clue-call-flow. >>>>> >>>>> I've focused on a particular use case rather than a generic one. >>>>> I've >>>> chosen the telemedical use case, and a special case of that use case. >>>>> Some of the interesting things about this case are that it >>>>> includes an MCU, and more than two endpoints. And those endpoints >>>>> are not all identical. (The latter point won't have obvious impact >>>>> until more detail is filled in.) >>>>> >>>>> And for now I've considered only the ladder diagram of sip and >>>>> clue >>>> messages. That leaves a lot out. I expect it to be expanded to >>>> include the content of those messages. But before getting to that >>>> there are already a bunch of issues to sort out, that will impact >>>> what goes in those >>> messages. >>>>> >>>>> I don't have any illusions that this version is "correct". It is >>>>> just a >>>> starting point to discuss the issues. So please send comments. >>>> Maybe we will have time to talk about it at tomorrow's design team >>>> meeting, and/or at the interim next week. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>>> >>>>>> A new version of I-D, >>>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>>> Revision: 00 >>>>>> Title: CLUE Telemedical Use Case Callflow >>>>>> Creation date: 2012-09-11 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 8 >>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical- >>>> c >>>> a >>>> l >>>> lflow- >>>> 00.txt >>>>>> Status: >>>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-call >>>> f >>>> l >>>> o >>>> w >>>>>> Htmlized: >>>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow- >>>> 0 >>>> 0 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This is the beginning of an example call flow for an >>>>>> instantiation >>>> of >>>>>> the use case described in the telemedical use case >>>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will >>>>>> be > added >>>>>> later. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >>> >> >> > > From pkyzivat@alum.mit.edu Fri Sep 14 15:02:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2394B21F8443 for ; Fri, 14 Sep 2012 15:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CTjeiXKIe7u for ; Fri, 14 Sep 2012 15:02:10 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BB0BD21F84FC for ; Fri, 14 Sep 2012 15:02:09 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id z9t81j00116LCl053A23ej; Fri, 14 Sep 2012 22:02:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id zA1h1j0033ZTu2S3SA1hrz; Fri, 14 Sep 2012 22:01:41 +0000 Message-ID: <5053A957.3060800@alum.mit.edu> Date: Fri, 14 Sep 2012 18:01:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> <011101cd92c8$79949eb0$6cbddc10$@gmail.com> In-Reply-To: <011101cd92c8$79949eb0$6cbddc10$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 22:02:11 -0000 On 9/14/12 6:29 PM, Roni Even wrote: > Paul, > One concern I have is that some of the usages like simulcast are not a CLUE > issue but are relevant also for non CLUE solutions. So to resolve this use > case we can mandate using CLUE (as a multi stream signaling) or resolve it > using SDP. The worst case is if we have two ways to signal without defining > the interoperability. > > I tried to provide in section 4.1 > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 a review of some > of the signaling proposal from AVTcore, AVText and MMSUIC that can address > some of the scenarios discussed in CLUE in order to have a full picture > before deciding to put something in CLUE protocol. > > I hope that people will look at these documents . I looked, and it is helpful to have these technologies identified. But as I said in my last message, it would be more helpful if the document could actually *position* the use of simulcast in the context of a clue session. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 9:13 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 3:36 PM, Roni Even wrote: >> Paul, >> Try to analyze it assuming that each resolution is using a different >> transport address, so you must use SDP to switch in which case why not >> define simulcast in SDP and not in CLUE. > > This is really into the "what goes where", which is a good discussion to > have! > > I guess what you are describing means that there are two alternate encodings > available for this capture. They could map to two different m-lines in sdp. > But what would cause them both to be listed in the SDP? > > This can work if the SDP is determined by the advertisement, and covers all > possible configurations that might be configured from that advertisement. So > then, if both are in an SDP offer that corresponds to that advertisement, > then the SDP answer can choose which of those to accept. That is in effect > doing a configuration, or part of it. For that to work, the advertisement > that explains what those mean would have to be sent before the SDP offer, so > that it would be available to make the decision about what to accept in the > answer. > > And then if later there is a desire to switch to the other resolution, then > I guess an SDP offer would be sent in the other direction, changing which of > the two m-lines has a non-zero port. > > It sounds like this can be made to work, though the devil is in the details. > It will require a lot of analysis of when advertisements must be sent > relative to offers. Based on above, an advertisement MAY/MUST? > be followed by an offer. And apparently the offer must be sufficient for any > configuration of that advertisement. I'm worried that this may require the > offerer to consume more resources than are required for most configurations. > > Thanks, > Paul > >> Roni >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 7:01 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> On 9/14/12 1:25 PM, Roni Even wrote: >>> Paul, >>> I can think of an example for SDP only with no CLUE but it depends >>> how simulcast is implemented. A switch from high res to low res of >>> the same capture (example room view) without a change in the CLUE >>> Roni >> >> OK. I can sort of see that. Maybe. >> >> Does this fall into the category of something where there are >> alternatives within a single config? >> >> But I would have thought that the high and low res versions of the >> same capture would be represented in clue signaling by advertising two >> possible encodings for the same capture, and then configuring the >> capture with one or the other. If so, then there would be a config >> message associated with the change. >> >> Thanks, >> Paul >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 14 September, 2012 5:44 PM >>> To: Roni Even >>> Cc: 'Espen Berger (espeberg)'; 'CLUE' >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> I agree with this. One comment below. >>> >>> On 9/14/12 12:15 PM, Roni Even wrote: >>>> Hi Paul, >>>> Other examples >>>> >>>> 1. want to add a transport connection when adding a new RTP stream >>>> (example opening a presentation stream during the call or changing >>>> the presentation >>>> stream) will require a re-invite. In general every change in the >>>> transport connection whether adding a new one when not SSRC >>>> multiplexing or changing the connection (transfer the call or some >>>> of the media streams without the CLUE channel) 2. Changing the codec >>>> used >>>> (H.26 to H.264 or audio codec) may require a re-invite. >>>> 3. When an MCU wants to change the common mode of a call when a >>>> party is added or dropped. >>>> >>>> There are more use cases. >>>> >>>> I see there are two types of requirements for re-invite. >>>> >>>> The first is during call setup in a point to point and multipoint >>>> call where the first invite is used to negotiate CLUE support and >>>> address interoperability with non-CLUE systems. After going the >>>> negotiation of the CLUE state there will be a need for a re-invite >>>> to correlate the CLUE and SDP states. >>>> >>>> The second during the call is when there is a change in the CLUE >>>> state that MAY require a correlation with the SDP state or even just >>>> an SDP state change like changing codec or addressing network or >>>> application issues that do not change the CLUE state. >>> >>> I think we don't yet know if there will be anything that makes sense >>> to change in SDP without some corresponding change in advertisement >>> or >> config. >>> If there is, it must be something for which there are alternative >>> ways to accomplish the configuration. I'm not sure what that might >>> be, but in principle I see it could happen. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Espen Berger (espeberg) >>>> Sent: 14 September, 2012 4:36 PM >>>> To: Paul Kyzivat >>>> Cc: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> My main point is that the initial INVITE can be sufficient for a >>>> call with CLUE negotiated media stream. >>>> >>>> One of the exceptions we have discussed is the requirement to >>>> upgrade bandwidth to allow for three camera/screen scenarios, which >>>> is typically not something you allocate in the network before you >>>> really >>> knows it's needed. >>>> In this case the re-INVITE is optional and there a clear user story >>>> to explain why and when we want to do it. >>>> >>>> I think necessary, and useful, to write down user stories to explain >>>> why a SIP re-INVITE is needed. With user stories it's much easier >>>> to discuss how to solve actual problems with protocols. >>>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 11. september 2012 17:51 >>>> To: Espen Berger (espeberg) >>>> Cc: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>>> My comments >>>>> >>>>> * It's natural that the MCU send an empty advertisement when the >>>>> classroom >>>> dials in as the first participant. If not, the classroom does not >>>> now if the conference is empty. The configuration message can be >>>> delayed, since you are mainly indicating that you do not want to receive > media. >>>> >>>> That is a good idea. I'll do it. >>>> >>>>> * I think the MCU can delay its initial configure message until the >>>> classroom and surgery has done the configure message. With only two >>>> participant in the conference, you do not have to configure each >>>> endpoint to send media until the MCU knows someone request the media >>>> and also know the media restrictions. >>>>> >>>>> * What is the purpose for the second INVITE from the classroom, >>>>> where the >>>> text says 'to cover both configurations'. The initial SIP INVITE can >>>> be sufficient for payload numbers, bw, codec-parameters. Based on >>>> the draft-romanow-clue-call-flow document the main example for a >>>> re-invite is to increase or decrease bandwidth allocation. >>>> >>>> I assumed a consistent approach to first invites - that they are >>>> vanilla and minimal, and so aren't sufficient to support the actual >>>> CLUE >>> call. >>>> >>>> I have assumed that the invite with o/a to get things *right* is >>>> done >>>> *after* the Configure messages have been exchanged, when the needs >>>> are fully known. There is a chance for glare here - with both sides >>>> trying to initiate the o/a. I assumed for this flow that this >>>> doesn't happen >>>> - either one side waits for the other to go first, or else the >>>> timing results in one side sending first and that this then causes >>>> the other side to omit its own attempt because it is no longer needed. >>>> >>>> Because the two sides make independent choices of what to receive, >>>> and these may not be symmetric, it is necessary to consider both >>>> configurations to decide what to offer. Or else, one side sends an >>>> offer sufficient for itself, and then the other side may have to >>>> both answer and then make a new offer to add things it needs. >>>> >>>> This needs more discussion. I didn't sense any consensus or even >>>> common understanding of the issues and tradeoffs. >>>> >>>>> * The expert endpoints does not send a Configure message to the MCU. >>>>> Is >>>> this intentional or not? >>>> >>>> I'm having trouble remembering what I was thinking. :-) I think the >>>> note "Defer config till get request" is a mistake, and the expert >>>> should go ahead and send a Configure. I'll fix it. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Cheers >>>>> >>>>> -Espen >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: 11. september 2012 00:52 >>>>> To: CLUE >>>>> Subject: Re: [clue] New Version Notification for >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> >>>>> I just submitted in initial version of a new callflow draft. >>>>> A more useful link for it is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal >>>>> l >>>>> f >>>>> l >>>>> ow/ >>>>> >>>>> This is complementary to draft-romanow-clue-call-flow. >>>>> >>>>> I've focused on a particular use case rather than a generic one. >>>>> I've >>>> chosen the telemedical use case, and a special case of that use case. >>>>> Some of the interesting things about this case are that it includes >>>>> an MCU, and more than two endpoints. And those endpoints are not >>>>> all identical. (The latter point won't have obvious impact until >>>>> more detail is filled in.) >>>>> >>>>> And for now I've considered only the ladder diagram of sip and clue >>>> messages. That leaves a lot out. I expect it to be expanded to >>>> include the content of those messages. But before getting to that >>>> there are already a bunch of issues to sort out, that will impact >>>> what goes in those >>> messages. >>>>> >>>>> I don't have any illusions that this version is "correct". It is >>>>> just a >>>> starting point to discuss the issues. So please send comments. Maybe >>>> we will have time to talk about it at tomorrow's design team >>>> meeting, and/or at the interim next week. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>>> >>>>>> A new version of I-D, >>>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>>> Revision: 00 >>>>>> Title: CLUE Telemedical Use Case Callflow >>>>>> Creation date: 2012-09-11 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 8 >>>>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c >>>> a >>>> l >>>> lflow- >>>> 00.txt >>>>>> Status: >>>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >>>> l >>>> o >>>> w >>>>>> Htmlized: >>>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-0 >>>> 0 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This is the beginning of an example call flow for an >>>>>> instantiation >>>> of >>>>>> the use case described in the telemedical use case >>>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be > added >>>>>> later. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >>> >> >> > > From mary.ietf.barnes@gmail.com Fri Sep 14 15:03:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DC221F8489 for ; Fri, 14 Sep 2012 15:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxAGyPAGnlDH for ; Fri, 14 Sep 2012 15:03:48 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9A21F8468 for ; Fri, 14 Sep 2012 15:03:47 -0700 (PDT) Received: by lahm15 with SMTP id m15so3234448lah.31 for ; Fri, 14 Sep 2012 15:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=76GYhQzaCN3joLQ/FceiLjK8OkPggZgf16KqVSe/zbI=; b=ToyQjtFLYbsks4KLpSP4czhmmeEZEeJQ93b63PN3vM9/rb2oz/qp4mzTzTE+P2+1vR diDi5FeHadID4xO/sJdIDlIJQPTW9RyiFO1+QeBiE1olukXLVQFiAmG9UJ0aTECRlh0q 6v36uyCrUg4UHggdtH7TzWdSpWTKTNucTAhgyJ52nFpM37vwV1DfgP0CSu8fcvsPrbcj 5BvHtk62ZVC6ouY69dsHuJK/gJQaOKCpze9Jj3c5b7UgyaM+f6C3+eZ5LU8Ef2zWGSBM 3fFPOhrHjsqLwq31RPNrn92FuYKnQzOOWC38dlmGrVBlw52Wkg3mQO12V+Zvh6QpmOL3 G8mA== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr3736208lab.43.1347660226387; Fri, 14 Sep 2012 15:03:46 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Fri, 14 Sep 2012 15:03:46 -0700 (PDT) In-Reply-To: <011101cd92c8$79949eb0$6cbddc10$@gmail.com> References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> <011101cd92c8$79949eb0$6cbddc10$@gmail.com> Date: Fri, 14 Sep 2012 17:03:46 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d0434bfde125e4604c9b099b7 Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 22:03:50 -0000 --f46d0434bfde125e4604c9b099b7 Content-Type: text/plain; charset=ISO-8859-1 This is a really important point. I totally agree that we need to consider that what CLUE needs or might define at the SDP level should be usable for non-CLUE endpoints for interoperability. This may put some limitations and restrictions on the decisions we make as to what is carried in SDP versus in CLUE application level signaling. Mary. On Fri, Sep 14, 2012 at 5:29 PM, Roni Even wrote: > Paul, > One concern I have is that some of the usages like simulcast are not a CLUE > issue but are relevant also for non CLUE solutions. So to resolve this use > case we can mandate using CLUE (as a multi stream signaling) or resolve it > using SDP. The worst case is if we have two ways to signal without defining > the interoperability. > > I tried to provide in section 4.1 > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 a review of some > of the signaling proposal from AVTcore, AVText and MMSUIC that can address > some of the scenarios discussed in CLUE in order to have a full picture > before deciding to put something in CLUE protocol. > > I hope that people will look at these documents . > > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 9:13 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 3:36 PM, Roni Even wrote: > > Paul, > > Try to analyze it assuming that each resolution is using a different > > transport address, so you must use SDP to switch in which case why not > > define simulcast in SDP and not in CLUE. > > This is really into the "what goes where", which is a good discussion to > have! > > I guess what you are describing means that there are two alternate > encodings > available for this capture. They could map to two different m-lines in sdp. > But what would cause them both to be listed in the SDP? > > This can work if the SDP is determined by the advertisement, and covers all > possible configurations that might be configured from that advertisement. > So > then, if both are in an SDP offer that corresponds to that advertisement, > then the SDP answer can choose which of those to accept. That is in effect > doing a configuration, or part of it. For that to work, the advertisement > that explains what those mean would have to be sent before the SDP offer, > so > that it would be available to make the decision about what to accept in the > answer. > > And then if later there is a desire to switch to the other resolution, then > I guess an SDP offer would be sent in the other direction, changing which > of > the two m-lines has a non-zero port. > > It sounds like this can be made to work, though the devil is in the > details. > It will require a lot of analysis of when advertisements must be sent > relative to offers. Based on above, an advertisement MAY/MUST? > be followed by an offer. And apparently the offer must be sufficient for > any > configuration of that advertisement. I'm worried that this may require the > offerer to consume more resources than are required for most > configurations. > > Thanks, > Paul > > > Roni > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: 14 September, 2012 7:01 PM > > To: Roni Even > > Cc: 'Espen Berger (espeberg)'; 'CLUE' > > Subject: Re: [clue] New Version Notification for > > draft-kyzivat-clue-telemedical-callflow-00.txt > > > > On 9/14/12 1:25 PM, Roni Even wrote: > >> Paul, > >> I can think of an example for SDP only with no CLUE but it depends > >> how simulcast is implemented. A switch from high res to low res of > >> the same capture (example room view) without a change in the CLUE > >> Roni > > > > OK. I can sort of see that. Maybe. > > > > Does this fall into the category of something where there are > > alternatives within a single config? > > > > But I would have thought that the high and low res versions of the > > same capture would be represented in clue signaling by advertising two > > possible encodings for the same capture, and then configuring the > > capture with one or the other. If so, then there would be a config > > message associated with the change. > > > > Thanks, > > Paul > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 14 September, 2012 5:44 PM > >> To: Roni Even > >> Cc: 'Espen Berger (espeberg)'; 'CLUE' > >> Subject: Re: [clue] New Version Notification for > >> draft-kyzivat-clue-telemedical-callflow-00.txt > >> > >> I agree with this. One comment below. > >> > >> On 9/14/12 12:15 PM, Roni Even wrote: > >>> Hi Paul, > >>> Other examples > >>> > >>> 1. want to add a transport connection when adding a new RTP stream > >>> (example opening a presentation stream during the call or changing > >>> the presentation > >>> stream) will require a re-invite. In general every change in the > >>> transport connection whether adding a new one when not SSRC > >>> multiplexing or changing the connection (transfer the call or some > >>> of the media streams without the CLUE channel) 2. Changing the codec > >>> used > >>> (H.26 to H.264 or audio codec) may require a re-invite. > >>> 3. When an MCU wants to change the common mode of a call when a > >>> party is added or dropped. > >>> > >>> There are more use cases. > >>> > >>> I see there are two types of requirements for re-invite. > >>> > >>> The first is during call setup in a point to point and multipoint > >>> call where the first invite is used to negotiate CLUE support and > >>> address interoperability with non-CLUE systems. After going the > >>> negotiation of the CLUE state there will be a need for a re-invite > >>> to correlate the CLUE and SDP states. > >>> > >>> The second during the call is when there is a change in the CLUE > >>> state that MAY require a correlation with the SDP state or even just > >>> an SDP state change like changing codec or addressing network or > >>> application issues that do not change the CLUE state. > >> > >> I think we don't yet know if there will be anything that makes sense > >> to change in SDP without some corresponding change in advertisement > >> or > > config. > >> If there is, it must be something for which there are alternative > >> ways to accomplish the configuration. I'm not sure what that might > >> be, but in principle I see it could happen. > >> > >> Thanks, > >> Paul > >> > >>> Roni > >>> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >>> Of Espen Berger (espeberg) > >>> Sent: 14 September, 2012 4:36 PM > >>> To: Paul Kyzivat > >>> Cc: CLUE > >>> Subject: Re: [clue] New Version Notification for > >>> draft-kyzivat-clue-telemedical-callflow-00.txt > >>> > >>> My main point is that the initial INVITE can be sufficient for a > >>> call with CLUE negotiated media stream. > >>> > >>> One of the exceptions we have discussed is the requirement to > >>> upgrade bandwidth to allow for three camera/screen scenarios, which > >>> is typically not something you allocate in the network before you > >>> really > >> knows it's needed. > >>> In this case the re-INVITE is optional and there a clear user story > >>> to explain why and when we want to do it. > >>> > >>> I think necessary, and useful, to write down user stories to explain > >>> why a SIP re-INVITE is needed. With user stories it's much easier > >>> to discuss how to solve actual problems with protocols. > >>> > >>> Cheers > >>> > >>> -Espen > >>> > >>> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Sent: 11. september 2012 17:51 > >>> To: Espen Berger (espeberg) > >>> Cc: CLUE > >>> Subject: Re: [clue] New Version Notification for > >>> draft-kyzivat-clue-telemedical-callflow-00.txt > >>> > >>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: > >>>> My comments > >>>> > >>>> * It's natural that the MCU send an empty advertisement when the > >>>> classroom > >>> dials in as the first participant. If not, the classroom does not > >>> now if the conference is empty. The configuration message can be > >>> delayed, since you are mainly indicating that you do not want to > receive > media. > >>> > >>> That is a good idea. I'll do it. > >>> > >>>> * I think the MCU can delay its initial configure message until the > >>> classroom and surgery has done the configure message. With only two > >>> participant in the conference, you do not have to configure each > >>> endpoint to send media until the MCU knows someone request the media > >>> and also know the media restrictions. > >>>> > >>>> * What is the purpose for the second INVITE from the classroom, > >>>> where the > >>> text says 'to cover both configurations'. The initial SIP INVITE can > >>> be sufficient for payload numbers, bw, codec-parameters. Based on > >>> the draft-romanow-clue-call-flow document the main example for a > >>> re-invite is to increase or decrease bandwidth allocation. > >>> > >>> I assumed a consistent approach to first invites - that they are > >>> vanilla and minimal, and so aren't sufficient to support the actual > >>> CLUE > >> call. > >>> > >>> I have assumed that the invite with o/a to get things *right* is > >>> done > >>> *after* the Configure messages have been exchanged, when the needs > >>> are fully known. There is a chance for glare here - with both sides > >>> trying to initiate the o/a. I assumed for this flow that this > >>> doesn't happen > >>> - either one side waits for the other to go first, or else the > >>> timing results in one side sending first and that this then causes > >>> the other side to omit its own attempt because it is no longer needed. > >>> > >>> Because the two sides make independent choices of what to receive, > >>> and these may not be symmetric, it is necessary to consider both > >>> configurations to decide what to offer. Or else, one side sends an > >>> offer sufficient for itself, and then the other side may have to > >>> both answer and then make a new offer to add things it needs. > >>> > >>> This needs more discussion. I didn't sense any consensus or even > >>> common understanding of the issues and tradeoffs. > >>> > >>>> * The expert endpoints does not send a Configure message to the MCU. > >>>> Is > >>> this intentional or not? > >>> > >>> I'm having trouble remembering what I was thinking. :-) I think the > >>> note "Defer config till get request" is a mistake, and the expert > >>> should go ahead and send a Configure. I'll fix it. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Cheers > >>>> > >>>> -Espen > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: 11. september 2012 00:52 > >>>> To: CLUE > >>>> Subject: Re: [clue] New Version Notification for > >>>> draft-kyzivat-clue-telemedical-callflow-00.txt > >>>> > >>>> I just submitted in initial version of a new callflow draft. > >>>> A more useful link for it is: > >>>> > >>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal > >>>> l > >>>> f > >>>> l > >>>> ow/ > >>>> > >>>> This is complementary to draft-romanow-clue-call-flow. > >>>> > >>>> I've focused on a particular use case rather than a generic one. > >>>> I've > >>> chosen the telemedical use case, and a special case of that use case. > >>>> Some of the interesting things about this case are that it includes > >>>> an MCU, and more than two endpoints. And those endpoints are not > >>>> all identical. (The latter point won't have obvious impact until > >>>> more detail is filled in.) > >>>> > >>>> And for now I've considered only the ladder diagram of sip and clue > >>> messages. That leaves a lot out. I expect it to be expanded to > >>> include the content of those messages. But before getting to that > >>> there are already a bunch of issues to sort out, that will impact > >>> what goes in those > >> messages. > >>>> > >>>> I don't have any illusions that this version is "correct". It is > >>>> just a > >>> starting point to discuss the issues. So please send comments. Maybe > >>> we will have time to talk about it at tomorrow's design team > >>> meeting, and/or at the interim next week. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: > >>>>> > >>>>> A new version of I-D, > >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt > >>>>> has been successfully submitted by Paul H. Kyzivat and posted to > >>>>> the IETF repository. > >>>>> > >>>>> Filename: draft-kyzivat-clue-telemedical-callflow > >>>>> Revision: 00 > >>>>> Title: CLUE Telemedical Use Case Callflow > >>>>> Creation date: 2012-09-11 > >>>>> WG ID: Individual Submission > >>>>> Number of pages: 8 > >>>>> URL: > >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c > >>> a > >>> l > >>> lflow- > >>> 00.txt > >>>>> Status: > >>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf > >>> l > >>> o > >>> w > >>>>> Htmlized: > >>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-0 > >>> 0 > >>>>> > >>>>> > >>>>> Abstract: > >>>>> This is the beginning of an example call flow for an > >>>>> instantiation > >>> of > >>>>> the use case described in the telemedical use case > >>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be > added > >>>>> later. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The IETF Secretariat > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > >> > >> > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d0434bfde125e4604c9b099b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a really important point. =A0I totally agree that we need to consid= er that what CLUE needs or might define at the SDP level should be usable f= or non-CLUE endpoints for interoperability. =A0This may put some limitation= s and restrictions on the decisions we make as to what is carried in SDP ve= rsus in CLUE application level signaling.

Mary.=A0

On Fri, Sep 14, 2= 012 at 5:29 PM, Roni Even <ron.even.tlv@gmail.com> wrot= e:

Paul,
One concern I have is that some of the usages like simulcast are not a CLUE=
issue but are relevant also for non CLUE solutions. So to resolve this use<= br> case we can mandate using CLUE (as a multi stream signaling) or resolve it<= br> using SDP. The worst case is if we have two ways to signal without defining=
the interoperability.

I tried to provide in section 4.1
http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 = a review of some
of the signaling proposal from AVTcore, AVText and MMSUIC that can address<= br> some of the scenarios discussed in CLUE in order to have a full picture
before deciding to put something in CLUE protocol.

I hope that people will look at these documents .

Roni

-----Original Message-----
From: Paul Kyzivat [mailto:pkyziva= t@alum.mit.edu]

Sent: 14 September, 2012 9:13= PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for
draft-kyzivat-clue-telemedical-callflow-00.txt

On 9/14/12 3:36 PM, Roni Even wrote:
> Paul,
> Try to analyze it assuming that each resolution is using a different > transport address, so you must use SDP to switch in which case why not=
> define simulcast in SDP and not in CLUE.

This is really into the "what goes where", which is a good discus= sion to
have!

I guess what you are describing means that there are two alternate encoding= s
available for this capture. They could map to two different m-lines in sdp.=
But what would cause them both to be listed in the SDP?

This can work if the SDP is determined by the advertisement, and covers all=
possible configurations that might be configured from that advertisement. S= o
then, if both are in an SDP offer that corresponds to that advertisement, then the SDP answer can choose which of those to accept. That is in effect<= br> doing a configuration, or part of it. For that to work, the advertisement that explains what those mean would have to be sent before the SDP offer, s= o
that it would be available to make the decision about what to accept in the=
answer.

And then if later there is a desire to switch to the other resolution, then=
I guess an SDP offer would be sent in the other direction, changing which o= f
the two m-lines has a non-zero port.

It sounds like this can be made to work, though the devil is in the details= .
It will require a lot of analysis of when advertisements must be sent
relative to offers. Based on above, an advertisement MAY/MUST?
be followed by an offer. And apparently the offer must be sufficient for an= y
configuration of that advertisement. I'm worried that this may require = the
offerer to consume more resources than are required for most configurations= .

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Roni
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pk= yzivat@alum.mit.edu]
> Sent: 14 September, 2012 7:01 PM
> To: Roni Even
> Cc: 'Espen Berger (espeberg)'; 'CLUE'
> Subject: Re: [clue] New Version Notification for
> draft-kyzivat-clue-telemedical-callflow-00.txt
>
> On 9/14/12 1:25 PM, Roni Even wrote:
>> Paul,
>> I can think of an example for SDP only with no CLUE but it depends=
>> how simulcast is implemented. A switch from high res to low res of=
>> the same capture (example room view) without a change in the CLUE<= br> >> Roni
>
> OK. I can sort of see that. Maybe.
>
> Does this fall into the category of something where there are
> alternatives within a single config?
>
> But I would have thought that the high and low res versions of the
> same capture would be represented in clue signaling by advertising two=
> possible encodings for the same capture, and then configuring the
> capture with one or the other. If so, then there would be a config
> message associated with the change.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 14 September, 2012 5:44 PM
>> To: Roni Even
>> Cc: 'Espen Berger (espeberg)'; 'CLUE'
>> Subject: Re: [clue] New Version Notification for
>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>
>> I agree with this. One comment below.
>>
>> On 9/14/12 12:15 PM, Roni Even wrote:
>>> Hi Paul,
>>> Other examples
>>>
>>> 1. want to add a transport connection when adding a new RTP st= ream
>>> (example opening a presentation stream during the call or chan= ging
>>> the presentation
>>> stream) will require a =A0re-invite. In general every change i= n the
>>> transport connection whether adding a new one when not SSRC >>> multiplexing or changing the connection (transfer the call or = some
>>> of the media streams without the CLUE channel) 2. Changing the= codec
>>> used
>>> (H.26 to H.264 or audio codec) may require a re-invite.
>>> 3. When an MCU wants to change the common mode of a call when = a
>>> party is added or dropped.
>>>
>>> There are more use cases.
>>>
>>> I see there are two types of requirements for re-invite.
>>>
>>> The first is during call setup in a point to point and multipo= int
>>> call where the first invite is used to negotiate CLUE support = and
>>> address interoperability with non-CLUE systems. After going th= e
>>> negotiation of the CLUE state there will be a need for a re-in= vite
>>> to correlate the CLUE and SDP states.
>>>
>>> The second during the call is when there is a change in the CL= UE
>>> state that MAY require a correlation with the SDP state or eve= n just
>>> an SDP state change like changing codec or addressing network = or
>>> application issues that do not change the CLUE state.
>>
>> I think we don't yet know if there will be anything that makes= sense
>> to change in SDP without some corresponding change in advertisemen= t
>> or
> config.
>> If there is, it must be something for which there are alternative<= br> >> ways to accomplish the configuration. I'm not sure what that m= ight
>> be, but in principle I see it could happen.
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> Roni
>>>
>>> -----Original Message-----
>>> From: clue-bounces@ie= tf.org [mailto:clue-bounces@ie= tf.org] On Behalf
>>> Of Espen Berger (espeberg)
>>> Sent: 14 September, 2012 4:36 PM
>>> To: Paul Kyzivat
>>> Cc: CLUE
>>> Subject: Re: [clue] New Version Notification for
>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>>
>>> My main point is that the initial INVITE can be sufficient for= a
>>> call with CLUE negotiated media stream.
>>>
>>> One of the exceptions we have discussed is the requirement to<= br> >>> upgrade bandwidth to allow for three camera/screen scenarios, = which
>>> is typically not something you allocate in the network before = you
>>> really
>> knows it's needed.
>>> In this case the re-INVITE is optional and there a clear user = story
>>> to explain why and when we want to do it.
>>>
>>> I think necessary, and useful, to write down user stories to e= xplain
>>> why a SIP re-INVITE is needed. =A0With user stories it's m= uch easier
>>> to discuss how to solve actual problems with protocols.
>>>
>>> Cheers
>>>
>>> -Espen
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: 11. september 2012 17:51
>>> To: Espen Berger (espeberg)
>>> Cc: CLUE
>>> Subject: Re: [clue] New Version Notification for
>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>>
>>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote:
>>>> My comments
>>>>
>>>> * It's natural that the MCU send an empty advertisemen= t when the
>>>> classroom
>>> dials in as the first participant. If not, the classroom does = not
>>> now if the conference is empty. The configuration message can = be
>>> delayed, since you are mainly indicating that you do not want = to receive
media.
>>>
>>> That is a good idea. I'll do it.
>>>
>>>> * I think the MCU can delay its initial configure message = until the
>>> classroom and surgery has done the configure message. With onl= y two
>>> participant in the conference, you do not have to configure ea= ch
>>> endpoint to send media until the MCU knows someone request the= media
>>> and also know the media restrictions.
>>>>
>>>> * What is the purpose for the second INVITE from the class= room,
>>>> where the
>>> text says 'to cover both configurations'. The initial = SIP INVITE can
>>> be sufficient for payload numbers, bw, codec-parameters. Based= on
>>> the draft-romanow-clue-call-flow document the main example for= a
>>> re-invite is to increase or decrease bandwidth allocation.
>>>
>>> I assumed a consistent approach to first invites - that they a= re
>>> vanilla and minimal, and so aren't sufficient to support t= he actual
>>> CLUE
>> call.
>>>
>>> I have assumed that the invite with o/a to get things *right* = is
>>> done
>>> *after* the Configure messages have been exchanged, when the n= eeds
>>> are fully known. There is a chance for glare here - with both = sides
>>> trying to initiate the o/a. I assumed for this flow that this<= br> >>> doesn't happen
>>> - either one side waits for the other to go first, or else the=
>>> timing results in one side sending first and that this then ca= uses
>>> the other side to omit its own attempt because it is no longer= needed.
>>>
>>> Because the two sides make independent choices of what to rece= ive,
>>> and these may not be symmetric, it is necessary to consider bo= th
>>> configurations to decide what to offer. Or else, one side send= s an
>>> offer sufficient for itself, and then the other side may have = to
>>> both answer and then make a new offer to add things it needs.<= br> >>>
>>> This needs more discussion. I didn't sense any consensus o= r even
>>> common understanding of the issues and tradeoffs.
>>>
>>>> * The expert endpoints does not send a Configure message t= o the MCU.
>>>> Is
>>> this intentional or not?
>>>
>>> I'm having trouble remembering what I was thinking. :-) I = think the
>>> note "Defer config till get request" is a mistake, a= nd the expert
>>> should go ahead and send a Configure. I'll fix it.
>>>
>>> =A0 =A0 Thanks,
>>> =A0 =A0 Paul
>>>
>>>> Cheers
>>>>
>>>> -Espen
>>>>
>>>> -----Original Message-----
>>>> From: clue-bounce= s@ietf.org [mailto:clue-bounce= s@ietf.org] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: 11. september 2012 00:52
>>>> To: CLUE
>>>> Subject: Re: [clue] New Version Notification for
>>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>>>
>>>> I just submitted in initial version of a new callflow draf= t.
>>>> A more useful link for it is:
>>>>
>>>> https://datatracker.ietf.org/doc/dr= aft-kyzivat-clue-telemedical-cal
>>>> l
>>>> f
>>>> l
>>>> ow/
>>>>
>>>> This is complementary to draft-romanow-clue-call-flow.
>>>>
>>>> I've focused on a particular use case rather than a ge= neric one.
>>>> I've
>>> chosen the telemedical use case, and a special case of that us= e case.
>>>> Some of the interesting things about this case are that it= includes
>>>> an MCU, and more than two endpoints. And those endpoints a= re not
>>>> all identical. (The latter point won't have obvious im= pact until
>>>> more detail is filled in.)
>>>>
>>>> And for now I've considered only the ladder diagram of= sip and clue
>>> messages. That leaves a lot out. I expect it to be expanded to=
>>> include the content of those messages. But before getting to t= hat
>>> there are already a bunch of issues to sort out, that will imp= act
>>> what goes in those
>> messages.
>>>>
>>>> I don't have any illusions that this version is "= correct". It is
>>>> just a
>>> starting point to discuss the issues. So please send comments.= Maybe
>>> we will have time to talk about it at tomorrow's design te= am
>>> meeting, and/or at the interim next week.
>>>>
>>>> =A0 =A0Thanks,
>>>> =A0 =A0Paul
>>>>
>>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote:
>>>>>
>>>>> A new version of I-D,
>>>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>>>> has been successfully submitted by Paul H. Kyzivat and= posted to
>>>>> the IETF repository.
>>>>>
>>>>> Filename: =A0draft-kyzivat-clue-telemedical-callflow >>>>> Revision: =A000
>>>>> Title: =A0 =A0 =A0 =A0 =A0 =A0 CLUE Telemedical Use Ca= se Callflow
>>>>> Creation date: =A0 =A0 2012-09-11
>>>>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission >>>>> Number of pages: 8
>>>>> URL:
>>> http://www.ietf.org/internet-drafts/dr= aft-kyzivat-clue-telemedical-c
>>> a
>>> l
>>> lflow-
>>> 00.txt
>>>>> Status:

>>> h= ttp://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf
>>> l
>>> o
>>> w
>>>>> Htmlized:
>>> http://tools.ietf.org/html/draft-kyziv= at-clue-telemedical-callflow-0
>>> 0
>>>>>
>>>>>

>>>>> Abstract= :
>>>>> =A0 =A0 =A0 =A0 This is the beginning of an example ca= ll flow for an
>>>>> instantiation
>>> of
>>>>> =A0 =A0 =A0 =A0 the use case described in the telemedi= cal use case
>>>>> =A0 =A0 =A0 =A0 [I-D.xiao-clue-telemedical-use-case]. = =A0More detail will be
added
>>>>> =A0 =A0 =A0 =A0 later.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>>
>>
>>
>
>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--f46d0434bfde125e4604c9b099b7-- From mary.ietf.barnes@gmail.com Sun Sep 16 14:55:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1721F84E7 for ; Sun, 16 Sep 2012 14:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXOYYgGG8Q0f for ; Sun, 16 Sep 2012 14:55:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31821F84E1 for ; Sun, 16 Sep 2012 14:55:52 -0700 (PDT) Received: by lahm15 with SMTP id m15so4022511lah.31 for ; Sun, 16 Sep 2012 14:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=s4oqWlXpxoeATAgCvC7KAOv0m71axA2qFf4GsPyTRnE=; b=M47UTjP519yz8cwCbRpqAy8j9AW0Q0UXedLyjEMAJPMMXu95vRJdHA/ZJ2EWtfNqAi 627zna36/9EzjsljZe9qqrC0YGweK+KfPmtUKTyGCGFNq/k5vORRbcpcBJpGNx4Z8f0E Wj4I0gdWEOPHdqca0R1gqYUKRAobQji2FyIYiuDz/+7jHDJSe9okt84eGKbjIDZvU0sl Scby5n1cMfAoY/DAg96Sea6gCtsxkWHexE7vRmOEWrHCPkRdChpEiwOdNxgZ3i2xIF+W DCQUt8gyZbw3eFFcfwLAsGWc8OAEg4N+jHcIv6X0gliCUHx5aDwOICbAHrUMpUhhVcLy anqA== MIME-Version: 1.0 Received: by 10.112.45.72 with SMTP id k8mr3299441lbm.57.1347832552068; Sun, 16 Sep 2012 14:55:52 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Sun, 16 Sep 2012 14:55:52 -0700 (PDT) Date: Sun, 16 Sep 2012 16:55:52 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04016d9f7b96c104c9d8b823 Subject: [clue] Updated agenda for CLUE Interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:55:54 -0000 --f46d04016d9f7b96c104c9d8b823 Content-Type: text/plain; charset=ISO-8859-1 Below, please find the agenda (I can't upload it to the meeting materials right now as it looks like they're mucking with the server). Also, we were not able to upload all the design team minutes as there is a bug somewhere and both Paul and I get permission errors. So, the agenda has links to the minutes as they were posted to the mailing list as opposed to the version on the wiki. Note, that we have assigned "discussion leaders". The plan is not to review documents per se. But, to focus on issues that have arisen on the mailing list and during design team calls. We also have more than enough materials from the IETF-84 meeting for each of the documents. If you are listed as a leader and are unsure of what we expect, please let the chairs know and we can work with you on what we have in mind. We do not anticipate lots of slides but rather discussion and focusing on issue resolution. Note, that the first part of the meeting, we will discuss the meeting format and objectives. Participants are expected to at least have reviewed the mailing list threads for the current issues and to please review the meeting minutes in cases where you were not able to attend. Some revisiting of discussions can be useful, but we don't want to repeat too much. Thanks, Mary. ============================================================== CLUE WG Interim Meeting Sept. 19-20, 2012 Milipitas, CA Host: Cisco Draft Agenda ============ (created on 29 August 2012) (updated on 16 September 2012) Wednesday: 08:30-09:00 Coffee/getting settled [Note: breakfast will *not* be served] 09:00-10:00 (chairs) - status - agenda bash - objectives/desired outcomes - ticket #16 10:00-10:30 Data model (Andy, Christer) * Related drafts: - draft-romanow-clue-data-model-01.txt * Discussions: - design team meeting: -- http://www.ietf.org/mail-archive/web/clue/current/msg01895.html (Sept. 4, 2012) - email threads: -- http://www.ietf.org/mail-archive/web/clue/current/msg01836.html * Related issues: - ticket #4 10:30-10:45: Break (with coffee/snack) 10:45-11:45 RTP (Roni, Jonathan) * Related Drafts: - draft-even-clue-rtp-mapping-04.txt * Discussions: - IETF-84 - design team meetings: -- http://www.ietf.org/mail-archive/web/clue/current/msg01806.html (Aug 14, 2012) -- http://www.ietf.org/mail-archive/web/clue/current/msg01837.html (Aug 21, 2012) -- http://www.ietf.org/mail-archive/web/clue/current/msg01873.html (Aug 28, 2012) * Related issues: - ticket #11 11:45-13:00 Lunch 13:00-14:50 Call Flows (Rob, Paul) References: * Drafts: - draft-romanow-clue-call-flow-02 - draft-kyzivat-clue-telemedical-callflow-00.txt * Discussions: - IETF-84 - design team meeting: -- http://www.ietf.org/mail-archive/web/clue/current/msg01916.html(Sept. 11, 2012) - email threads: -- http://www.ietf.org/mail-archive/web/clue/current/msg01905.html 14:50-15:10 Break (coffee/snacks) 15:10-17:00 Signaling (Andy, Rob) * Drafts: - draft-romanow-clue-call-flow-02 - draft-romanow-clue-sdp-usage-02 * Discussions: - IETF-84 - Design team meetings: -- http://www.ietf.org/mail-archive/web/clue/current/msg01916.html(Sept. 11, 2012) * Issues to resolve: - tickets #11,#12,#13,#14,#15 17:00-18:00 Summary and identification of key items to discuss and resolve on Friday 19:30 Dinner @ Macaroni Grill Thursday (details to be added after Wed meeting) 08:30-09:00 Coffee/Plans for the day 09:00-10:30 Issues from Wednesday 10:30-10:45 Break (with coffee/snacks) 10:45-12:30 Issues from Wednesday (continued) 12:30-13:00 Break (with coffee/snacks) 13:00-14:00 Discussion of way forward and summary of action items --f46d04016d9f7b96c104c9d8b823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Below, please find the agenda (I can't upload it to the meeting materia= ls right now as it looks like they're mucking with the server). =A0Also= , we were not able to upload all the design team minutes as there is a bug = somewhere and both Paul and I get permission errors. =A0So, the agenda has = links to the minutes as they were posted to the mailing list as opposed to = the version on the wiki. =A0

Note, that we have assigned "discussion leaders". = =A0The plan is not to review documents per se. =A0But, to focus on issues t= hat have arisen on the mailing list and during design team calls. =A0We als= o have more than enough materials from the IETF-84 meeting for each of the = documents. =A0If you are listed as a leader and are unsure of what we expec= t, please let the chairs know and we can work with you on what we have in m= ind. =A0We do not anticipate lots of slides but rather discussion and focus= ing on issue resolution. =A0Note, that the first part of the meeting, we wi= ll discuss the meeting format and objectives.=A0

Participants are expected to at least have reviewed the= mailing list threads for the current issues and to please review the meeti= ng minutes in cases where you were not able to attend. =A0Some revisiting o= f discussions can be useful, but we don't want to repeat too much.

Thanks,
Mary.

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CLUE WG Interim = Meeting
Sept. 19-20, 2012=A0
Milipitas, CA
Host: Cisco

Draft Agenda
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(created on 29 Augu= st 2012)
(updated on 16 September 2012)

= Wednesday:
=A0 =A008:30-09:00 Coffee/getting settled =A0[Note: breakfast will *not* be= served]

=A0 =A009:00-10:00 (chairs)
=A0= =A0- status
=A0 =A0- agenda bash=A0
=A0 =A0- objective= s/desired outcomes

=A0 =A0- ticket #16
=A0
=A0 =A010:00-10:30 Data mo= del (Andy, Christer)
=A0 =A0* Related drafts:=A0
=A0 = =A0- draft-romanow-clue-data-model-01.txt =A0 =A0

= =A0 =A0* Discussions:

=A0 =A0 - design team meeting: =A0=A0
=A0 =A0 -- http://www= .ietf.org/mail-archive/web/clue/current/msg01895.html =A0(Sept. 4, 2012= )
=A0 =A0 - email threads:=A0
=A0 =A0 -- http://www.ietf.org/mail-= archive/web/clue/current/msg01836.html

=A0 =A0= * Related issues:

=A0 =A0- ticket #4 =A0
=A0 =A0=A0
=A0 =A010:30-10:= 45: Break (with coffee/snack)

=A0 =A010:45-11:45 R= TP (Roni, Jonathan)
=A0 =A0* Related Drafts:
=A0 =A0- d= raft-even-clue-rtp-mapping-04.txt

=A0 =A0
=A0 =A0* Discussions:

=A0 =A0- IETF-84
=A0 =A0- design team meetings: =A0
=A0 =A0-- http://www.i= etf.org/mail-archive/web/clue/current/msg01806.html =A0(Aug 14, 2012)
=A0 =A0-- http://www.ietf.org/mail-archive/web/clue/current/msg01837.= html =A0(Aug 21, 2012)
=A0 =A0-- http://www.ietf.org/mail-ar= chive/web/clue/current/msg01873.html =A0(Aug 28, 2012)

=A0 =A0* Related issues:=A0
=A0 =A0- ticket #= 11=A0

=A0 =A011:45-13:00 Lunch=A0

=A0 =A013:00-14:50 Call Flows (Rob, Paul)
=A0 =A0Referen= ces:=A0
=A0 =A0* Drafts:

=A0 =A0- draft-romanow-clue-call-flow-02
=A0 =A0- draft-kyzi= vat-clue-telemedical-callflow-00.txt
=A0 =A0
=A0 =A0* D= iscussions:
=A0 =A0- IETF-84=A0
=A0 =A0- design team me= eting:=A0
=A0 =A0-- http://www.ietf.org/mail-archive/web/clue/cu= rrent/msg01916.html (Sept. 11, 2012)

=A0 =A0- email threads:=A0
=A0 =A0-- http:/= /www.ietf.org/mail-archive/web/clue/current/msg01905.html

=A0 =A014:50-15:10 Break (coffee/snacks)

=A0 =A015:10-17:00 Signaling (Andy, Rob)
=A0 =A0* Drafts: = =A0
=A0 =A0- draft-romanow-clue-call-flow-02
=A0 =A0- d= raft-romanow-clue-sdp-usage-02 =A0=A0

=A0 =A0* Discussions:
=A0 =A0- IETF-84=A0
=A0 =A0- Design team meetings:
=A0 =A0 -- http://www.ietf= .org/mail-archive/web/clue/current/msg01916.html (Sept. 11, 2012)

=A0 =A0* Issues to resolve:=A0
=A0 =A0- ticke= ts #11,#12,#13,#14,#15
=A0 =A0=A0
=A0 =A017:00-18:00 Su= mmary and identification of key items=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 to discuss and resolve on Friday

=A0 =A0=A0
=A0 =A019:30 =A0Dinner @ Macaroni Grill=A0
<= div>
Thursday (details to be added after Wed meeting)
=A0 =A0 08:30-09:00 Coffee/Plans for the day

= =A0 =A0 09:00-10:30 Issues from Wednesday

=A0 =A0 10:30-10:45 Break (with coffee/snacks)
=A0 =A0=A0
=A0 =A0 10:45-12:30 Issues from Wednesday (continued= )

=A0 =A0 12:30-13:00 Break (with coffee/snacks)

=A0 =A0 13:00-14:00 Discussion of way forward and summary of action it= ems
--f46d04016d9f7b96c104c9d8b823-- From christer.holmberg@ericsson.com Mon Sep 17 01:04:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E364721F845B for ; Mon, 17 Sep 2012 01:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A27zHFNZfYlk for ; Mon, 17 Sep 2012 01:04:45 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 833F721F8459 for ; Mon, 17 Sep 2012 01:04:44 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-56-5056d99b5f63 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.AB.17130.B99D6505; Mon, 17 Sep 2012 10:04:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 17 Sep 2012 10:04:42 +0200 From: Christer Holmberg To: Mary Barnes , Roni Even Date: Mon, 17 Sep 2012 10:04:41 +0200 Thread-Topic: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt Thread-Index: Ac2SxNSy4tPVluObQS+x5zQUQxeSkwB5aVpQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A5EE258@ESESSCMS0356.eemea.ericsson.se> References: <20120910223439.673.38316.idtracker@ietfa.amsl.com> <504E6F1F.1050702@alum.mit.edu> <504F5DE1.2020003@alum.mit.edu> <00b901cd9294$28cea9a0$7a6bfce0$@gmail.com> <505350D9.9070200@alum.mit.edu> <00bd01cd929d$eddff290$c99fd7b0$@gmail.com> <505362C6.2040300@alum.mit.edu> <010c01cd92b0$4d8147f0$e883d7d0$@gmail.com> <505381C4.8080207@alum.mit.edu> <011101cd92c8$79949eb0$6cbddc10$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A5EE258ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvre7sm2EBBvtaBSz2n7rMbPF5/35m i7/tzA7MHjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXxp2ty1gKXq1jqvh/poO5gfFpE1MX IyeHhICJxL8tN9ggbDGJC/fWA9lcHEICpxglTl/pYYFwFjBKfF71jLWLkYODTcBCovufNkiD iECQxJRH+8GamQUkJFZd/MAIYrMIqEpc/H0AbIGwQKLE5wubWCDqkyTe9DazQdhGEkf3fWEB GckrEC5x46g5xKoXLBJb9rWD1XMKBEpcPLEEbA4j0HHfT61hgtglLnHryXyoBwQkluw5zwxh i0q8fPyPFaJeVOJO+3pGkPnMAvkSKz4HgIR5BQQlTs58wjKBUXQWkkmzEKpmIamCKNGRWLD7 ExuErS2xbOFrZhj7zIHHTMjiCxjZVzEK5yZm5qSXm+ulFmUmFxfn5+kVp25iBMbcwS2/DXYw brovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGL7naYsbwVTwCM26W TZyzMV1shmHgd9a0LxveRJwtzF9bvtD+7HzlyTscpkfHr+yMmvj8Z7x89FcnzlU93XLzldSs iiNmGvb2XZm4sl3pS1Vu9v/4VCPOO7fTrkyNOHW6/eqKJP/75V8ehduZnDBXZ1wT9uimR6aM 0JHjHbvWODFLZVjs6ExSYinOSDTUYi4qTgQAjQxkzocCAAA= Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:04:50 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A5EE258ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It is not only about non-CLUE endpoints - it is also about intermediaries. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: 15. syyskuuta 2012 1:04 To: Roni Even Cc: CLUE Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemed= ical-callflow-00.txt This is a really important point. I totally agree that we need to consider= that what CLUE needs or might define at the SDP level should be usable for= non-CLUE endpoints for interoperability. This may put some limitations an= d restrictions on the decisions we make as to what is carried in SDP versus= in CLUE application level signaling. Mary. On Fri, Sep 14, 2012 at 5:29 PM, Roni Even > wrote: Paul, One concern I have is that some of the usages like simulcast are not a CLUE issue but are relevant also for non CLUE solutions. So to resolve this use case we can mandate using CLUE (as a multi stream signaling) or resolve it using SDP. The worst case is if we have two ways to signal without defining the interoperability. I tried to provide in section 4.1 http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 a review of some of the signaling proposal from AVTcore, AVText and MMSUIC that can address some of the scenarios discussed in CLUE in order to have a full picture before deciding to put something in CLUE protocol. I hope that people will look at these documents . Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 14 September, 2012 9:13 PM To: Roni Even Cc: 'Espen Berger (espeberg)'; 'CLUE' Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt On 9/14/12 3:36 PM, Roni Even wrote: > Paul, > Try to analyze it assuming that each resolution is using a different > transport address, so you must use SDP to switch in which case why not > define simulcast in SDP and not in CLUE. This is really into the "what goes where", which is a good discussion to have! I guess what you are describing means that there are two alternate encoding= s available for this capture. They could map to two different m-lines in sdp. But what would cause them both to be listed in the SDP? This can work if the SDP is determined by the advertisement, and covers all possible configurations that might be configured from that advertisement. S= o then, if both are in an SDP offer that corresponds to that advertisement, then the SDP answer can choose which of those to accept. That is in effect doing a configuration, or part of it. For that to work, the advertisement that explains what those mean would have to be sent before the SDP offer, s= o that it would be available to make the decision about what to accept in the answer. And then if later there is a desire to switch to the other resolution, then I guess an SDP offer would be sent in the other direction, changing which o= f the two m-lines has a non-zero port. It sounds like this can be made to work, though the devil is in the details= . It will require a lot of analysis of when advertisements must be sent relative to offers. Based on above, an advertisement MAY/MUST? be followed by an offer. And apparently the offer must be sufficient for an= y configuration of that advertisement. I'm worried that this may require the offerer to consume more resources than are required for most configurations= . Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 14 September, 2012 7:01 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] New Version Notification for > draft-kyzivat-clue-telemedical-callflow-00.txt > > On 9/14/12 1:25 PM, Roni Even wrote: >> Paul, >> I can think of an example for SDP only with no CLUE but it depends >> how simulcast is implemented. A switch from high res to low res of >> the same capture (example room view) without a change in the CLUE >> Roni > > OK. I can sort of see that. Maybe. > > Does this fall into the category of something where there are > alternatives within a single config? > > But I would have thought that the high and low res versions of the > same capture would be represented in clue signaling by advertising two > possible encodings for the same capture, and then configuring the > capture with one or the other. If so, then there would be a config > message associated with the change. > > Thanks, > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 14 September, 2012 5:44 PM >> To: Roni Even >> Cc: 'Espen Berger (espeberg)'; 'CLUE' >> Subject: Re: [clue] New Version Notification for >> draft-kyzivat-clue-telemedical-callflow-00.txt >> >> I agree with this. One comment below. >> >> On 9/14/12 12:15 PM, Roni Even wrote: >>> Hi Paul, >>> Other examples >>> >>> 1. want to add a transport connection when adding a new RTP stream >>> (example opening a presentation stream during the call or changing >>> the presentation >>> stream) will require a re-invite. In general every change in the >>> transport connection whether adding a new one when not SSRC >>> multiplexing or changing the connection (transfer the call or some >>> of the media streams without the CLUE channel) 2. Changing the codec >>> used >>> (H.26 to H.264 or audio codec) may require a re-invite. >>> 3. When an MCU wants to change the common mode of a call when a >>> party is added or dropped. >>> >>> There are more use cases. >>> >>> I see there are two types of requirements for re-invite. >>> >>> The first is during call setup in a point to point and multipoint >>> call where the first invite is used to negotiate CLUE support and >>> address interoperability with non-CLUE systems. After going the >>> negotiation of the CLUE state there will be a need for a re-invite >>> to correlate the CLUE and SDP states. >>> >>> The second during the call is when there is a change in the CLUE >>> state that MAY require a correlation with the SDP state or even just >>> an SDP state change like changing codec or addressing network or >>> application issues that do not change the CLUE state. >> >> I think we don't yet know if there will be anything that makes sense >> to change in SDP without some corresponding change in advertisement >> or > config. >> If there is, it must be something for which there are alternative >> ways to accomplish the configuration. I'm not sure what that might >> be, but in principle I see it could happen. >> >> Thanks, >> Paul >> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf >>> Of Espen Berger (espeberg) >>> Sent: 14 September, 2012 4:36 PM >>> To: Paul Kyzivat >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> My main point is that the initial INVITE can be sufficient for a >>> call with CLUE negotiated media stream. >>> >>> One of the exceptions we have discussed is the requirement to >>> upgrade bandwidth to allow for three camera/screen scenarios, which >>> is typically not something you allocate in the network before you >>> really >> knows it's needed. >>> In this case the re-INVITE is optional and there a clear user story >>> to explain why and when we want to do it. >>> >>> I think necessary, and useful, to write down user stories to explain >>> why a SIP re-INVITE is needed. With user stories it's much easier >>> to discuss how to solve actual problems with protocols. >>> >>> Cheers >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 11. september 2012 17:51 >>> To: Espen Berger (espeberg) >>> Cc: CLUE >>> Subject: Re: [clue] New Version Notification for >>> draft-kyzivat-clue-telemedical-callflow-00.txt >>> >>> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote: >>>> My comments >>>> >>>> * It's natural that the MCU send an empty advertisement when the >>>> classroom >>> dials in as the first participant. If not, the classroom does not >>> now if the conference is empty. The configuration message can be >>> delayed, since you are mainly indicating that you do not want to receiv= e media. >>> >>> That is a good idea. I'll do it. >>> >>>> * I think the MCU can delay its initial configure message until the >>> classroom and surgery has done the configure message. With only two >>> participant in the conference, you do not have to configure each >>> endpoint to send media until the MCU knows someone request the media >>> and also know the media restrictions. >>>> >>>> * What is the purpose for the second INVITE from the classroom, >>>> where the >>> text says 'to cover both configurations'. The initial SIP INVITE can >>> be sufficient for payload numbers, bw, codec-parameters. Based on >>> the draft-romanow-clue-call-flow document the main example for a >>> re-invite is to increase or decrease bandwidth allocation. >>> >>> I assumed a consistent approach to first invites - that they are >>> vanilla and minimal, and so aren't sufficient to support the actual >>> CLUE >> call. >>> >>> I have assumed that the invite with o/a to get things *right* is >>> done >>> *after* the Configure messages have been exchanged, when the needs >>> are fully known. There is a chance for glare here - with both sides >>> trying to initiate the o/a. I assumed for this flow that this >>> doesn't happen >>> - either one side waits for the other to go first, or else the >>> timing results in one side sending first and that this then causes >>> the other side to omit its own attempt because it is no longer needed. >>> >>> Because the two sides make independent choices of what to receive, >>> and these may not be symmetric, it is necessary to consider both >>> configurations to decide what to offer. Or else, one side sends an >>> offer sufficient for itself, and then the other side may have to >>> both answer and then make a new offer to add things it needs. >>> >>> This needs more discussion. I didn't sense any consensus or even >>> common understanding of the issues and tradeoffs. >>> >>>> * The expert endpoints does not send a Configure message to the MCU. >>>> Is >>> this intentional or not? >>> >>> I'm having trouble remembering what I was thinking. :-) I think the >>> note "Defer config till get request" is a mistake, and the expert >>> should go ahead and send a Configure. I'll fix it. >>> >>> Thanks, >>> Paul >>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue= -bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: 11. september 2012 00:52 >>>> To: CLUE >>>> Subject: Re: [clue] New Version Notification for >>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>> >>>> I just submitted in initial version of a new callflow draft. >>>> A more useful link for it is: >>>> >>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal >>>> l >>>> f >>>> l >>>> ow/ >>>> >>>> This is complementary to draft-romanow-clue-call-flow. >>>> >>>> I've focused on a particular use case rather than a generic one. >>>> I've >>> chosen the telemedical use case, and a special case of that use case. >>>> Some of the interesting things about this case are that it includes >>>> an MCU, and more than two endpoints. And those endpoints are not >>>> all identical. (The latter point won't have obvious impact until >>>> more detail is filled in.) >>>> >>>> And for now I've considered only the ladder diagram of sip and clue >>> messages. That leaves a lot out. I expect it to be expanded to >>> include the content of those messages. But before getting to that >>> there are already a bunch of issues to sort out, that will impact >>> what goes in those >> messages. >>>> >>>> I don't have any illusions that this version is "correct". It is >>>> just a >>> starting point to discuss the issues. So please send comments. Maybe >>> we will have time to talk about it at tomorrow's design team >>> meeting, and/or at the interim next week. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 9/10/12 6:34 PM, internet-drafts@ietf.org wrote: >>>>> >>>>> A new version of I-D, >>>>> draft-kyzivat-clue-telemedical-callflow-00.txt >>>>> has been successfully submitted by Paul H. Kyzivat and posted to >>>>> the IETF repository. >>>>> >>>>> Filename: draft-kyzivat-clue-telemedical-callflow >>>>> Revision: 00 >>>>> Title: CLUE Telemedical Use Case Callflow >>>>> Creation date: 2012-09-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 8 >>>>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c >>> a >>> l >>> lflow- >>> 00.txt >>>>> Status: >>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf >>> l >>> o >>> w >>>>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-0 >>> 0 >>>>> >>>>> >>>>> Abstract: >>>>> This is the beginning of an example call flow for an >>>>> instantiation >>> of >>>>> the use case described in the telemedical use case >>>>> [I-D.xiao-clue-telemedical-use-case]. More detail will be added >>>>> later. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7F2072F1E0DE894DA4B517B93C6A0585340A5EE258ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

It is not only about non-CLUE endpoints – it= is also about intermediaries.

Regards,<= /o:p>

Christer

From: clue-bounces@i= etf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
<= b>Sent: 15. syyskuuta 2012 1:04
To: Roni Even
Cc: C= LUE
Subject: Re: [clue] New Version Notification for draft-kyziva= t-clue-telemedical-callflow-00.txt

This is a really important poin= t. I totally agree that we need to consider that what CLUE needs or m= ight define at the SDP level should be usable for non-CLUE endpoints for in= teroperability. This may put some limitations and restrictions on the= decisions we make as to what is carried in SDP versus in CLUE application = level signaling.

<= /p>

Mary.&nbs= p;

On Fri, Sep 14, 2012 at 5:29 PM,= Roni Even <= ron.even.tlv@gmail.com> wrote:

Pa= ul,
One concern I have is that some of the usages like simulcast are not= a CLUE
issue but are relevant also for non CLUE solutions. So to resolv= e this use
case we can mandate using CLUE (as a multi stream signaling) = or resolve it
using SDP. The worst case is if we have two ways to signal= without defining
the interoperability.

I tried to provide in sec= tion 4.1
http://tools.ietf.org/html/draft-even-clue-rtp-map= ping-04 a review of some
of the signaling proposal from AVTcore, AVT= ext and MMSUIC that can address
some of the scenarios discussed in CLUE = in order to have a full picture
before deciding to put something in CLUE= protocol.

I hope that people will look at these documents .

Roni

-----Original Message-----=
From: Paul Kyzivat [mailto:pky= zivat@alum.mit.edu]

= Sent: 14 September, 2012 9:13 PM
To: Roni Even
Cc: 'Espen Berger (esp= eberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for
draf= t-kyzivat-clue-telemedical-callflow-00.txt

On 9/14/12 3:36 PM, Roni = Even wrote:
> Paul,
> Try to analyze it assuming that each reso= lution is using a different
> transport address, so you must use SDP = to switch in which case why not
> define simulcast in SDP and not in = CLUE.

This is really into the "what goes where", which is = a good discussion to
have!

I guess what you are describing means = that there are two alternate encodings
available for this capture. They = could map to two different m-lines in sdp.
But what would cause them bot= h to be listed in the SDP?

This can work if the SDP is determined by= the advertisement, and covers all
possible configurations that might be= configured from that advertisement. So
then, if both are in an SDP offe= r that corresponds to that advertisement,
then the SDP answer can choose= which of those to accept. That is in effect
doing a configuration, or p= art of it. For that to work, the advertisement
that explains what those = mean would have to be sent before the SDP offer, so
that it would be ava= ilable to make the decision about what to accept in the
answer.

A= nd then if later there is a desire to switch to the other resolution, then<= br>I guess an SDP offer would be sent in the other direction, changing whic= h of
the two m-lines has a non-zero port.

It sounds like this can= be made to work, though the devil is in the details.
It will require a = lot of analysis of when advertisements must be sent
relative to offers. = Based on above, an advertisement MAY/MUST?
be followed by an offer. And = apparently the offer must be sufficient for any
configuration of that ad= vertisement. I'm worried that this may require the
offerer to consume mo= re resources than are required for most configurations.

= ; Thanks,
Paul

> Ron= i
>
> -----Original Message-----
> From: Paul Kyzivat [ma= ilto:pkyzivat@alum.mit.edu]> Sent: 14 September, 2012 7:01 PM
> To: Roni Even
> Cc: 'E= spen Berger (espeberg)'; 'CLUE'
> Subject: Re: [clue] New Version Not= ification for
> draft-kyzivat-clue-telemedical-callflow-00.txt
>= ;
> On 9/14/12 1:25 PM, Roni Even wrote:
>> Paul,
>>= ; I can think of an example for SDP only with no CLUE but it depends
>= ;> how simulcast is implemented. A switch from high res to low res of>> the same capture (example room view) without a change in the CLUE=
>> Roni
>
> OK. I can sort of see that. Maybe.
>= ;
> Does this fall into the category of something where there are
= > alternatives within a single config?
>
> But I would have = thought that the high and low res versions of the
> same capture woul= d be represented in clue signaling by advertising two
> possible enco= dings for the same capture, and then configuring the
> capture with o= ne or the other. If so, then there would be a config
> message associ= ated with the change.
>
> Thanks,
> = Paul
>
>> -----Original Message----->> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 14 September, 2012 5:44 PM<= br>>> To: Roni Even
>> Cc: 'Espen Berger (espeberg)'; 'CLUE'=
>> Subject: Re: [clue] New Version Notification for
>> d= raft-kyzivat-clue-telemedical-callflow-00.txt
>>
>> I agr= ee with this. One comment below.
>>
>> On 9/14/12 12:15 P= M, Roni Even wrote:
>>> Hi Paul,
>>> Other examples=
>>>
>>> 1. want to add a transport connection when= adding a new RTP stream
>>> (example opening a presentation st= ream during the call or changing
>>> the presentation
>&g= t;> stream) will require a re-invite. In general every change in t= he
>>> transport connection whether adding a new one when not S= SRC
>>> multiplexing or changing the connection (transfer the c= all or some
>>> of the media streams without the CLUE channel) = 2. Changing the codec
>>> used
>>> (H.26 to H.264 o= r audio codec) may require a re-invite.
>>> 3. When an MCU want= s to change the common mode of a call when a
>>> party is added= or dropped.
>>>
>>> There are more use cases.
&= gt;>>
>>> I see there are two types of requirements for r= e-invite.
>>>
>>> The first is during call setup in= a point to point and multipoint
>>> call where the first invit= e is used to negotiate CLUE support and
>>> address interoperab= ility with non-CLUE systems. After going the
>>> negotiation of= the CLUE state there will be a need for a re-invite
>>> to cor= relate the CLUE and SDP states.
>>>
>>> The second = during the call is when there is a change in the CLUE
>>> state= that MAY require a correlation with the SDP state or even just
>>= > an SDP state change like changing codec or addressing network or
&g= t;>> application issues that do not change the CLUE state.
>>= ;
>> I think we don't yet know if there will be anything that make= s sense
>> to change in SDP without some corresponding change in a= dvertisement
>> or
> config.
>> If there is, it mus= t be something for which there are alternative
>> ways to accompli= sh the configuration. I'm not sure what that might
>> be, but in p= rinciple I see it could happen.
>>
>> = ;Thanks,
>> Paul
>>
>>> R= oni
>>>
>>> -----Original Message-----
>>&= gt; From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>>> Of Espen Berger (espeberg)
>>> Sen= t: 14 September, 2012 4:36 PM
>>> To: Paul Kyzivat
>>&= gt; Cc: CLUE
>>> Subject: Re: [clue] New Version Notification f= or
>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>&g= t;>
>>> My main point is that the initial INVITE can be suff= icient for a
>>> call with CLUE negotiated media stream.
>= ;>>
>>> One of the exceptions we have discussed is the re= quirement to
>>> upgrade bandwidth to allow for three camera/sc= reen scenarios, which
>>> is typically not something you alloca= te in the network before you
>>> really
>> knows it's = needed.
>>> In this case the re-INVITE is optional and there a = clear user story
>>> to explain why and when we want to do it.<= br>>>>
>>> I think necessary, and useful, to write dow= n user stories to explain
>>> why a SIP re-INVITE is needed. &n= bsp;With user stories it's much easier
>>> to discuss how to so= lve actual problems with protocols.
>>>
>>> Cheers<= br>>>>
>>> -Espen
>>>
>>>
&= gt;>> -----Original Message-----
>>> From: Paul Kyzivat [= mailto:pkyzivat@alum.mit.edu]<= br>>>> Sent: 11. september 2012 17:51
>>> To: Espen Be= rger (espeberg)
>>> Cc: CLUE
>>> Subject: Re: [clue= ] New Version Notification for
>>> draft-kyzivat-clue-telemedic= al-callflow-00.txt
>>>
>>> On 9/11/12 9:56 AM, Espe= n Berger (espeberg) wrote:
>>>> My comments
>>>&= gt;
>>>> * It's natural that the MCU send an empty advertise= ment when the
>>>> classroom
>>> dials in as the= first participant. If not, the classroom does not
>>> now if t= he conference is empty. The configuration message can be
>>> de= layed, since you are mainly indicating that you do not want to receive
m= edia.
>>>
>>> That is a good idea. I'll do it.
&= gt;>>
>>>> * I think the MCU can delay its initial con= figure message until the
>>> classroom and surgery has done the= configure message. With only two
>>> participant in the confer= ence, you do not have to configure each
>>> endpoint to send me= dia until the MCU knows someone request the media
>>> and also = know the media restrictions.
>>>>
>>>> * What= is the purpose for the second INVITE from the classroom,
>>>&g= t; where the
>>> text says 'to cover both configurations'. The = initial SIP INVITE can
>>> be sufficient for payload numbers, b= w, codec-parameters. Based on
>>> the draft-romanow-clue-call-f= low document the main example for a
>>> re-invite is to increas= e or decrease bandwidth allocation.
>>>
>>> I assum= ed a consistent approach to first invites - that they are
>>> v= anilla and minimal, and so aren't sufficient to support the actual
>&= gt;> CLUE
>> call.
>>>
>>> I have assum= ed that the invite with o/a to get things *right* is
>>> done>>> *after* the Configure messages have been exchanged, when the= needs
>>> are fully known. There is a chance for glare here - = with both sides
>>> trying to initiate the o/a. I assumed for t= his flow that this
>>> doesn't happen
>>> - either = one side waits for the other to go first, or else the
>>> timin= g results in one side sending first and that this then causes
>>&g= t; the other side to omit its own attempt because it is no longer needed.>>>
>>> Because the two sides make independent choic= es of what to receive,
>>> and these may not be symmetric, it i= s necessary to consider both
>>> configurations to decide what = to offer. Or else, one side sends an
>>> offer sufficient for i= tself, and then the other side may have to
>>> both answer and = then make a new offer to add things it needs.
>>>
>>&g= t; This needs more discussion. I didn't sense any consensus or even
>= >> common understanding of the issues and tradeoffs.
>>><= br>>>>> * The expert endpoints does not send a Configure messag= e to the MCU.
>>>> Is
>>> this intentional or no= t?
>>>
>>> I'm having trouble remembering what I wa= s thinking. :-) I think the
>>> note "Defer config till ge= t request" is a mistake, and the expert
>>> should go ahea= d and send a Configure. I'll fix it.
>>>
>>> = Thanks,
>>> Paul
>>>
>&= gt;>> Cheers
>>>>
>>>> -Espen
>&g= t;>>
>>>> -----Original Message-----
>>>&g= t; From: clue-bounces@ietf.org= [mailto:clue-bounces@ietf.org= ] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: 1= 1. september 2012 00:52
>>>> To: CLUE
>>>> Su= bject: Re: [clue] New Version Notification for
>>>> draft-ky= zivat-clue-telemedical-callflow-00.txt
>>>>
>>>&= gt; I just submitted in initial version of a new callflow draft.
>>= ;>> A more useful link for it is:
>>>>
>>>= > https://datatracker.ietf.org/doc/draft-kyzivat-= clue-telemedical-cal
>>>> l
>>>> f
>= ;>>> l
>>>> ow/
>>>>
>>>= > This is complementary to draft-romanow-clue-call-flow.
>>>= >
>>>> I've focused on a particular use case rather than = a generic one.
>>>> I've
>>> chosen the telemedi= cal use case, and a special case of that use case.
>>>> Some= of the interesting things about this case are that it includes
>>= >> an MCU, and more than two endpoints. And those endpoints are not>>>> all identical. (The latter point won't have obvious impa= ct until
>>>> more detail is filled in.)
>>>>=
>>>> And for now I've considered only the ladder diagram of= sip and clue
>>> messages. That leaves a lot out. I expect it = to be expanded to
>>> include the content of those messages. Bu= t before getting to that
>>> there are already a bunch of issue= s to sort out, that will impact
>>> what goes in those
>&= gt; messages.
>>>>
>>>> I don't have any illu= sions that this version is "correct". It is
>>>> j= ust a
>>> starting point to discuss the issues. So please send = comments. Maybe
>>> we will have time to talk about it at tomor= row's design team
>>> meeting, and/or at the interim next week.=
>>>>
>>>> Thanks,
>>&g= t;> Paul
>>>>
>>>> On 9/10/12= 6:34 PM, internet-drafts@ietf.= org wrote:
>>>>>
>>>>> A new versio= n of I-D,
>>>>> draft-kyzivat-clue-telemedical-callflow-0= 0.txt
>>>>> has been successfully submitted by Paul H. Ky= zivat and posted to
>>>>> the IETF repository.
>>= ;>>>
>>>>> Filename: draft-kyzivat-clue-te= lemedical-callflow
>>>>> Revision: 00
>>&g= t;>> Title: CLUE Telemedica= l Use Case Callflow
>>>>> Creation date: 20= 12-09-11
>>>>> WG ID: = Individual Submission
>>>>> Number of pages: 8
= >>>>> URL:
>>> http://ww= w.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-c
>>= > a
>>> l
>>> lflow-
>>> 00.txt
&= gt;>>>> Status:

>>> http://datatracker.ietf.org/doc/d= raft-kyzivat-clue-telemedical-callf
>>> l
>>> o=
>>> w
>>>>> Htmlized:
>>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical= -callflow-0
>>> 0
>>>>>
>>>&g= t;>

>>>>&= gt; Abstract:
>>>>> This is t= he beginning of an example call flow for an
>>>>> instant= iation
>>> of
>>>>> &nbs= p; the use case described in the telemedical use case
>>>>&g= t; [I-D.xiao-clue-telemedical-use-case]. = More detail will be
added
>>>>> &= nbsp; later.
>>>>>
>>>>>
>>>= ;>>
>>>>>
>>>>> The IETF Secretar= iat
>>>>>
>>>>>
>>>>
= >>>> _______________________________________________
>>= ;>> clue mailing list
>>>> clue@ietf.org
>>>> https://www.ietf.org/mailman/list= info/clue
>>>>
>>>
>>> _________= ______________________________________
>>> clue mailing list>>> clue@ietf.org
>>= ;> https://www.ietf.org/mailman/listinfo/clue
>>>
>&= gt;>
>>
>>
>
>

____________________= ___________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue=

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A5EE258ESESSCMS0356e_-- From mary.ietf.barnes@gmail.com Mon Sep 17 10:32:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3521F8679 for ; Mon, 17 Sep 2012 10:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=0.273, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWnw1vWzJozy for ; Mon, 17 Sep 2012 10:32:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07A21F8678 for ; Mon, 17 Sep 2012 10:32:34 -0700 (PDT) Received: by lahm15 with SMTP id m15so4661016lah.31 for ; Mon, 17 Sep 2012 10:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=s6jnpyCn9pAIwT8KQu+yHlEAAN/dcw3AGciHdoJ7nK8=; b=thlWlq4U6qM7dMJg4N29ct/+E8k9jguC85fVLbCUYPic1tSM7e1+iAMruHT4NeucOJ jjmsKs9QeLgMfXUI0Rka3Tm83J5Y/mJC2vLoaE0yYycMwk253cRAn6rew57RQWXLJzy5 3svSYhVhovx1WMaT2XiDFqbTY1Fqp9bG14k3rDMFCVdoMdv9a8nI52JKz8jKD68gANWb 6H6156Y4zyv1K2E2/t9Am4DBhBfTIy8ISE5Q1mvI2c9r/sD3Zs24P7HtE4MXRiYVH6F7 sO9yNeNMruou/dpFcJK0A5v9y5MDHxEZXD8sCACO/oLrh9sgeIT4x9meFktg3zGmvvn8 3oRg== MIME-Version: 1.0 Received: by 10.112.26.106 with SMTP id k10mr4158835lbg.100.1347903152931; Mon, 17 Sep 2012 10:32:32 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Mon, 17 Sep 2012 10:32:32 -0700 (PDT) Date: Mon, 17 Sep 2012 12:32:32 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec554dbbe9f435c04c9e928b4 Subject: [clue] No Design Team Call tomorrow (Sept. 18) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:32:35 -0000 --bcaec554dbbe9f435c04c9e928b4 Content-Type: text/plain; charset=ISO-8859-1 As noted on last week's call, there will be no call tomorrow since many of us will be en route to the interim tomorrow. Mary. --bcaec554dbbe9f435c04c9e928b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As noted on last week's call, there will be no call tomorrow since many= of us will be en route to the interim tomorrow.=A0

Mary= .=A0
--bcaec554dbbe9f435c04c9e928b4-- From gonzalo.camarillo@ericsson.com Tue Sep 18 04:31:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE15921F87D5 for ; Tue, 18 Sep 2012 04:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n2455hXAXYJ for ; Tue, 18 Sep 2012 04:31:56 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 880F421F879B for ; Tue, 18 Sep 2012 04:31:55 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-b9-50585baa4608 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.D6.25676.AAB58505; Tue, 18 Sep 2012 13:31:54 +0200 (CEST) Received: from [131.160.36.73] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Tue, 18 Sep 2012 13:31:53 +0200 Message-ID: <50585BA9.70006@ericsson.com> Date: Tue, 18 Sep 2012 14:31:53 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvre6q6IgAg8Mn5Sz2n7rMbPF5/35m ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgymhcsoOpYClPxfdf19ka GO9wdjFycEgImEjMXyfXxcgJZIpJXLi3nq2LkYtDSOAUo8T7De+YIJzVjBKtN9awglTxCmhK nLn2lBHEZhFQlVgz5RMLiM0mYCGx5dZ9MFtUIFji3MZtbBD1ghInZz4Bi4sI6Eh8+/wWLM4s YCfRdm8X2ExhAXuJia8/gcWFBAIkDn5cAVbPKRAo8fvpe1aI6yQl3ky+yQLRqycx5WoLI4Qt L7H97RxmiF5tieXPWlgmMArNQrJ6FpKWWUhaFjAyr2IUzk3MzEkvN9JLLcpMLi7Oz9MrTt3E CAzrg1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYWZc+ unFl18z/Oq8PXJy05b5sYbbA2uZHvy/bdXWvMDbznfL7f3G8XPINd68f/dtKtm9Wbnjr7W4k k/z1SOK/5kN5p93sdikXbTHvDJnLVF3Kkmm4UPeywZE/QS/YD+h+leZ5+7tk1mY1v7rXgTuN 9r59IGwimjF1pmFmyLOwZNV0EY4XLx7zKLEUZyQaajEXFScCAPjZeRo5AgAA Cc: CLUE Subject: Re: [clue] CLUE WG Interim meeting - Details and Draft agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:31:56 -0000 Hi, if you could include the list of relevant documents (i.e., documents people following the interim should have read) in the wiki/agenda, that would be useful for people who are not so involved in the WG to prepare for the interim. Thanks, Gonzalo On 31/08/2012 8:24 PM, Mary Barnes wrote: > Hi all, > > I have updated the wiki with information for the Interim Meeting Sept. > 19-20, 2012: > http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > > There is a draft agenda which will be populated to point to documents > that are submitted, as well as relevant email threads before the > meeting. Please note the deadlines are as follows: > > * Request Agenda time: Wednesday, Sept. 12, 2012 (5pm Pacific) > * Draft Deadline: Wednesday, Sept. 12, 2012 (5pm Pacific) > * Revised agenda: Thursday, Sept. 13, 2012 (5pm Pacific) > * Presentation deadline: Friday, Sept. 14, 2012 (5pm Pacific) > * Final agenda (day 1): Monday, Sept. 17, 2012 (noon Pacific) > * Final agenda (day 2): Wednesday,Sept. 19, 2012 (10pm Pacific) > > Note, that I will organize a (un-hosted) group dinner at Macaroni Grill > for the 19th, so please respond to the doodle if you would like to attend: > http://www.doodle.com/nar2u3783xsxaxk7 > > Also, if you did not respond to the original doodle and will attend, > please fill out the doodle: > http://www.doodle.com/uzb9nf2h92dqfp5i > > If you will be attending remotely, please let us know. We will schedule > a Webex and post those details shortly. > > Regards, > Mary. From mary.ietf.barnes@gmail.com Tue Sep 18 04:37:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2821F8698 for ; Tue, 18 Sep 2012 04:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.334 X-Spam-Level: X-Spam-Status: No, score=-103.334 tagged_above=-999 required=5 tests=[AWL=0.264, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGNJPxeAMbxS for ; Tue, 18 Sep 2012 04:37:51 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0977021F8687 for ; Tue, 18 Sep 2012 04:37:50 -0700 (PDT) Received: by oagk14 with SMTP id k14so6608779oag.31 for ; Tue, 18 Sep 2012 04:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LKaG0hafpj4PCGemNLboA8DQt4YD++yF1iT9x/AcjyI=; b=ZywMBwVfIo0bvZSl+yxM6uYbJ90e62kOXB6LDwjXMQcjzVBPqw+xX4Mf3888LNIWw4 ZSz1StgRPgJ+MzNzpVEz8Mm1MpFCUrLs8zFiqykmkZI1kOHH47ogCPYzTbPplyJDl2WZ ZBG5+Z0fxmdzwKN0w78EIF/iAMans4woKD/WlBQ3thOJlB5yCgknL6+dsvAeh6xGxnJr 9NSQL1iQuqqitgTs2VZM29IWV/BvrJAIolLiTY5IUnavyMJOaM7m8Cofs90Nj+jpJrMH ytp85Yr9V5JoKHqrHxEibUsKsmscQ9ung0w8TfgO5bQGhD5I2jpLBozJN/RbjaxO38KT zCLg== MIME-Version: 1.0 Received: by 10.182.118.2 with SMTP id ki2mr14728310obb.101.1347968270513; Tue, 18 Sep 2012 04:37:50 -0700 (PDT) Received: by 10.60.162.71 with HTTP; Tue, 18 Sep 2012 04:37:50 -0700 (PDT) In-Reply-To: <50585BA9.70006@ericsson.com> References: <50585BA9.70006@ericsson.com> Date: Tue, 18 Sep 2012 06:37:50 -0500 Message-ID: From: Mary Barnes To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=f46d0447f37ceeb5e104c9f851c2 Cc: CLUE Subject: Re: [clue] CLUE WG Interim meeting - Details and Draft agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:37:52 -0000 --f46d0447f37ceeb5e104c9f851c2 Content-Type: text/plain; charset=ISO-8859-1 The more detailed agenda is uploaded in the meeting materials manager and there's a link to that from the wiki. It's probably better if I just delete the drafty one on the wiki. Note, that you may have to refresh your browser to see the updated agenda in the meeting materials manager. Mary. On Tue, Sep 18, 2012 at 6:31 AM, Gonzalo Camarillo < Gonzalo.Camarillo@ericsson.com> wrote: > Hi, > > if you could include the list of relevant documents (i.e., documents > people following the interim should have read) in the wiki/agenda, that > would be useful for people who are not so involved in the WG to prepare > for the interim. > > Thanks, > > Gonzalo > > On 31/08/2012 8:24 PM, Mary Barnes wrote: > > Hi all, > > > > I have updated the wiki with information for the Interim Meeting Sept. > > 19-20, 2012: > > http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > > > > There is a draft agenda which will be populated to point to documents > > that are submitted, as well as relevant email threads before the > > meeting. Please note the deadlines are as follows: > > > > * Request Agenda time: Wednesday, Sept. 12, 2012 (5pm Pacific) > > * Draft Deadline: Wednesday, Sept. 12, 2012 (5pm Pacific) > > * Revised agenda: Thursday, Sept. 13, 2012 (5pm Pacific) > > * Presentation deadline: Friday, Sept. 14, 2012 (5pm Pacific) > > * Final agenda (day 1): Monday, Sept. 17, 2012 (noon Pacific) > > * Final agenda (day 2): Wednesday,Sept. 19, 2012 (10pm Pacific) > > > > Note, that I will organize a (un-hosted) group dinner at Macaroni Grill > > for the 19th, so please respond to the doodle if you would like to > attend: > > http://www.doodle.com/nar2u3783xsxaxk7 > > > > Also, if you did not respond to the original doodle and will attend, > > please fill out the doodle: > > http://www.doodle.com/uzb9nf2h92dqfp5i > > > > If you will be attending remotely, please let us know. We will schedule > > a Webex and post those details shortly. > > > > Regards, > > Mary. > > --f46d0447f37ceeb5e104c9f851c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The more detailed agenda is uploaded in the meeting materials manager and t= here's a link to that from the wiki. =A0It's probably better if I j= ust delete the drafty one on the wiki. =A0 Note, that you may have to refre= sh your browser to see the updated agenda in the meeting materials manager.= =A0

Mary.=A0

On Tue, Sep 18, 2= 012 at 6:31 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson= .com> wrote:

Hi,

if you could include the list of relevant documents (i.e., documents
people following the interim should have read) in the wiki/agenda, that
would be useful for people who are not so involved in the WG to prepare
for the interim.

Thanks,

Gonzalo

On 31/08/2012 8:24 PM, Mary Barnes wrote:
> Hi all,
>
> I have updated the wiki with information for the Interim Meeting Sept.=
> 19-20, 2012:
> http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart >
> There is a draft agenda which will be populated to point to documents<= br> > that are submitted, as well as relevant email threads before the
> meeting. =A0Please note the deadlines are as follows:
>

> =A0 * Request Agenda time: Wednesday, Sept. 12, 2012 (5pm Pacifi= c)
> =A0 * Draft Deadline: Wednesday, Sept. 12, 2012 (5pm Pacific)
> =A0 * Revised agenda: Thursday, Sept. 13, 2012 (5pm Pacific)
> =A0 * Presentation deadline: Friday, Sept. 14, 2012 (5pm Pacific)
> =A0 * Final agenda (day 1): Monday, Sept. 17, 2012 (noon Pacific)
> =A0 * Final agenda (day 2): Wednesday,Sept. 19, 2012 (10pm Pacific)
>
> Note, that I will organize a (un-hosted) group dinner at Macaroni Gril= l
> for the 19th, so please respond to the doodle if you would like to att= end:
> h= ttp://www.doodle.com/nar2u3783xsxaxk7
>
> Also, if you did not respond to the original doodle and will attend, > please fill out the doodle:
> h= ttp://www.doodle.com/uzb9nf2h92dqfp5i
>
> If you will be attending remotely, please let us know. =A0We will sche= dule
> a Webex and post those details shortly.
>
> Regards,
> Mary.

--f46d0447f37ceeb5e104c9f851c2-- From gonzalo.camarillo@ericsson.com Tue Sep 18 04:41:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5021E80BB for ; Tue, 18 Sep 2012 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.232 X-Spam-Level: X-Spam-Status: No, score=-106.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2OB95cZ7HcI for ; Tue, 18 Sep 2012 04:41:57 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CAB4921E80A7 for ; Tue, 18 Sep 2012 04:41:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-58-50585e03b088 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 86.2C.11467.30E58505; Tue, 18 Sep 2012 13:41:55 +0200 (CEST) Received: from [131.160.36.73] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Tue, 18 Sep 2012 13:41:55 +0200 Message-ID: <50585E02.6080007@ericsson.com> Date: Tue, 18 Sep 2012 14:41:54 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mary Barnes References: <50585BA9.70006@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvrS5zXESAwedNGhb7T11mtvi8fz+z xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcz+e4qpoJ2x4u+VOYwN jAldjJwcEgImEjcnnGOBsMUkLtxbz9bFyMUhJHCKUeLNw33MEM5qRomnP7qYQap4BbQljvf1 AdkcHCwCqhJrfniBhNkELCS23LoPNkhUIFji3MZtbBDlghInZz4Bi4sI6Eh8+/wWLM4sYCfR dm8XK4gtLGAvMfH1J6jFmxkl2mfvA9vFKRAo8fvAdEaI6yQl3ky+yQLRrCcx5WoLI4QtL7H9 7RyweiGg25Y/a2GZwCg0C8nuWUhaZiFpWcDIvIpRODcxMye93FAvtSgzubg4P0+vOHUTIzCs D275rbuD8dQ5kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw+jWeydyb qW++eNWfAHOPR48P9+gmsCes/NuxYULXw+jsY9zf+joSd/OIdyvEnDx5nfdAX4puk0yJ8MYM zSy1CU45SxgbLtw+oX17rsyFZ96Xlh0K/GeRFfU2/ML2levrJ++z0szcuNX4ZFlKw9o720yS /BKfqt+Kd5jPcrNh+1OWdNfQGTnySizFGYmGWsxFxYkAjKXsOjkCAAA= Cc: CLUE Subject: Re: [clue] CLUE WG Interim meeting - Details and Draft agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:41:57 -0000 Hi Mary, > It's probably better if I just delete the drafty one on the wiki. yes, that would be great. Thanks, Gonzalo From mary.ietf.barnes@gmail.com Wed Sep 19 19:14:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D611E80A2 for ; Wed, 19 Sep 2012 19:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n93deCQ6XbBQ for ; Wed, 19 Sep 2012 19:14:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0BD521E8048 for ; Wed, 19 Sep 2012 19:14:23 -0700 (PDT) Received: by lboj14 with SMTP id j14so1396703lbo.31 for ; Wed, 19 Sep 2012 19:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JXVDmGC9IsxCvWVXJ8BQ6dmeAfm/x+pPGrVJQY+/x8k=; b=uGtz/Qm5XDGm7RRfLezh2K4JDWL7nJs0s5+vUa/ZjN03TQiK2hDzEualTd6Y6nlplD UCv+LFKwtXW71cBZidfWUUEVk51lie8ob1snXivhumSvulNqoqkllFJS5wVLxUvudQYJ 4+g17zWWHn8Aqv2lTUVBkrWVYRkQfZD+piECn4CRK5apYI24BlirPzpnAfPrS0CJawrS MIs4d1KeBvyReViJpvb4Lm51BXWrTfIQDVhKRITdS3ZlHP/n8gU/tmu/pE5sgBBh2Mxv qSOw86pa8m7XW1f14oCpscqxiHwQSznHFSScpj8w4a3Xmg4WrSpX9spghd646l7X07c7 yngQ== MIME-Version: 1.0 Received: by 10.112.51.201 with SMTP id m9mr185847lbo.2.1348107262659; Wed, 19 Sep 2012 19:14:22 -0700 (PDT) Received: by 10.114.0.199 with HTTP; Wed, 19 Sep 2012 19:14:22 -0700 (PDT) Date: Wed, 19 Sep 2012 21:14:22 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0401678b828db504ca18ae47 Subject: [clue] Recordings from today's Interim Meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 02:14:24 -0000 --f46d0401678b828db504ca18ae47 Content-Type: text/plain; charset=ISO-8859-1 Just in case anyone wants to relive today, the recordings are available here: - Streaming: https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=8311957&rKey=01cb3a68a6ab26ec - Download: https://ietf.webex.com/ietf/lsr.php?AT=dw&SP=MC&rID=8311957&rKey=f34973ea517e24da I'm still trying to tease out the list of issues from my notes (which I'm transcribing from my handwritten notes, so any typed notes anyone might have would be useful at this juncture). Thanks, Mary. --f46d0401678b828db504ca18ae47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just in case anyone wants to relive today, the recordings are available her= e:
- Streaming:
h= ttps://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DMC&rID=3D8311957&am= p;rKey=3D01cb3a68a6ab26ec

- Download:
https://i= etf.webex.com/ietf/lsr.php?AT=3Ddw&SP=3DMC&rID=3D8311957&rKey= =3Df34973ea517e24da

I'm still trying to tease out the list of iss= ues from my notes (which I'm transcribing from my handwritten notes, so= any typed notes anyone might have would be useful at this juncture). =A0

Thanks,
Mary.=A0
--f46d0401678b828db504ca18ae47-- From pkyzivat@alum.mit.edu Thu Sep 20 01:01:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984321F86DF for ; Thu, 20 Sep 2012 01:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax+RGc5gFrWj for ; Thu, 20 Sep 2012 01:01:26 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6421F86F1 for ; Thu, 20 Sep 2012 01:01:25 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id 1KzD1k0011YDfWL55L1V7Q; Thu, 20 Sep 2012 08:01:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([64.134.225.153]) by omta20.westchester.pa.mail.comcast.net with comcast id 1Kvb1k00L3KCHDc3gKvgTn; Thu, 20 Sep 2012 07:55:51 +0000 Message-ID: <505ACC14.3070008@alum.mit.edu> Date: Thu, 20 Sep 2012 03:56:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] my homework on telemedical callflows X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:01:26 -0000 An updated callflow doc can be found at http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-01 As it happens, an MCU case doesn't demonstrate some of the things we were focusing on today. But it is what it is. Thanks, Paul From mary.ietf.barnes@gmail.com Thu Sep 20 16:39:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC611E80A2 for ; Thu, 20 Sep 2012 16:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=0.255, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frYgmy-QCrz9 for ; Thu, 20 Sep 2012 16:39:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C086B11E8099 for ; Thu, 20 Sep 2012 16:39:11 -0700 (PDT) Received: by lboj14 with SMTP id j14so2871689lbo.31 for ; Thu, 20 Sep 2012 16:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VP4v9sW4UsPXGQqexwmDYQw/8C+Tqlp4J6eTHq0siqk=; b=0X7nI05PtF76F+LOCg/8KhK2lHWLJvg2OucN6XrRIum5/alK9O/GQVPhlMnWTOaqID A2gu9Ku6IptgIvWTQDcdOb3x++zd0DQouNXo/4I4z+fKtzbQqEwczMoGM2vo2ISEu9sJ ia/LWEMbVK3tE/PB3omZXoI5vOa3xkZYAMaCTSsHrYpcwjqmtvAg24S7v9LjN6t5XqrZ K3intRPC/1SCsGf4Rg4OtNW2Y+G9XiJOilk3hDS1HQbYpmp1AieRA50m2oP9vy44FTjG 858+ZH2/1bktEx0Y2J+0NQwUFp0JKf09GEqY9O4cPgk2z8427JwdgQcb72tfYJFrutjj Ib8w== MIME-Version: 1.0 Received: by 10.112.43.137 with SMTP id w9mr1102151lbl.134.1348184349123; Thu, 20 Sep 2012 16:39:09 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Thu, 20 Sep 2012 16:39:09 -0700 (PDT) In-Reply-To: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Thu, 20 Sep 2012 18:39:09 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec54a32c038a53a04ca2aa187 Subject: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:39:13 -0000 --bcaec54a32c038a53a04ca2aa187 Content-Type: text/plain; charset=ISO-8859-1 As we discussed at the end of the meeting today, some folks have difficulty with the current time (7am Pacific) on Tuesdays, thus I've setup a new poll to see if we can't find a better day/time. Note, that while the poll is using dates for next week, we would ideally stick with the same day/time for subsequent weeks. http://doodle.com/f7ncra3kvps8nm8c At this point, I'm almost thinking we might not have enough new ideas to discuss next week, in particular if Monday ends up being the preferred date/time. But, we'll decide that when we agree a day of the week & time. Thanks, Mary. --bcaec54a32c038a53a04ca2aa187 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As we discussed at the end of the meeting today,= some folks have difficulty with the current time (7am Pacific) on Tuesdays= , thus I've setup a new poll to see if we can't find a better day/t= ime. =A0Note, that while the poll is using dates for next week, we would id= eally stick with the same day/time for subsequent weeks.=A0

http://doo= dle.com/f7ncra3kvps8nm8c

At this point, I'm almost thinking we might not have enough new ide= as to discuss next week, in particular if Monday ends up being the preferre= d date/time. =A0 But, we'll decide that when we agree a day of the week= & time.

Thanks,
Mary.

--bcaec54a32c038a53a04ca2aa187-- From mary.ietf.barnes@gmail.com Thu Sep 20 17:36:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6CD21E8050 for ; Thu, 20 Sep 2012 17:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=0.248, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUeZlyIxEWgl for ; Thu, 20 Sep 2012 17:36:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8D21E8047 for ; Thu, 20 Sep 2012 17:36:29 -0700 (PDT) Received: by lboj14 with SMTP id j14so2912853lbo.31 for ; Thu, 20 Sep 2012 17:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=370ofAMWLPzSEo20Op7vc97X5lb7K9LRN3usUNrNxk4=; b=nm6u+pEee3e8hgMKxGRjM0sum+dWDarenVCaHjcUyUDkKSOx3Wy2w0Uwz2qdbn/sDr WPLATOtrxxCqUeYpF5LU8Sn8p5YG/6cdWKzqngCqkJ0dF7srtW7fi5WF/CoGSsuujGAj qwFxXSfE7ZvyPA4HiLIaORT4xa/WM6PH2CmJ3groV6yMuf0bHlVAPy93ua6gNs3kqQDw 0ST/jr0duKaz1dcYAJnullur5SzZeQglpKlLxpxm/MusbDDrPtR2lqF4K9y/fyOpReBX K1EvjrgbPTbSI1AnfYBW6LUbuGs9yuCZccuAZ810aKYqEcVs46otbITvU58tOFyr738O Az7A== MIME-Version: 1.0 Received: by 10.112.28.7 with SMTP id x7mr1172493lbg.54.1348187788261; Thu, 20 Sep 2012 17:36:28 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Thu, 20 Sep 2012 17:36:28 -0700 (PDT) Date: Thu, 20 Sep 2012 19:36:28 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec554dcf235b8f904ca2b6eac Subject: [clue] Final version of Chair's agenda/status/issue charts + draft minutes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 00:36:34 -0000 --bcaec554dcf235b8f904ca2b6eac Content-Type: text/plain; charset=ISO-8859-1 I have uploaded the final version of the charts, including notes captured for the issues, to the proceedings. I have also uploaded draft meeting minutes which currently are just comprised of my notes and links to recordings: http://www.ietf.org/proceedings/interim/2012/09/19/clue/proceedings.html I will update with a summary of conclusions and action items once I get the complete set of notes from Rob and Andy. Thanks everyone for your participation these last two days. Regards, Mary. --bcaec554dcf235b8f904ca2b6eac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have uploaded the final version of the charts, including notes captured f= or the issues, to the proceedings.=A0I have also uploaded draft meeting min= utes which currently are just comprised of my notes and links to recordings= :
http://www.ietf.org/proceedings/interim/2012/09/19/clue/proceedin= gs.html

I will update with a summary of conclu= sions and action items once I get the complete set of notes from Rob and An= dy. =A0

Thanks everyone for your participation these last two d= ays.=A0

Regards,
Mary.=A0
--bcaec554dcf235b8f904ca2b6eac-- From mary.ietf.barnes@gmail.com Mon Sep 24 08:06:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032AD21F87D1 for ; Mon, 24 Sep 2012 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guO505LPyHvP for ; Mon, 24 Sep 2012 08:06:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1EC21F861A for ; Mon, 24 Sep 2012 08:06:22 -0700 (PDT) Received: by lbok13 with SMTP id k13so1137096lbo.31 for ; Mon, 24 Sep 2012 08:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1YlDbEjf/ASOptmOIUudEx/Hs/RBpe9DbvCXCDidfP8=; b=VMBRFoaDYNlnZQFZKjZMqyukvQdL1rzwCzvo4b9vDGtl1BEVMWeGTgwZRSN6G+XKC6 R3qBCCIbVhvos4PR3kLx4sdAC+bO4KbddEWR1rx3cbIlxY2nWJsvVU7TP85EQoLZt98k acC5d78jXZyBblFpVchSPaPkHpGjeM46V6+l4yvx663vQGx65rJfyOkIFR0/Hf2qR382 tqljHmlyuL6MaUEvxgsS/z20QcAR5Ix8njN6VU1p9EpoVSLTQzR1Hmtk02dWcjiqdnzm uPFHarcKXJ4f8kepf0oaUByWWyyOFDVeQhbbLQVfBgMaIv2/NlLxGp+y9qLRG/8pmcVJ rGkw== MIME-Version: 1.0 Received: by 10.112.87.234 with SMTP id bb10mr1677304lbb.54.1348499176843; Mon, 24 Sep 2012 08:06:16 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Mon, 24 Sep 2012 08:06:16 -0700 (PDT) In-Reply-To: References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Mon, 24 Sep 2012 10:06:16 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0401fced6a6ba204ca73ee08 Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 15:06:37 -0000 --f46d0401fced6a6ba204ca73ee08 Content-Type: text/plain; charset=ISO-8859-1 As a reminder, please respond to the poll. At this time, Thursday morning (same time) seems to work as I have a regular meeting that got moved up an hour that I would prefer not to miss on Tuesdays. Obviously, Monday is out for this week and I don't think folks will have had enough time to think about or review materials from last week for a Tuesday meeting. So, if folks can please respond to the doodle by noon Pacific tomorrow, we can decide if we will have a meeting this week on Thursday (Monday would be a very painful time for folks in CA). Thanks, Mary. On Thu, Sep 20, 2012 at 6:39 PM, Mary Barnes wrote: > As we discussed at the end of the meeting today, some folks have > difficulty with the current time (7am Pacific) on Tuesdays, thus I've setup > a new poll to see if we can't find a better day/time. Note, that while the > poll is using dates for next week, we would ideally stick with the same > day/time for subsequent weeks. > > http://doodle.com/f7ncra3kvps8nm8c > > At this point, I'm almost thinking we might not have enough new ideas to > discuss next week, in particular if Monday ends up being the preferred > date/time. But, we'll decide that when we agree a day of the week & time. > > Thanks, > Mary. > > > > --f46d0401fced6a6ba204ca73ee08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a reminder, please respond to the poll. At this time, Thursday morning (= same time) seems to work as I have a regular meeting that got moved up an h= our that I would prefer not to miss on Tuesdays. =A0

Obv= iously, Monday is out for this week and I don't think folks will have h= ad enough time to think about or review materials from last week for a Tues= day meeting. =A0So, if folks can please respond to the doodle by noon Pacif= ic tomorrow, we can decide if we will have a meeting this week on Thursday = (Monday would be a very painful time for folks in CA).=A0

Thanks,
Mary.=A0

On Thu, Sep 20, 2012 at 6:39 PM, Mary Barnes <mary.ietf.bar= nes@gmail.com> wrote:

As we discussed a= t the end of the meeting today, some folks have difficulty with the current= time (7am Pacific) on Tuesdays, thus I've setup a new poll to see if w= e can't find a better day/time. =A0Note, that while the poll is using d= ates for next week, we would ideally stick with the same day/time for subse= quent weeks.=A0

http://doo= dle.com/f7ncra3kvps8nm8c

At this point, I'm almost thinking we might not have enough new ide= as to discuss next week, in particular if Monday ends up being the preferre= d date/time. =A0 But, we'll decide that when we agree a day of the week= & time.

Thanks,
Mary.

--f46d0401fced6a6ba204ca73ee08-- From mary.ietf.barnes@gmail.com Tue Sep 25 13:59:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0711321F8816 for ; Tue, 25 Sep 2012 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.329 X-Spam-Level: X-Spam-Status: No, score=-103.329 tagged_above=-999 required=5 tests=[AWL=0.269, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcI43BwluNpf for ; Tue, 25 Sep 2012 13:59:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78A3721F8815 for ; Tue, 25 Sep 2012 13:59:12 -0700 (PDT) Received: by lbok13 with SMTP id k13so809037lbo.31 for ; Tue, 25 Sep 2012 13:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NixoSgUGurpzIWJoZTf2iI83o83oJXJaYuox5icA9Wo=; b=KYlVjW4qD73Nf5LEENf2wbUhXNzlAJWerxvwtA7XNdP9QjBIu1X3n97xj4vv9BU/D7 LMiFWYzpT2sdAH2iljwxC+HQaawsTn+rSTxubywaSvqjWa19nJBKL9StuuPN8Li3kXvU OA/pB5WgUurxBl/gOUn8NQJFj93mD7YgKumWgiQHDDxHD8H7XnCtWTcIoHIAUozNhOzq zIaRSllvRqEX85hQEYaCRpEd2XTjxQs2NDQ8gAx/ttjtcWT2MRzcaVBmwfZ597RGwJK/ GnecCYT47tQwL8wtqbF6Ik36bSLjU2LhW58NMAYrsa+JUqUUOM8k6wB32//O5bGW+igD mRug== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr14405841lab.30.1348606751336; Tue, 25 Sep 2012 13:59:11 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Tue, 25 Sep 2012 13:59:11 -0700 (PDT) In-Reply-To: References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Tue, 25 Sep 2012 15:59:11 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d040714cf5ae75b04ca8cfabf Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:59:14 -0000 --f46d040714cf5ae75b04ca8cfabf Content-Type: text/plain; charset=ISO-8859-1 Monday morning @ 7am Pacific is the optimal day for the design team meetings. So, we will start back up next Monday and try to have the agenda out by noon on Friday. I will send the updated Webex info and update the wiki. Thanks, Mary. On Mon, Sep 24, 2012 at 10:06 AM, Mary Barnes wrote: > As a reminder, please respond to the poll. At this time, Thursday morning > (same time) seems to work as I have a regular meeting that got moved up an > hour that I would prefer not to miss on Tuesdays. > > Obviously, Monday is out for this week and I don't think folks will have > had enough time to think about or review materials from last week for a > Tuesday meeting. So, if folks can please respond to the doodle by noon > Pacific tomorrow, we can decide if we will have a meeting this week on > Thursday (Monday would be a very painful time for folks in CA). > > Thanks, > Mary. > > > On Thu, Sep 20, 2012 at 6:39 PM, Mary Barnes wrote: > >> As we discussed at the end of the meeting today, some folks have >> difficulty with the current time (7am Pacific) on Tuesdays, thus I've setup >> a new poll to see if we can't find a better day/time. Note, that while the >> poll is using dates for next week, we would ideally stick with the same >> day/time for subsequent weeks. >> >> http://doodle.com/f7ncra3kvps8nm8c >> >> At this point, I'm almost thinking we might not have enough new ideas to >> discuss next week, in particular if Monday ends up being the preferred >> date/time. But, we'll decide that when we agree a day of the week & time. >> >> Thanks, >> Mary. >> >> >> >> > --f46d040714cf5ae75b04ca8cfabf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Monday morning @ 7am Pacific is the optimal day for the design team meeting= s. =A0So, we will start back up next Monday and try to have the agenda out = by noon on Friday. =A0 I will send the updated Webex info and update the wi= ki.

Thanks,
Mary.=A0

On Mon, Sep 24, 2012 at 10:06 AM, Mary Barnes <mary.ietf.barnes@= gmail.com> wrote:

As a reminder, please respond to the poll. A= t this time, Thursday morning (same time) seems to work as I have a regular= meeting that got moved up an hour that I would prefer not to miss on Tuesd= ays. =A0

Obviously, Monday is out for this week and I don't think= folks will have had enough time to think about or review materials from la= st week for a Tuesday meeting. =A0So, if folks can please respond to the do= odle by noon Pacific tomorrow, we can decide if we will have a meeting this= week on Thursday (Monday would be a very painful time for folks in CA).=A0=

Thanks,
Mary.=A0

On Thu, Sep 20, 2012 at 6:39 PM, Mary Barnes <= span dir=3D"ltr"><mary.ietf.barnes@gmail.com> wrote:

As we discussed a= t the end of the meeting today, some folks have difficulty with the current= time (7am Pacific) on Tuesdays, thus I've setup a new poll to see if w= e can't find a better day/time. =A0Note, that while the poll is using d= ates for next week, we would ideally stick with the same day/time for subse= quent weeks.=A0

http://doo= dle.com/f7ncra3kvps8nm8c

At this point, I'm almost thinking we might not have enough new ide= as to discuss next week, in particular if Monday ends up being the preferre= d date/time. =A0 But, we'll decide that when we agree a day of the week= & time.

Thanks,
Mary.

--f46d040714cf5ae75b04ca8cfabf-- From mary.ietf.barnes@gmail.com Tue Sep 25 14:22:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEDE21F88D0 for ; Tue, 25 Sep 2012 14:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=0.262, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8d3FtO4KgYO for ; Tue, 25 Sep 2012 14:22:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8B421F88B2 for ; Tue, 25 Sep 2012 14:22:21 -0700 (PDT) Received: by lbok13 with SMTP id k13so835551lbo.31 for ; Tue, 25 Sep 2012 14:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0e115jEuBFh0s2zR+yA811XIWN7qNfeFIqiKbxTNaPw=; b=amak61P9XcLBeGzPGeru4oUJS9kyeUa+cKAA2t5zo8S1AyiX9Jx2EezhsVKlQG3jJ3 y/vxFednmRjI1pJdC48RYN/4vfUSvEa7cmz3p7YkGxXA6PxbDb8JrP84alZ/EP6eLHQx IaP4wCjII/FKsE7S2zwCuQA+VR1Bwa+ib0VKAW5tExt1fUc+8fSUmHvidhk5Nf4iAxA+ 6hpI7fY0xAI68RsAmt5MtBZyx7g+P29BcI/sRBM0rmsQB6Ap35WhiduSYuaZWWZziIog bGpLCHBilMe7/a5aESVsAa5I4gQiVvFwG/aA/u1NKAe5B4o39HdFlxL/1ahqFM21QuIk m1uA== MIME-Version: 1.0 Received: by 10.152.113.165 with SMTP id iz5mr14278811lab.48.1348608140420; Tue, 25 Sep 2012 14:22:20 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Tue, 25 Sep 2012 14:22:20 -0700 (PDT) In-Reply-To: <1152710503.9256.1348607869055.JavaMail.nobody@jva2tc003.webex.com> References: <1152710503.9256.1348607869055.JavaMail.nobody@jva2tc003.webex.com> Date: Tue, 25 Sep 2012 16:22:20 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0408393b26a5dc04ca8d4d8f Subject: [clue] Meeting rescheduled: CLUE Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:22:23 -0000 --f46d0408393b26a5dc04ca8d4d8f Content-Type: text/plain; charset=ISO-8859-1 Note, the dial-in information is the same, but you might want to use the link to update your calendar. Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Tue, Sep 25, 2012 at 4:17 PM Subject: Meeting rescheduled: CLUE Design Team To: mary.ietf.barnes@gmail.com Hello , Clue Working Group changed the date for this online meeting. Topic: CLUE Design Team Date: Every Monday, from Monday, October 1, 2012 to Monday, March 4, 2013 Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 642 221 028 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1272401277&PW=NNWRkOGVjYTBh&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1272401277&PW=NNWRkOGVjYTBh&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:642 221 028 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1272401277&ICS=MRS2&LD=1&RD=2&ST=1&SHA2=g0ABIdINrJlA73tIU8GcHyRb5YjJdipwv2WxTQvgqZQ=&AID=1265811087&RT=MiM3 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14086003600x642221028# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --f46d0408393b26a5dc04ca8d4d8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note, the dial-in information is the same, but you might want to use the li= nk to update your calendar.

Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com>
Date: Tue, Sep 25, 2012 at 4:17 PM
Subject: Meeting rescheduled: CLUE De= sign Team
To: mary.ietf.ba= rnes@gmail.com

Hello ,

Clue Working Group changed the date for this online meet= ing.

Topic: CLUE Design Team
Date: Every Monday, from Monday= , October 1, 2012 to Monday, March 4, 2013
Time: 9:00 am, Central Dayl= ight Time (Chicago, GMT-05:00)
Meeting Number: 642 221 028
Meeting Password: 1234

---= ----------------------------------------------------
To join the onlin= e meeting (Now from mobile devices!)
---------------------------------= ----------------------
1. Go to htt= ps://ietf.webex.com/ietf/j.php?ED=3D158121817&UID=3D1272401277&PW= =3DNNWRkOGVjYTBh&RT=3DMiM3
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://iet= f.webex.com/ietf/j.php?ED=3D158121817&UID=3D1272401277&PW=3DNNWRkOG= VjYTBh&ORT=3DMiM3

-------------------------------------------------------
To join = the audio conference only
--------------------------------------------= -----------
Call-in toll number (US/Canada): +1-408-600-3600

Access code:642 221 028

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
clue-chairs@tools.ietf.org

To update this me= eting to your calendar program (for example Microsoft Outlook), click this = link:
https://ietf.webex.com/ietf/j.php?ED=3D158121817&UID= =3D1272401277&ICS=3DMRS2&LD=3D1&RD=3D2&ST=3D1&SHA2=3Dg0= ABIdINrJlA73tIU8GcHyRb5YjJdipwv2WxTQvgqZQ=3D&AID=3D1265811087&RT=3D= MiM3

WebEx will automatically setup Meeting Manager for Windows the f= irst time you join a meeting. To save time, you can setup prior to the meet= ing by clicking this link:
https://ietf.webex.com/ietf/meetin= gcenter/mcsetup.php

The playback of UCF (Universal Communications Format) rich media= files requires appropriate players. To view this type of rich media files = in the meeting, please check whether you have the players installed on your= computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+14086003600x642221028#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent to the recording, discuss your concerns with the meeting host prior to = the start of the recording or do not join the session. Please note that any= such recordings may be subject to discovery in the event of litigation.

--f46d0408393b26a5dc04ca8d4d8f-- From christer.holmberg@ericsson.com Wed Sep 26 01:24:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CA921F881B for ; Wed, 26 Sep 2012 01:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8-usQzvDrxW for ; Wed, 26 Sep 2012 01:24:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ED9C221F881D for ; Wed, 26 Sep 2012 01:24:12 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-4f-5062bbab8da2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 75.FE.11467.BABB2605; Wed, 26 Sep 2012 10:24:11 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 26 Sep 2012 10:24:11 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Wed, 26 Sep 2012 10:24:09 +0200 Thread-Topic: Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 Thread-Index: Ac2bwBJYY7yJKOScQjGqagM4bDXI8w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvre7q3UkBBg8OmVnsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGW82yRRsM6hoWLGItYHxonYXIweHhICJRNfTgC5GTiBTTOLC vfVsXYxcHEICpxglWk8sgXIWMEr0b21mBmlgE7CQ6P6nDdIgIqAscXRzPxtImEVAVeLWijCQ sLBAsETf1oMsECUhEqsPrGSEsPUk1q97wA5i8wqES2ybsY0NxGYE2vv91BomEJtZQFzi1pP5 TBD3iEg8vHiaDcIWlXj5+B8rRL2oxJ329YwQ9ZkS+1csYISYKShxcuYTlgmMQrOQjJqFpGwW kjKIeL7EgpWHWSFsHYkFuz+xQdjaEssWvmaGsc8ceMyEKa4rceT8MXYIW1GibXszUC8XkL2C UeLc+xWMMIkp3Q/ZFzDyrGIUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECIzBg1t+6+5gPHVO5BCj NAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MU2NtP93WdVPZIpsd5zwz65ym 2YGP8603rZ3+/8u/927rpt6donQqzeVe7uL2P7cPP/u1iOWf5if1R7duvtkyIcAjQfsPz2el k2zT2LssDvmxcGiY3XuePm15yvLe8C/VBr8j89vdv7xjPNra/DF3j/Pvc753N1uteTkxJyG3 Yd6eGse/ixrjdimxFGckGmoxFxUnAgAtJpm5jwIAAA== Subject: [clue] FW: Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 08:24:17 -0000 --_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_ Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_" --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I've submitted the max-ssrc draft to MMUSIC. The mechanism may be of intere= st for CLUE. Regards, Christer (Associated IPR: https://datatracker.ietf.org/ipr/1639/) From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 26. syyskuuta 2012 10:23 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version/working group: draft-westerlund-mmusic-= max-ssrc-00 Hi, We have submitted a draft, new to MMUSIC: draft-westerlund-mmusic-max-ssrc. The draft SDP entities to, within an m- line, indicate sending and receivin= g capabilities for multiple streams, based on used payload types. Earlier versions of the draft were submitted to AVTCORE. However, we think = MMUSIC is more appropriate, due to the new SDP attributes etc. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI,

I’ve submitted the max-ssrc draft to MMUSIC. The = mechanism may be of interest for CLUE.

Regards,

<= p class=3DMsoNormal>Christer

(Associated IPR= : https://datatracker.ietf.org/ipr/1639/)

From: mmusic-bounces@ietf.org [mailto:mmusic-bounc= es@ietf.org] On Behalf Of Christer Holmberg
Sent: 26. syys= kuuta 2012 10:23
To: mmusic@ietf.org
Subject: [MMUSIC] = Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00

Hi,

We have = submitted a draft, new to MMUSIC: draft-westerlund-mmusic-max-ssrc.

The d= raft SDP entities to, within an m- line, indicate sending and receiving cap= abilities for multiple streams, based on used payload types.
=

Earlier vers= ions of the draft were submitted to AVTCORE. However, we think MMUSIC is mo= re appropriate, due to the new SDP attributes etc.

Regards,<= /p>

Christer<= o:p>
= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_-- --_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Wed, 26 Sep 2012 07:24:47 GMT"; modification-date="Wed, 26 Sep 2012 07:24:47 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D1FESESSCMS0356e_-- From spromano@unina.it Thu Sep 27 07:37:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BF821F854E for ; Thu, 27 Sep 2012 07:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCH85pDWDbXL for ; Thu, 27 Sep 2012 07:37:42 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id A67A321F852C for ; Thu, 27 Sep 2012 07:37:39 -0700 (PDT) Received: from [10.219.27.15] ([10.219.27.15]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id q8REbbLA030987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Sep 2012 16:37:37 +0200 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_DD229F66-41A2-4AEC-8BD3-B9E51F6764AD" Date: Thu, 27 Sep 2012 16:37:36 +0200 Message-Id: To: clue@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Roberta Presta Subject: [clue] CLUE schema definition proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 14:37:43 -0000 --Apple-Mail=_DD229F66-41A2-4AEC-8BD3-B9E51F6764AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear all, together with Roberta Presta, I have lately tried to get in synch with = the current state of the art in CLUE. In the next few days, we're going = to provide you with some feedback about both the framework and the data = model. In the meantime, we have started to work on a schema definition for = CLUE, which has been included in a straw-man draft proposal that you can = find on-line at the following URL: http://www.ietf.org/id/draft-presta-clue-data-model-schema-00.txt We hope this can foster discussion and prove useful for completing the = on-going work. As a first, very high level comment, we think that the = framework document might be somehow restructured in order to just = contain the overall description of the CLUE architecture and components, without = delving into the details associated with the data structures. On the = other hand, a new document might be proposed, which basically merges the = already existing data model draft from Allyn and Andy = (http://tools.ietf.org/html/draft-romanow-clue-data-model-01) and the = 'schema definition' draft we are working on. If this sounds reasonable = to the WG, we might then also add some more information to the current call flows documents = (http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 and = http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-01), = basically showing the exact content of the CLUE messages (and = transported data). For this last part, we might work on automatically = generating CLUE-compliant data structures, starting from the schema = definition, in much the same way as we did for both XCON and MEDIACTRL = in the past. If you think this is worth discussing, we can talk about the details = during next Monday's conference call. Cheers, Simon and Roberta _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_DD229F66-41A2-4AEC-8BD3-B9E51F6764AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = all,

together with Roberta Presta, I have lately = tried to get in synch with the current state of the art in CLUE. In the = next few days, we're going to provide you with some feedback about both = the framework and the data model.
In the meantime, we have = started to work on a schema definition for CLUE, which has been included = in a straw-man draft proposal that you can find on-line at the following = URL:

http://www.ietf.org/id/draft-presta-clue-data-model-schema-00.txt

We hope this can foster discussion and prove = useful for completing the on-going work. As a first, very high level = comment, we think that the framework document might be somehow = restructured in order to just contain the
overall description = of the CLUE architecture and components, without delving into the = details associated with the data structures. On the other hand, a new = document might be proposed, which basically merges the already = existing
data model draft from Allyn and Andy (http:= //tools.ietf.org/html/draft-romanow-clue-data-model-01) and the = 'schema definition' draft we are working on. If this sounds reasonable = to the WG, we might then also add some more information
to the = current call flows documents (http:/= /tools.ietf.org/html/draft-romanow-clue-call-flow-02 and http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-01= ), basically showing the exact content of the CLUE messages (and = transported data). For this last part, we might work on automatically = generating CLUE-compliant data structures, starting from the schema = definition, in much the same way as we did for both XCON and MEDIACTRL = in the past.

If you think this is worth = discussing, we can talk about the details during next Monday's = conference = call.

Cheers,

Simon = and Roberta

= =    = _\\|//_
= =   ( O-O )
= ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=    = Simon Pietro Romano
=   Universita' di Napoli = Federico II
=    = Computer Engineering = Department
   = Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
= = e-mail: spromano@unina.it

= <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli
   = idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
   =    = = oooO
~~~~~~~~~~~~~~~~~~~~~~~( = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
= = \ ( ( = )
= = = \_) ) /
= = = = (_/

= --Apple-Mail=_DD229F66-41A2-4AEC-8BD3-B9E51F6764AD-- From pkyzivat@alum.mit.edu Thu Sep 27 13:08:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C043221F84D9 for ; Thu, 27 Sep 2012 13:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbQ001i-sNrb for ; Thu, 27 Sep 2012 13:08:23 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 1080521F84D7 for ; Thu, 27 Sep 2012 13:08:22 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id 4CZl1k0040SCNGk51L8SGa; Thu, 27 Sep 2012 20:08:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 4L3j1k00t3ZTu2S3VL3jcm; Thu, 27 Sep 2012 20:03:43 +0000 Message-ID: <5064B109.3090406@alum.mit.edu> Date: Thu, 27 Sep 2012 16:03:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] CLUE schema definition proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 20:08:23 -0000 Simon, Roberta, Thank you! Thank you! Thank you!!!! We really need this and until now it seemed we had nobody with the knowledge, cycles, and interest to do it. EVERYBODY: Please review this carefully and comment on things that don't agree with your understanding. I don't expect this to be "right" initially. One of the primary values it has is that it gives a formal syntax, rather than a vague one. So it is easier for someone to decide if it agrees with their understanding. So I expect review and discussion of this to result in a feedback loop with refinements to both this syntax and the framework. I will do a review myself. I expect I will do it a bit at a time, sending comments/questions as I go. I know enough XML to read and understand this, but not enough to write such a schema correctly, with good style and according to current best practice. Thanks, Paul On 9/27/12 10:37 AM, Simon Pietro Romano wrote: > Dear all, > > together with Roberta Presta, I have lately tried to get in synch with > the current state of the art in CLUE. In the next few days, we're going > to provide you with some feedback about both the framework and the data > model. > In the meantime, we have started to work on a schema definition for > CLUE, which has been included in a straw-man draft proposal that you can > find on-line at the following URL: > > http://www.ietf.org/id/draft-presta-clue-data-model-schema-00.txt > > We hope this can foster discussion and prove useful for completing the > on-going work. As a first, very high level comment, we think that the > framework document might be somehow restructured in order to just > contain the > overall description of the CLUE architecture and components, without > delving into the details associated with the data structures. On the > other hand, a new document might be proposed, which basically merges the > already existing > data model draft from Allyn and Andy > (http://tools.ietf.org/html/draft-romanow-clue-data-model-01) and the > 'schema definition' draft we are working on. If this sounds reasonable > to the WG, we might then also add some more information > to the current call flows documents > (http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 and > http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-01), > basically showing the exact content of the CLUE messages (and > transported data). For this last part, we might work on automatically > generating CLUE-compliant data structures, starting from the schema > definition, in much the same way as we did for both XCON and MEDIACTRL > in the past. > > If you think this is worth discussing, we can talk about the details > during next Monday's conference call. > > Cheers, > > Simon and Roberta > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Sep 27 14:01:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB0A21F86D6 for ; Thu, 27 Sep 2012 14:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ6370lJpMLI for ; Thu, 27 Sep 2012 14:01:45 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9832F21F85C6 for ; Thu, 27 Sep 2012 14:01:44 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so2578053bkc.31 for ; Thu, 27 Sep 2012 14:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=speBhIUTrGnmYJvb/U7EEoU///mv/fra45SaStBnohk=; b=n4YaAmzaWCM3duvNGBeLBOQZDxQhgh5beFyeXUAZjIWl3QF2Jmu4O60xUY7ZhW4eT2 JCJchRL2KiuCznbgmRhfuXMsxyEf8qlFWxUPOKzNPb90SijGO3SEBek+D6T+629+7QMq q9fuHjbMD26VcrArua/XYg90O3S8FAJ9eVCSF5VAuSs7JgiKPE6K7xKtQMUpeYjZ3Izg ReJn4B3LKjPtE2uspPeuDvT0L78kAp1Mm6TjzzoEzOPS79+W+2PU3i7yluaYiLTrr/NW PmWK3IM8BOM7yrgmSIpt6vPXJkvHJK8VRQyPps41XBlLLnZpPsYUqWZtSS+wsYTB5aOh Z/kQ== MIME-Version: 1.0 Received: by 10.112.43.137 with SMTP id w9mr1977567lbl.134.1348779703448; Thu, 27 Sep 2012 14:01:43 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Thu, 27 Sep 2012 14:01:43 -0700 (PDT) In-Reply-To: <5064B109.3090406@alum.mit.edu> References: <5064B109.3090406@alum.mit.edu> Date: Thu, 27 Sep 2012 16:01:43 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec54a32c01ab51c04cab53f61 Cc: clue@ietf.org Subject: Re: [clue] CLUE schema definition proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 21:01:45 -0000 --bcaec54a32c01ab51c04cab53f61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be really good to have some discussion of this on Monday's design team call as well. Mary. On Thu, Sep 27, 2012 at 3:03 PM, Paul Kyzivat wrote= : > Simon, Roberta, > > Thank you! Thank you! Thank you!!!! > > We really need this and until now it seemed we had nobody with the > knowledge, cycles, and interest to do it. > > EVERYBODY: Please review this carefully and comment on things that don't > agree with your understanding. > > I don't expect this to be "right" initially. One of the primary values it > has is that it gives a formal syntax, rather than a vague one. So it is > easier for someone to decide if it agrees with their understanding. So I > expect review and discussion of this to result in a feedback loop with > refinements to both this syntax and the framework. > > I will do a review myself. I expect I will do it a bit at a time, sending > comments/questions as I go. I know enough XML to read and understand this= , > but not enough to write such a schema correctly, with good style and > according to current best practice. > > Thanks, > Paul > > > On 9/27/12 10:37 AM, Simon Pietro Romano wrote: > >> Dear all, >> >> together with Roberta Presta, I have lately tried to get in synch with >> the current state of the art in CLUE. In the next few days, we're going >> to provide you with some feedback about both the framework and the data >> model. >> In the meantime, we have started to work on a schema definition for >> CLUE, which has been included in a straw-man draft proposal that you can >> find on-line at the following URL: >> >> http://www.ietf.org/id/draft-**presta-clue-data-model-schema-**00.txt >> >> We hope this can foster discussion and prove useful for completing the >> on-going work. As a first, very high level comment, we think that the >> framework document might be somehow restructured in order to just >> contain the >> overall description of the CLUE architecture and components, without >> delving into the details associated with the data structures. On the >> other hand, a new document might be proposed, which basically merges the >> already existing >> data model draft from Allyn and Andy >> (http://tools.ietf.org/html/**draft-romanow-clue-data-model-**01) >> and the >> 'schema definition' draft we are working on. If this sounds reasonable >> to the WG, we might then also add some more information >> to the current call flows documents >> (http://tools.ietf.org/html/**draft-romanow-clue-call-flow-**02and >> http://tools.ietf.org/html/**draft-kyzivat-clue-**telemedical-callflow-0= 1 >> ), >> basically showing the exact content of the CLUE messages (and >> transported data). For this last part, we might work on automatically >> generating CLUE-compliant data structures, starting from the schema >> definition, in much the same way as we did for both XCON and MEDIACTRL >> in the past. >> >> If you think this is worth discussing, we can talk about the details >> during next Monday's conference call. >> >> Cheers, >> >> Simon and Roberta >> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> >> (_/ >> >> >> >> >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --bcaec54a32c01ab51c04cab53f61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be really good to have some discussion of this on Monday&#= 39;s design team call as well.

Mary.=A0

On Thu, Sep 27, 2012 at 3:03 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:

Simon, Roberta,

Thank you! Thank you! Thank you!!!!

We really need this and until now it seemed we had nobody with the knowledg= e, cycles, and interest to do it.

EVERYBODY: Please review this carefully and comment on things that don'= t agree with your understanding.

I don't expect this to be "right" initially. One of the prima= ry values it has is that it gives a formal syntax, rather than a vague one.= So it is easier for someone to decide if it agrees with their understandin= g. So I expect review and discussion of this to result in a feedback loop w= ith refinements to both this syntax and the framework.

I will do a review myself. I expect I will do it a bit at a time, sending c= omments/questions as I go. I know enough XML to read and understand this, b= ut not enough to write such a schema correctly, with good style and accordi= ng to current best practice.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

On 9/27/12 10:37 AM, Simon Pietro Romano wrote:

Dear all,

together with Roberta Presta, I have lately tried to get in synch with
the current state of the art in CLUE. In the next few days, we're going=
to provide you with some feedback about both the framework and the data
model.
In the meantime, we have started to work on a schema definition for
CLUE, which has been included in a straw-man draft proposal that you can find on-line at the following URL:

http://www.ietf.org/id/draft-presta-clue-data-m= odel-schema-00.txt

We hope this can foster discussion and prove useful for completing the
on-going work. As a first, very high level comment, we think that the
framework document might be somehow restructured in order to just
contain the
overall description of the CLUE architecture and components, without
delving into the details associated with the data structures. On the
other hand, a new document might be proposed, which basically merges the already existing
data model draft from Allyn and Andy
(http://tools.ietf.org/html/draft-romanow-clue-data-m= odel-01) and the
'schema definition' draft we are working on. If this sounds reasona= ble
to the WG, we might then also add some more information
to the current call flows documents
(http://tools.ietf.org/html/draft-romanow-clue-call-fl= ow-02 and
http://tools.ietf.org/html/draft-kyzivat-cl= ue-telemedical-callflow-01),
basically showing the exact content of the CLUE messages (and
transported data). For this last part, we might work on automatically
generating CLUE-compliant data structures, starting from the schema
definition, in much the same way as we did for both XCON and MEDIACTRL
in the past.

If you think this is worth discussing, we can talk about the details
during next Monday's conference call.

Cheers,

Simon and Roberta

=A0 =A0 =A0 =A0_\\|//_
=A0 =A0 =A0 =A0( O-O )
=A0 =A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<= br> Simon Pietro Romano
Universita' di Napoli Federico II
=A0 =A0 =A0 Computer Engineering Department
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Phone: +39 081 7683823 -- Fax: +3= 9 081 7683816
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 e-mail: spromano@unina.it
<mailto:spromano@= unina.it>

=A0 =A0 =A0<<Molti mi dicono che lo scoraggiamento =CB l'alibi de= gli
=A0 =A0 =A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte= .
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 oooO
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_) = =A0 =A0 =A0 =A0 =A0) /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (_/

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec54a32c01ab51c04cab53f61-- From ron.even.tlv@gmail.com Sun Sep 30 05:57:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C774321F861B for ; Sun, 30 Sep 2012 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yk0641XwpVB for ; Sun, 30 Sep 2012 05:57:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8E421F849C for ; Sun, 30 Sep 2012 05:57:18 -0700 (PDT) Received: by qcac10 with SMTP id c10so2100193qca.31 for ; Sun, 30 Sep 2012 05:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=j67IAkDJi0+VZW37mD35ldnaz9mcQXRT3P84vjkIU9o=; b=J+rK4JgHPun6GlLjoCyt+qFWQ4i/ObFcF28IiuJ4qw2pfKb/u+/zWIEyoxtecLs36r 9x0e1wW0Qd2aRkgwqoLk//BTX52BdAuy4go+/99qdm22PzrKklnkz9yYivLVs7rXg33I 9pYvvuRQhIQfcDEl5i/8A8qx3h9EA5TPzDhB2ob4vvknTXgol5+um4nx1TYt7hwtNGWk 7qFRifLBGJMLVdoAtmIb5HUwd3irQhCRdI5HdFWWpQTIpc1/OANkkYoFxLTluRDzosa7 Lme5oBYvmMNKv/URqn536uK32fUIh/WDnwij/A3UoSVL0hwD/2OBQDs1F22uPU3MEk67 T6xA== Received: by 10.229.135.76 with SMTP id m12mr8307121qct.68.1349009837728; Sun, 30 Sep 2012 05:57:17 -0700 (PDT) Received: from RoniE ([76.15.217.235]) by mx.google.com with ESMTPS id g4sm11540400qav.16.2012.09.30.05.57.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 05:57:17 -0700 (PDT) From: "Roni Even" To: "'Simon Pietro Romano'" , References: In-Reply-To: Date: Sun, 30 Sep 2012 14:55:20 +0200 Message-ID: <005b01cd9f0a$db632690$922973b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01CD9F1B.9EEDCB50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHbiFhTbbM+4euVwqqK12QDqFPEpivNZFQ Content-Language: en-us Cc: 'Roberta Presta' Subject: Re: [clue] CLUE schema definition proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 12:57:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005C_01CD9F1B.9EEDCB50 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was able to have a first look. =20 1. For the capture area using elements names like topUp should be topLeft and topRight 2. The framework is not clear about what elements are mandatory = and when. For example =93spatialDescriptionType=94 has minOccurs=3D0. I am = not sure if this should be optional. I am also not sure if you supply the information only capturePoint and scale are required. This becomes clear = in the example where the mediaCaptures are syntactically correct but since they lack the spatial description they are not conveying any information = to show which one is left middle and right. My view is that the major goal = of CLUE is to support the option to provide spatial information and without having the spatial description as required it does not make any sense. =20 Thanks Roni =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro Romano Sent: 27 September, 2012 4:38 PM To: clue@ietf.org Cc: Roberta Presta Subject: [clue] CLUE schema definition proposal =20 Dear all, =20 together with Roberta Presta, I have lately tried to get in synch with = the current state of the art in CLUE. In the next few days, we're going to provide you with some feedback about both the framework and the data = model. In the meantime, we have started to work on a schema definition for = CLUE, which has been included in a straw-man draft proposal that you can find on-line at the following URL: =20 http://www.ietf.org/id/draft-presta-clue-data-model-schema-00.txt =20 We hope this can foster discussion and prove useful for completing the on-going work. As a first, very high level comment, we think that the framework document might be somehow restructured in order to just = contain the overall description of the CLUE architecture and components, without = delving into the details associated with the data structures. On the other hand, = a new document might be proposed, which basically merges the already = existing data model draft from Allyn and Andy (http://tools.ietf.org/html/draft-romanow-clue-data-model-01) and the 'schema definition' draft we are working on. If this sounds reasonable = to the WG, we might then also add some more information to the current call flows documents (http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 and http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-01), basically showing the exact content of the CLUE messages (and = transported data). For this last part, we might work on automatically generating CLUE-compliant data structures, starting from the schema definition, in = much the same way as we did for both XCON and MEDIACTRL in the past. =20 If you think this is worth discussing, we can talk about the details = during next Monday's conference call. =20 Cheers, =20 Simon and Roberta =20 =20 =20 _\\|//_ =20 ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' = di Napoli Federico II Computer Engineering Department = Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it =20 <>. Magritte. = oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ =20 \ ( ( ) = \_) ) / = (_/ =20 =20 =20 =20 ------=_NextPart_000_005C_01CD9F1B.9EEDCB50 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I was able to have a first look.

1.       = For the capture area using elements names like topUp should be = topLeft and topRight
2.       = The framework is not clear about what elements are mandatory and = when. For example “spatialDescriptionType” has = =A0minOccurs=3D0. =A0I am not sure if this should be optional. =A0I am = also not sure if you supply the information only capturePoint and scale = are required. This becomes clear in the example where the mediaCaptures = are syntactically =A0correct but since they lack the spatial description = they are not conveying any information to show which one is left middle = and right. My view is that the major goal of CLUE is to support the = option to provide spatial information and without having the spatial = description as required it does not make any = sense.

Thanks
Roni

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Simon Pietro Romano
Sent: 27 September, 2012 4:38 = PM
To: clue@ietf.org
Cc: Roberta = Presta
Subject: [clue] CLUE schema definition = proposal

Dear = all,

together with Roberta Presta, I have lately tried to = get in synch with the current state of the art in CLUE. In the next few = days, we're going to provide you with some feedback about both the = framework and the data model.
In the meantime, we have started to work on a schema = definition for CLUE, which has been included in a straw-man draft = proposal that you can find on-line at the following = URL:

http://www.ietf.org/id/draft-presta-clue-data-model-schema-00.txt

We hope this can foster discussion and prove useful = for completing the on-going work. As a first, very high level comment, = we think that the framework document might be somehow restructured in = order to just contain the
overall description of the CLUE architecture and = components, without delving into the details associated with the data = structures. On the other hand, a new document might be proposed, which = basically merges the already existing
data model draft from Allyn and Andy (http= ://tools.ietf.org/html/draft-romanow-clue-data-model-01) and the = 'schema definition' draft we are working on. If this sounds reasonable = to the WG, we might then also add some more = information
to the current = call flows documents (http:= //tools.ietf.org/html/draft-romanow-clue-call-flow-02 and <= a = href=3D"http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflo= w-01">http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-= 01), basically showing the exact content of the CLUE messages (and = transported data). For this last part, we might work on automatically = generating CLUE-compliant data structures, starting from the schema = definition, in much the same way as we did for both XCON and MEDIACTRL = in the past.

If you think this is worth discussing, we can talk = about the details during next Monday's conference = call.

Cheers,

Simon and Roberta

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0    = _\\|//_
= = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0   ( O-O = )
= ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=   =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Simon Pietro Romano
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Universita' di Napoli = Federico II
=   =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Computer Engineering = Department
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =    Phone: +39 081 7683823 -- Fax: = +39 081 7683816
= = = e-mail: spromano@unina.it

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 <<Molti mi dicono che lo = scoraggiamento =CB l'alibi degli
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0    idioti. Ci rifletto un = istante; e mi scoraggio>>. Magritte.
   =   =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = = oooO
= ~~~~~~~~~~~~~~~~~~~~~~~( = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \ ( = ( )
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = = \_) = ) /
= = = = (_/

------=_NextPart_000_005C_01CD9F1B.9EEDCB50--