From xcon-bounces@ietf.org Mon Apr 03 04:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKlz-0000xN-BO; Mon, 03 Apr 2006 04:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKlx-0000jl-MJ for xcon@ietf.org; Mon, 03 Apr 2006 04:50:53 -0400 Received: from prix.tandberg.no ([194.196.35.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKlw-0006r9-7a for xcon@ietf.org; Mon, 03 Apr 2006 04:50:53 -0400 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.10/8.12.10) with ESMTP id k338opOD023910 for ; Mon, 3 Apr 2006 10:50:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Apr 2006 10:50:50 +0200 Message-ID: <01C679F7AECF2B47B489F735B7EE49005BB5AC@47mail.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to distribute a list of all participants? Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAAAFfUi+AA+H4OMA== From: "Trond G. Andersen" To: "XCON-IETF" X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [XCON] How to distribute a list of all participants? X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1912991940==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1912991940== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C656FB.B566FE94" This is a multi-part message in MIME format. ------_=_NextPart_001_01C656FB.B566FE94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. =20 I am trying to figure out how to get a list of all participants in an ongoing conference within the XCON framework. I don ' t see how BFCP would be able to transer a list of userid's (sitelist) , so how will we do it? =20 =20 Thanks, trond ------_=_NextPart_001_01C656FB.B566FE94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi.

I am trying to figure out how to get a list of = all=20 participants in an ongoing conference within the XCON framework. I = don ' t see how BFCP = would be=20 able to transer a list of userid's (sitelist) , so how will we = do=20 it?

Thanks,

trond

------_=_NextPart_001_01C656FB.B566FE94-- --===============1912991940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1912991940==-- From xcon-bounces@ietf.org Mon Apr 03 04:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKps-0002PM-4o; Mon, 03 Apr 2006 04:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKpr-0002PH-Ku for xcon@ietf.org; Mon, 03 Apr 2006 04:54:55 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKpp-0006xX-OQ for xcon@ietf.org; Mon, 03 Apr 2006 04:54:55 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F54EFA9; Mon, 3 Apr 2006 10:54:53 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 10:54:42 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 10:54:35 +0200 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B3C6B2973; Mon, 3 Apr 2006 11:54:35 +0300 (EEST) Message-ID: <4430E2CB.3050409@ericsson.com> Date: Mon, 03 Apr 2006 11:54:35 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Adam Roach Subject: Re: [XCON] Minutes Posted References: <44241C21.8070804@nostrum.com> In-Reply-To: <44241C21.8070804@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2006 08:54:35.0514 (UTC) FILETIME=[3B6945A0:01C656FC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Adam, could you mention in the minutes that the BFCP connection draft was supposed to be presented by that we ran out of time? Thanks, Gonzalo Adam Roach wrote: > [as chair] > > The minutes from the ad-hoc meeting are now posted on the IETF materials > page: > > https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=65 > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 03 04:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKrk-00051E-2E; Mon, 03 Apr 2006 04:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKri-0004w4-KW for xcon@ietf.org; Mon, 03 Apr 2006 04:56:50 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKrh-00072e-6z for xcon@ietf.org; Mon, 03 Apr 2006 04:56:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] How to distribute a list of all participants? Date: Mon, 3 Apr 2006 11:56:46 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03632AC3@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] How to distribute a list of all participants? Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAAAFfUi+AA+H4OMAAAJAiw From: "Even, Roni" To: "Trond G. Andersen" , "XCON-IETF" X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536904031==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0536904031== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C656FC.89D4CDA8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C656FC.89D4CDA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, To get the p[articipant list you need to subscribe to the conference event package =20 http://tools.ietf.org/wg/sipping/draft-ietf-sipping-conference-package/d raft-ietf-sipping-conference-package-12.txt =20 Roni Even ________________________________ From: Trond G. Andersen [mailto:trond.andersen@tandberg.net]=20 Sent: Monday, April 03, 2006 11:51 AM To: XCON-IETF Subject: [XCON] How to distribute a list of all participants? Hi. =20 I am trying to figure out how to get a list of all participants in an ongoing conference within the XCON framework. I don ' t see how BFCP would be able to transer a list of userid's (sitelist) , so how will we do it? =20 =20 Thanks, trond ------_=_NextPart_001_01C656FC.89D4CDA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

To get=20 the p[articipant list you need to subscribe to the conference event=20 package

http://tools.ietf.org= /wg/sipping/draft-ietf-sipping-conference-package/draft-ietf-sipping-conf= erence-package-12.txt

Roni=20 Even

From: Trond G. Andersen=20 [mailto:trond.andersen@tandberg.net]
Sent: Monday, April 03, = 2006=20 11:51 AM
To: XCON-IETF
Subject: [XCON] How to = distribute a=20 list of all participants?

Hi.

Thanks,

trond

------_=_NextPart_001_01C656FC.89D4CDA8-- --===============0536904031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0536904031==-- From xcon-bounces@ietf.org Mon Apr 03 05:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKxL-00007h-TL; Mon, 03 Apr 2006 05:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKxL-00007c-LH for xcon@ietf.org; Mon, 03 Apr 2006 05:02:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKxK-0007Jv-6U for xcon@ietf.org; Mon, 03 Apr 2006 05:02:39 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 24B4E4F0001 for ; Mon, 3 Apr 2006 10:59:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 10:59:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 10:59:31 +0200 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6999C2973 for ; Mon, 3 Apr 2006 11:59:31 +0300 (EEST) Message-ID: <4430E3F3.1000609@ericsson.com> Date: Mon, 03 Apr 2006 11:59:31 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2006 08:59:31.0161 (UTC) FILETIME=[EBA16C90:01C656FC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [XCON] BFCP Connection Draft X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Folks, we did not have time to present the BFCP connection draft during our session in Dallas. In any case, you can download the slides I intended to show from: http://www3.ietf.org/proceedings/06mar/slides/xcon-4.ppt I am interested in getting feedback on the open issue below, on slide 10th: When a client gets the transport address of the server to perform an active TCP open: o Do we allow FQDNs? o If so, which DNS procedures do we define? SRV, A, AAAA...? Thanks, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 05 19:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHhM-0005SL-82; Wed, 05 Apr 2006 19:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHhL-0005SB-5A for xcon@ietf.org; Wed, 05 Apr 2006 19:46:03 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHhJ-0003B8-S9 for xcon@ietf.org; Wed, 05 Apr 2006 19:46:03 -0400 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k35Njwqr009362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Apr 2006 18:46:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <443456B0.9000209@nostrum.com> Date: Wed, 05 Apr 2006 18:45:52 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [XCON] XCON Protocol Operations discussion X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org [as chair] At the ad-hoc meeting in Dallas, the chairs solicited a group of volunteers to actively work on an internet-draft to define the protocol operations (but not the protocol itself) for conference manipulation. The document will be brought to the working group as an individual contribution. This message is intended to allow anyone who was not present at that meeting to volunteer to assist in creating this document. If you would like to help out, please subscribe to the following mailing list: http://www.nostrum.com/mailman/listinfo/xcon-ops Note that anyone joining the list will be expected to participate in weekly conference calls, and will be assigned specific work items to complete. Do not join if you don't have the time to actively work on the document. Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Apr 09 13:39:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSdsc-0006AC-Pe; Sun, 09 Apr 2006 13:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpR9-0007lj-HN for xcon@ietf.org; Tue, 21 Mar 2006 17:34:47 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpR8-0007ak-CC for xcon@ietf.org; Tue, 21 Mar 2006 17:34:47 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2LMYkBW005450 for ; Tue, 21 Mar 2006 22:34:46 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 17:34:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Mar 2006 17:34:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs and Nouns Thread-Index: AcZNN6jn0vEpPIr3TmqG6N3zitDVVQ== From: "Rosen, Brian" To: X-OriginalArrivalTime: 21 Mar 2006 22:34:46.0117 (UTC) FILETIME=[A7D8A150:01C64D37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Sun, 09 Apr 2006 13:39:16 -0400 Subject: [XCON] Verbs and Nouns X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0404568534==" Errors-To: xcon-bounces@ietf.org --===============0404568534== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgcHVycG9zZSBvZiB0aGUgQm9GIGlzIHRvIGRlY2lkZSBvbiB0aGUgdmVyYnMg YW5kIG5vdW5zLiAgTXkgbGlzdCBpczoNCg0KVmVyYg0KICBDcmVhdGUvRGVsZXRlIEl0ZW0NCiAg ICAgTm91bnMNCiAgICAgICBDb25mZXJlbmNlDQogICAgICAgU2lkZWJhcg0KCSA/Rmxvb3I/DQoN CiAgU2V0L0dldCBWYWx1ZSANCiAgICAgTm91bnMNCgkgQ29uZlN0YXRlDQoJIE1lZGlhUG9saWN5 DQoJIFNlY3VyaXR5UG9saWN5DQoJID9GbG9vciBDb250cm9sIFBvbGljeT8NCiAgICAgICBDb250 cm9scw0KCQ0KICBBZGQvRGVsZXRlIG1lbWJlciBvZiBsaXN0DQogICAgICBOb3Vucw0KCSAgRGlh bCBPdXQNCgkgIFJlZmVyDQoJICBBbGxvd2VkIFBhcnRpY2lwYW50cw0KCSAgQWxsb3dlZCBGbG9v ciBIb2xkZXJzDQoJICBBbGxvd2VkIEZsb29yIE1vZGVyYXRvcnMNCgkgIFNpZGViYXINCg0KSXTi gJlzIGEgc3RhcnQg4pi6Og0KIA0KDQoNCg== --===============0404568534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0404568534==-- From xcon-bounces@ietf.org Mon Apr 10 22:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8bs-0002ws-Fm; Mon, 10 Apr 2006 22:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8bs-0002wn-3u for xcon@ietf.org; Mon, 10 Apr 2006 22:28:04 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8bq-00021c-TQ for xcon@ietf.org; Mon, 10 Apr 2006 22:28:04 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3B2Rxh8013171 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 10 Apr 2006 22:28:00 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [XCON] Verbs and Nouns Date: Mon, 10 Apr 2006 22:28:22 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I suspect many of these would have to be somewhat finer-grained, such =20= as MediaPolicy, unless you only want to allow replacing the whole =20 policy at once. On Mar 21, 2006, at 5:34 PM, Rosen, Brian wrote: > I think the purpose of the BoF is to decide on the verbs and =20 > nouns. My list is: > > Verb > Create/Delete Item > Nouns > Conference > Sidebar > ?Floor? > > Set/Get Value > Nouns > ConfState > MediaPolicy > SecurityPolicy > ?Floor Control Policy? > Controls > =09 > Add/Delete member of list > Nouns > Dial Out > Refer > Allowed Participants > Allowed Floor Holders > Allowed Floor Moderators > Sidebar > > It=E2=80=99s a start =E2=98=BA: > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 12 02:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYv1-00071O-8u; Wed, 12 Apr 2006 02:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYuz-00070J-Gm for xcon@ietf.org; Wed, 12 Apr 2006 02:33:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTYuw-0000Sy-MB for xcon@ietf.org; Wed, 12 Apr 2006 02:33:33 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 249354F0039 for ; Wed, 12 Apr 2006 08:33:30 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 08:33:29 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 08:33:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Apr 2006 08:33:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of the data model draft thread-index: AcYAbz2Ce/P5lmxiEdq0TwARJEEJ/AAEskTwEE1h7pAHEIonoA== From: "Oscar Novo \(JO/LMF\)" To: X-OriginalArrivalTime: 12 Apr 2006 06:33:29.0234 (UTC) FILETIME=[02D53720:01C65DFB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [XCON] New version of the data model draft X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hello, Today, I've submitted the new version of the "A Common Conference Information Data Model for Centralized Conferencing" draft. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-common-data-model-00 .txt Here's an overall summary of the changes: - The policy information of the CPCP drafts is added to this document (thanks Hisham Khartabil, Petri Koskelainen, and Aki Niemi to let me do it). - Definition of new elements for the PSTN, H.320, and H.323 protocols.=20 - Additional elements added.=20 - Modification of the handling of times in the data model as we agreed in IETF-65. - The XML schema is now validate. I will appreciate your comments! Kind Regards, Oscar Novo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 17 14:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYNT-0004rb-I5; Mon, 17 Apr 2006 14:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTD6T-0001uR-GQ; Tue, 11 Apr 2006 03:15:57 -0400 Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTD6O-0003ue-Ty; Tue, 11 Apr 2006 03:15:57 -0400 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Tue, 11 Apr 2006 10:18:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Apr 2006 10:15:17 +0300 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602018AB7@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Video Transcoding using SIP & SDP Thread-Index: AcZdN6+fI6Zyomf2QtulmbGVHUUBJA== From: "Osher Hmelnizky" To: , X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-Mailman-Approved-At: Mon, 17 Apr 2006 14:23:10 -0400 Cc: Sharone Aloni , Oren Kudovitzky Subject: [XCON] Video Transcoding using SIP & SDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0804643545==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0804643545== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65D37.CE6D420B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65D37.CE6D420B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, is it any work in progress regarding Video transcoding services using SIP and SDP. I'm looking something like RFC 4117 for video. =20 Thanks in advance =20 Osher =20 ------_=_NextPart_001_01C65D37.CE6D420B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello, is it any work in progress regarding Video transcoding services using SIP and SDP.

I’m looking something like RFC = 4117 for video.

Thanks in advance

Osher

------_=_NextPart_001_01C65D37.CE6D420B-- --===============0804643545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0804643545==-- From xcon-bounces@ietf.org Fri Apr 21 09:35:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvnX-0005Zl-DP; Fri, 21 Apr 2006 09:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvnV-0005ZV-Bs for xcon@ietf.org; Fri, 21 Apr 2006 09:35:45 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWvnS-0007uC-5w for xcon@ietf.org; Fri, 21 Apr 2006 09:35:45 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 882C68EC; Fri, 21 Apr 2006 15:35:41 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 15:35:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 15:35:40 +0200 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BF438236B; Fri, 21 Apr 2006 16:35:40 +0300 (EEST) Message-ID: <4448DFAC.9080009@ericsson.com> Date: Fri, 21 Apr 2006 16:35:40 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 13:35:40.0528 (UTC) FILETIME=[7B2DAF00:01C66548] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: alan@sipstation.com, Keith Drage , Adam Roach , Joerg Ott Subject: [XCON] Proposed small fixes to BFCP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Folks, while implementing our BFCP stack (the 'running code' part of the protocol), we have discovered a couple of relatively minor bugs in the BFCP spec that need to be fixed. They are probably too big to be fixed thru RFC editor notes. My suggestion would be to remove the draft from the queue, perform the changes I propose below, and send it back to the queue. Opinions? Section 5.3.9 defines the ChairAction message. That message can contain several floors (which belong to the same floor request operation) but can only provide a single queue position (within the REQUEST-STATUS attribute) for all of them. We need to be able to provide different queue positions for different floors (e.g., second for floor 1 and third for floor 2). In order to do this, we need to define a new grouped attribute called FLOOR-REQUEST-STATUS whose definition would be the following: Attribute header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x|M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute ABNF: FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) (REQUEST-STATUS) [STATUS-INFO] *[EXTENSION-ATTRIBUTE] Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' The same for the already existing ChairAction message. Additionally, we would define a new grouped attribute called OVERALL-REQUEST-STATUS, whose definition would be almost identical to the FLOOR-REQUEST-STATUS attribute. The only difference is that this one would carry a Floor Request ID instead of a Floor ID. This attribute would be used within the FLOOR-REQUEST-INFORMATION attribute, whose ABNF would become: OLD: FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) (REQUEST-STATUS) <-- 1*(FLOOR-ID) <-- [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO] [STATUS-INFO] <-- *[EXTENSION-ATTRIBUTE] NEW: FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) (OVERALL-REQUEST-STATUS) 1*(FLOOR-REQUEST-STATUS) [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO] *[EXTENSION-ATTRIBUTE] Then, we would need to add a brief discussion on queues, indicating that the queue positions in the OVERALL-REQUEST-STATUS attribute refer to positions in a global queue for floor requests and that queue positions in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue for floor requests for a particular floor. Of course, implementations are free to implement (or provide information about) one, both, or none of these queue types. The ChairAction message would become: OLD: ChairAction = (COMMON-HEADER) 1*(FLOOR-ID) <-- (FLOOR-REQUEST-ID) (REQUEST-STATUS) <-- [STATUS-INFO] *[EXTENSION-ATTRIBUTE] NEW: ChairAction = (COMMON-HEADER) 1*(FLOOR-REQUEST-STATUS) (FLOOR-REQUEST-ID) [STATUS-INFO] *[EXTENSION-ATTRIBUTE] A different issue (more easily fixable than the issue above) is that the FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID) instead of *(FLOOR-ID). Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Apr 21 11:26:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWxWD-0002qo-L3; Fri, 21 Apr 2006 11:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWxWB-0002qL-UF for xcon@ietf.org; Fri, 21 Apr 2006 11:25:59 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWxWB-0006bd-Bo for xcon@ietf.org; Fri, 21 Apr 2006 11:25:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Proposed small fixes to BFCP Date: Fri, 21 Apr 2006 18:25:56 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C036F3834@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Proposed small fixes to BFCP Thread-Index: AcZlSI2MlKst4yslQCSAXh6oBHPH5AADi2Uw From: "Even, Roni" To: "Gonzalo Camarillo" , "XCON" X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Adam Roach , Keith Drage , alan@sipstation.com, Joerg Ott X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi guys, I may open here a can of worms, but when looking at an implementation = that includes BFCP as described in = http://www.ietf.org/internet-drafts/draft-even-xcon-pnc-01.txt, we = encountered the issue of NAT traversal. The pnc draft addresses = multipoint cases but may also be used in a point to point case where one = of the endpoints is the BFCP server. Since BFCP is only defined for TCP = we feel that there is currently a lack of support for TCP based NAT = traversal solutions. Maybe we can consider allowing BFCP over UDP. Thanks Roni Even=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Friday, April 21, 2006 4:36 PM > To: XCON > Cc: alan@sipstation.com; Keith Drage; Adam Roach; Joerg Ott > Subject: [XCON] Proposed small fixes to BFCP >=20 > Folks, >=20 > while implementing our BFCP stack (the 'running code' part of the > protocol), we have discovered a couple of relatively minor bugs in the > BFCP spec that need to be fixed. They are probably too big to be fixed > thru RFC editor notes. My suggestion would be to remove the draft from > the queue, perform the changes I propose below, and send it back to = the > queue. Opinions? >=20 >=20 > Section 5.3.9 defines the ChairAction message. That message can = contain > several floors (which belong to the same floor request operation) but > can only provide a single queue position (within the REQUEST-STATUS > attribute) for all of them. We need to be able to provide different > queue positions for different floors (e.g., second for floor 1 and = third > for floor 2). In order to do this, we need to define a new grouped > attribute called FLOOR-REQUEST-STATUS whose definition would be the > following: >=20 > Attribute header: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x x x x x x x|M| Length | Floor ID = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Attribute ABNF: >=20 > FLOOR-REQUEST-STATUS =3D (FLOOR-REQUEST-STATUS-HEADER) > (REQUEST-STATUS) > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] >=20 > Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute > would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' >=20 > The same for the already existing ChairAction message. >=20 >=20 > Additionally, we would define a new grouped attribute called > OVERALL-REQUEST-STATUS, whose definition would be almost identical to > the FLOOR-REQUEST-STATUS attribute. The only difference is that this = one > would carry a Floor Request ID instead of a Floor ID. This attribute > would be used within the FLOOR-REQUEST-INFORMATION attribute, whose = ABNF > would become: >=20 > OLD: >=20 > FLOOR-REQUEST-INFORMATION =3D (FLOOR-REQUEST-INFORMATION-HEADER) > (REQUEST-STATUS) <-- > 1*(FLOOR-ID) <-- > [BENEFICIARY-INFORMATION] > [REQUESTED-BY-INFORMATION] > [PRIORITY] > [PARTICIPANT-PROVIDED-INFO] > [STATUS-INFO] <-- > *[EXTENSION-ATTRIBUTE] >=20 > NEW: >=20 > FLOOR-REQUEST-INFORMATION =3D (FLOOR-REQUEST-INFORMATION-HEADER) > (OVERALL-REQUEST-STATUS) > 1*(FLOOR-REQUEST-STATUS) > [BENEFICIARY-INFORMATION] > [REQUESTED-BY-INFORMATION] > [PRIORITY] > [PARTICIPANT-PROVIDED-INFO] > *[EXTENSION-ATTRIBUTE] >=20 >=20 >=20 > Then, we would need to add a brief discussion on queues, indicating = that > the queue positions in the OVERALL-REQUEST-STATUS attribute refer to > positions in a global queue for floor requests and that queue = positions > in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue = for > floor requests for a particular floor. Of course, implementations are > free to implement (or provide information about) one, both, or none of > these queue types. >=20 > The ChairAction message would become: >=20 > OLD: >=20 > ChairAction =3D (COMMON-HEADER) > 1*(FLOOR-ID) <-- > (FLOOR-REQUEST-ID) > (REQUEST-STATUS) <-- > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] >=20 > NEW: >=20 > ChairAction =3D (COMMON-HEADER) > 1*(FLOOR-REQUEST-STATUS) > (FLOOR-REQUEST-ID) > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] >=20 >=20 > A different issue (more easily fixable than the issue above) is that = the > FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID) > instead of *(FLOOR-ID). >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Apr 21 14:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0ho-00070w-Dt; Fri, 21 Apr 2006 14:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0hm-00070r-Pc for xcon@ietf.org; Fri, 21 Apr 2006 14:50:10 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0hh-0000PC-Jg for xcon@ietf.org; Fri, 21 Apr 2006 14:50:10 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3A354F0001; Fri, 21 Apr 2006 20:49:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 20:49:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 20:49:54 +0200 Received: from [131.160.126.101] (rvi2-126-101.lmf.ericsson.se [131.160.126.101]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5BB66236B; Fri, 21 Apr 2006 21:49:54 +0300 (EEST) Message-ID: <44492951.2020802@ericsson.com> Date: Fri, 21 Apr 2006 21:49:53 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Even, Roni" Subject: NAT Traversal and BFCP WAS (Re: [XCON] Proposed small fixes to BFCP) References: <144ED8561CE90C41A3E5908EDECE315C036F3834@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C036F3834@IsrExch01.israel.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 18:49:54.0474 (UTC) FILETIME=[610188A0:01C66574] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Adam Roach , Keith Drage , alan@sipstation.com, XCON , Joerg Ott X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Roni, you can use ICE (e.g., using a TURN relay) for TCP-based media as well. That should cover your scenario. We do not need to develop any BFCP-specific extension for NAT traversal. Thanks, Gonzalo Even, Roni wrote: > Hi guys, > I may open here a can of worms, but when looking at an implementation that includes BFCP as described in http://www.ietf.org/internet-drafts/draft-even-xcon-pnc-01.txt, we encountered the issue of NAT traversal. The pnc draft addresses multipoint cases but may also be used in a point to point case where one of the endpoints is the BFCP server. Since BFCP is only defined for TCP we feel that there is currently a lack of support for TCP based NAT traversal solutions. Maybe we can consider allowing BFCP over UDP. > Thanks > Roni Even > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 26 18:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYspf-00024u-M9; Wed, 26 Apr 2006 18:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYspe-00024c-Cv; Wed, 26 Apr 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYspe-0004mM-4Q; Wed, 26 Apr 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3QMo1vP026680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYspd-0002pO-OF; Wed, 26 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Apr 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-common-data-model-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Common Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-00.txt Pages : 57 Date : 2006-4-26 This document collects, organizes, and describes the conference variables that have been introduced in various protocol drafts of the XCON and SIPPING working groups. The goal of this document is to allow the conference control protocols to use a unified common conference information data model for XCON. This document formally defines an Extensible Markup Language (XML) Schema that represents the common conference information in a conferencing server. The information is modeled as a series of elements, each of which contains a set of children and attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-common-data-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-common-data-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26152936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-common-data-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26152936.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Fri Apr 28 04:03:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNwn-00044r-6J; Fri, 28 Apr 2006 04:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNwm-00044m-Ap for xcon@ietf.org; Fri, 28 Apr 2006 04:03:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNwj-0000As-OO for xcon@ietf.org; Fri, 28 Apr 2006 04:03:28 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B60C4F0002; Fri, 28 Apr 2006 10:03:25 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:03:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:03:24 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BFAB8236E; Fri, 28 Apr 2006 11:03:23 +0300 (EEST) Message-ID: <4451CC4B.7000801@ericsson.com> Date: Fri, 28 Apr 2006 11:03:23 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [XCON] Proposed small fixes to BFCP References: <4448DFAC.9080009@ericsson.com> In-Reply-To: <4448DFAC.9080009@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 08:03:24.0290 (UTC) FILETIME=[39256E20:01C66A9A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Adam Roach , Keith Drage , alan@sipstation.com, XCON , Joerg Ott X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Adam, Alan, I would like to, at least, get the "go ahead" from the chairs... Thanks, Gonzalo Gonzalo Camarillo wrote: > Folks, > > while implementing our BFCP stack (the 'running code' part of the > protocol), we have discovered a couple of relatively minor bugs in the > BFCP spec that need to be fixed. They are probably too big to be fixed > thru RFC editor notes. My suggestion would be to remove the draft from > the queue, perform the changes I propose below, and send it back to the > queue. Opinions? > > > Section 5.3.9 defines the ChairAction message. That message can contain > several floors (which belong to the same floor request operation) but > can only provide a single queue position (within the REQUEST-STATUS > attribute) for all of them. We need to be able to provide different > queue positions for different floors (e.g., second for floor 1 and third > for floor 2). In order to do this, we need to define a new grouped > attribute called FLOOR-REQUEST-STATUS whose definition would be the > following: > > Attribute header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x x x x x x x|M| Length | Floor ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Attribute ABNF: > > FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) > (REQUEST-STATUS) > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] > > Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute > would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' > > The same for the already existing ChairAction message. > > > Additionally, we would define a new grouped attribute called > OVERALL-REQUEST-STATUS, whose definition would be almost identical to > the FLOOR-REQUEST-STATUS attribute. The only difference is that this one > would carry a Floor Request ID instead of a Floor ID. This attribute > would be used within the FLOOR-REQUEST-INFORMATION attribute, whose ABNF > would become: > > OLD: > > FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) > (REQUEST-STATUS) <-- > 1*(FLOOR-ID) <-- > [BENEFICIARY-INFORMATION] > [REQUESTED-BY-INFORMATION] > [PRIORITY] > [PARTICIPANT-PROVIDED-INFO] > [STATUS-INFO] <-- > *[EXTENSION-ATTRIBUTE] > > NEW: > > FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) > (OVERALL-REQUEST-STATUS) > 1*(FLOOR-REQUEST-STATUS) > [BENEFICIARY-INFORMATION] > [REQUESTED-BY-INFORMATION] > [PRIORITY] > [PARTICIPANT-PROVIDED-INFO] > *[EXTENSION-ATTRIBUTE] > > > > Then, we would need to add a brief discussion on queues, indicating that > the queue positions in the OVERALL-REQUEST-STATUS attribute refer to > positions in a global queue for floor requests and that queue positions > in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue for > floor requests for a particular floor. Of course, implementations are > free to implement (or provide information about) one, both, or none of > these queue types. > > The ChairAction message would become: > > OLD: > > ChairAction = (COMMON-HEADER) > 1*(FLOOR-ID) <-- > (FLOOR-REQUEST-ID) > (REQUEST-STATUS) <-- > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] > > NEW: > > ChairAction = (COMMON-HEADER) > 1*(FLOOR-REQUEST-STATUS) > (FLOOR-REQUEST-ID) > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] > > > A different issue (more easily fixable than the issue above) is that the > FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID) > instead of *(FLOOR-ID). > > Cheers, > > Gonzalo > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Apr 28 19:27:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcMj-0001AP-Mk; Fri, 28 Apr 2006 19:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcMh-00015P-OA for xcon@ietf.org; Fri, 28 Apr 2006 19:27:11 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZcMh-000500-E5 for xcon@ietf.org; Fri, 28 Apr 2006 19:27:11 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3SNR5iN001275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Apr 2006 18:27:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4452A4C9.6010304@nostrum.com> Date: Fri, 28 Apr 2006 18:27:05 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [XCON] Proposed small fixes to BFCP References: <4448DFAC.9080009@ericsson.com> <4451CC4B.7000801@ericsson.com> In-Reply-To: <4451CC4B.7000801@ericsson.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Joerg Ott , Keith Drage , alan@sipstation.com, XCON X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I was hoping to hear more from working group members before making the decision -- but it appears that no one has any comments one way or the other on the issue. I'll discuss with our AD and try to determine the best way to move forward. /a Gonzalo Camarillo wrote: > Adam, Alan, > > I would like to, at least, get the "go ahead" from the chairs... > > Thanks, > > Gonzalo > > Gonzalo Camarillo wrote: >> Folks, >> >> while implementing our BFCP stack (the 'running code' part of the >> protocol), we have discovered a couple of relatively minor bugs in >> the BFCP spec that need to be fixed. They are probably too big to be >> fixed thru RFC editor notes. My suggestion would be to remove the >> draft from the queue, perform the changes I propose below, and send >> it back to the queue. Opinions? >> >> >> Section 5.3.9 defines the ChairAction message. That message can >> contain several floors (which belong to the same floor request >> operation) but can only provide a single queue position (within the >> REQUEST-STATUS attribute) for all of them. We need to be able to >> provide different queue positions for different floors (e.g., second >> for floor 1 and third for floor 2). In order to do this, we need to >> define a new grouped attribute called FLOOR-REQUEST-STATUS whose >> definition would be the following: >> >> Attribute header: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |x x x x x x x|M| Length | Floor ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Attribute ABNF: >> >> FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) >> (REQUEST-STATUS) >> [STATUS-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute >> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' >> >> The same for the already existing ChairAction message. >> >> >> Additionally, we would define a new grouped attribute called >> OVERALL-REQUEST-STATUS, whose definition would be almost identical to >> the FLOOR-REQUEST-STATUS attribute. The only difference is that this >> one would carry a Floor Request ID instead of a Floor ID. This >> attribute would be used within the FLOOR-REQUEST-INFORMATION >> attribute, whose ABNF would become: >> >> OLD: >> >> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >> (REQUEST-STATUS) <-- >> 1*(FLOOR-ID) <-- >> [BENEFICIARY-INFORMATION] >> [REQUESTED-BY-INFORMATION] >> [PRIORITY] >> [PARTICIPANT-PROVIDED-INFO] >> [STATUS-INFO] <-- >> *[EXTENSION-ATTRIBUTE] >> >> NEW: >> >> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >> (OVERALL-REQUEST-STATUS) >> 1*(FLOOR-REQUEST-STATUS) >> [BENEFICIARY-INFORMATION] >> [REQUESTED-BY-INFORMATION] >> [PRIORITY] >> [PARTICIPANT-PROVIDED-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> >> >> Then, we would need to add a brief discussion on queues, indicating >> that the queue positions in the OVERALL-REQUEST-STATUS attribute >> refer to positions in a global queue for floor requests and that >> queue positions in the FLOOR-REQUEST-STATUS attribute refer to >> positions in a queue for floor requests for a particular floor. Of >> course, implementations are free to implement (or provide information >> about) one, both, or none of these queue types. >> >> The ChairAction message would become: >> >> OLD: >> >> ChairAction = (COMMON-HEADER) >> 1*(FLOOR-ID) <-- >> (FLOOR-REQUEST-ID) >> (REQUEST-STATUS) <-- >> [STATUS-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> NEW: >> >> ChairAction = (COMMON-HEADER) >> 1*(FLOOR-REQUEST-STATUS) >> (FLOOR-REQUEST-ID) >> [STATUS-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> >> A different issue (more easily fixable than the issue above) is that >> the FloorRequest and the FloorQuery messages should carry >> 1*(FLOOR-ID) instead of *(FLOOR-ID). >> >> Cheers, >> >> Gonzalo >> _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Apr 30 04:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa7CM-0006bX-K7; Sun, 30 Apr 2006 04:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa7CL-0006Vm-Nm for xcon@ietf.org; Sun, 30 Apr 2006 04:22:33 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa7CJ-0006cC-2C for xcon@ietf.org; Sun, 30 Apr 2006 04:22:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Proposed small fixes to BFCP Date: Sun, 30 Apr 2006 11:22:27 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C037AF1B3@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Proposed small fixes to BFCP Thread-Index: AcZrG142TSHTpqY7RKqjm2HP60gvRABE7NOg From: "Even, Roni" To: "Adam Roach" , "Gonzalo Camarillo" X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Joerg Ott , Keith Drage , alan@sipstation.com, XCON X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, I looked at the changes suggested by Gonzalo and they make sense to me. = Do not see any issues. Roni Even > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Saturday, April 29, 2006 2:27 AM > To: Gonzalo Camarillo > Cc: Joerg Ott; Keith Drage; alan@sipstation.com; XCON > Subject: Re: [XCON] Proposed small fixes to BFCP >=20 > I was hoping to hear more from working group members before making the > decision -- but it appears that no one has any comments one way or the > other on the issue. I'll discuss with our AD and try to determine the > best way to move forward. >=20 > /a >=20 > Gonzalo Camarillo wrote: > > Adam, Alan, > > > > I would like to, at least, get the "go ahead" from the chairs... > > > > Thanks, > > > > Gonzalo > > > > Gonzalo Camarillo wrote: > >> Folks, > >> > >> while implementing our BFCP stack (the 'running code' part of the > >> protocol), we have discovered a couple of relatively minor bugs in > >> the BFCP spec that need to be fixed. They are probably too big to = be > >> fixed thru RFC editor notes. My suggestion would be to remove the > >> draft from the queue, perform the changes I propose below, and send > >> it back to the queue. Opinions? > >> > >> > >> Section 5.3.9 defines the ChairAction message. That message can > >> contain several floors (which belong to the same floor request > >> operation) but can only provide a single queue position (within the > >> REQUEST-STATUS attribute) for all of them. We need to be able to > >> provide different queue positions for different floors (e.g., = second > >> for floor 1 and third for floor 2). In order to do this, we need to > >> define a new grouped attribute called FLOOR-REQUEST-STATUS whose > >> definition would be the following: > >> > >> Attribute header: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |x x x x x x x|M| Length | Floor ID = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Attribute ABNF: > >> > >> FLOOR-REQUEST-STATUS =3D (FLOOR-REQUEST-STATUS-HEADER) > >> (REQUEST-STATUS) > >> [STATUS-INFO] > >> *[EXTENSION-ATTRIBUTE] > >> > >> Now, the already existing FLOOR-REQUEST-INFORMATION grouped = attribute > >> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' > >> > >> The same for the already existing ChairAction message. > >> > >> > >> Additionally, we would define a new grouped attribute called > >> OVERALL-REQUEST-STATUS, whose definition would be almost identical = to > >> the FLOOR-REQUEST-STATUS attribute. The only difference is that = this > >> one would carry a Floor Request ID instead of a Floor ID. This > >> attribute would be used within the FLOOR-REQUEST-INFORMATION > >> attribute, whose ABNF would become: > >> > >> OLD: > >> > >> FLOOR-REQUEST-INFORMATION =3D = (FLOOR-REQUEST-INFORMATION-HEADER) > >> (REQUEST-STATUS) <-- > >> 1*(FLOOR-ID) <-- > >> [BENEFICIARY-INFORMATION] > >> [REQUESTED-BY-INFORMATION] > >> [PRIORITY] > >> [PARTICIPANT-PROVIDED-INFO] > >> [STATUS-INFO] <-- > >> *[EXTENSION-ATTRIBUTE] > >> > >> NEW: > >> > >> FLOOR-REQUEST-INFORMATION =3D = (FLOOR-REQUEST-INFORMATION-HEADER) > >> (OVERALL-REQUEST-STATUS) > >> 1*(FLOOR-REQUEST-STATUS) > >> [BENEFICIARY-INFORMATION] > >> [REQUESTED-BY-INFORMATION] > >> [PRIORITY] > >> [PARTICIPANT-PROVIDED-INFO] > >> *[EXTENSION-ATTRIBUTE] > >> > >> > >> > >> Then, we would need to add a brief discussion on queues, indicating > >> that the queue positions in the OVERALL-REQUEST-STATUS attribute > >> refer to positions in a global queue for floor requests and that > >> queue positions in the FLOOR-REQUEST-STATUS attribute refer to > >> positions in a queue for floor requests for a particular floor. Of > >> course, implementations are free to implement (or provide = information > >> about) one, both, or none of these queue types. > >> > >> The ChairAction message would become: > >> > >> OLD: > >> > >> ChairAction =3D (COMMON-HEADER) > >> 1*(FLOOR-ID) <-- > >> (FLOOR-REQUEST-ID) > >> (REQUEST-STATUS) <-- > >> [STATUS-INFO] > >> *[EXTENSION-ATTRIBUTE] > >> > >> NEW: > >> > >> ChairAction =3D (COMMON-HEADER) > >> 1*(FLOOR-REQUEST-STATUS) > >> (FLOOR-REQUEST-ID) > >> [STATUS-INFO] > >> *[EXTENSION-ATTRIBUTE] > >> > >> > >> A different issue (more easily fixable than the issue above) is = that > >> the FloorRequest and the FloorQuery messages should carry > >> 1*(FLOOR-ID) instead of *(FLOOR-ID). > >> > >> Cheers, > >> > >> Gonzalo > >> >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon