- sg16-avd - lists.packetizer.com

Registration to the Upcoming SG16 experts meetings in Yokosuka
by Istvan Sebestyen 20 Mar '98

20 Mar '98

At 20:01 17.03.1998 +0900, Kiyoshi SAKAI wrote: >Dear SG16 Q.11, Q.12-14 Experts, > >As we have announced earlier, March 20 is the deadline for the >registration and hotel reservation for the SG16 Yokosuka meeting. >If you plan to attend the meeting, please register as soon as possible >according to the following directions; > >1) Registration form should be sent to "harasaki(a)ccm.cl.nec.co.jp" > with copy to Rapporteurs. > >2) Hotel reservation form should be faxed to Yokosuka Prince Hotel. > >Block room reservation will expire on March 20, however, the hotel will >continue to accept your reservation at the same price after the deadline >only if the rooms are available. > >Registration and hotel reservation forms are attached to this mail. > >Best regards, > >Hidenobu Harasaki, NEC Corporation >Kiyoshi Sakai, Fujitsu Laboratories LTD. > >********************************************************************** > Kiyoshi Sakai > Media Processing Laboratory > Multimedia Systems Labs. > FUJITSU LABORATORIES LTD. > Tel. : +81 44 754 2679 > Fax. : +81 44 754 2347 > E-mail : sakai(a)flab.fujitsu.co.jp >********************************************************************** > >Attachment Converted: C:\TEMP\invitat2.zip > Yes, I would like to register to the above meeting. I did not find the registration form in the attachement... Kind regards, Istvan Sebestyen ------------------------------------------------------------------ Istvan Sebestyen Siemens AG Standardization, Large Networks PN GS 94, Private Communications Systems Group, Mch H/1760/255 Tel: +49-89-722 47230 Hofmannstr. 51 Fax: +49-89-722 47713 D-81359 Munich, GERMANY Internet: istvan.sebestyen(a)mch.pn.siemens.de (preferred) istvan.sebestyen(a)pn.siemens.de (Fall back only) X.400: c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail; s=Sebestyen;g=Istvan Note: Unfortunately - in practice - e-mails sent to me occasionally may get lost or stay unread for a long time due to business trips. So, for very important communication pls. send a "back-up" in fax. ------------------------------------------------------------------

2 1

Re: Registration to the Upcoming SG16 experts meetings in Yokosuka
by Nancy Greene 20 Mar '98

20 Mar '98

Regarding Mr. Sebastien's message of not finding the registration document attached to the e-mail, it may be a better practice to "do like the IETF" and send all meeting announcements and agendas in pure text so that they are quickly and easily available to all. Nancy ----------------------------------------------------------------------- Nancy Greene, Public Data Networks, Nortel Tel 613-763-9789 Fax 613-763-8904 Email ngreene(a)nortel.ca -----------------------------------------------------------------------

1 0

Request for APC-Number
by Sakae Okubo 20 Mar '98

20 Mar '98

Dear Kaynam Hedayat, In response to your request, APC-1339 has been allocated to your contribution "Proposals and General Comments for H.323 Annex C". Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ******************************************************************** --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C ---------------------------------------------------------------------

1 0

subscription
by Jong-il Kim 19 Mar '98

19 Mar '98

Woud you add me on this reflector? subscribe, subscription. Thanks in advance

1 0

Multiple GRQs
by Chris Purvis WVdevmt-WS 19 Mar '98

19 Mar '98

In H.225.0, under GRQ (section 7.8.1 in version 2, 7.8 in version 1), it says "Note that one GRQ is sent per logical endpoint; thus an MCU or a Gateway might send many.". Why would an MCU or Gateway want to do this? Does this mean that an MCU might go on to register with multiple gatekeepers? Or that a gateway might register multiply with one gatekeeper, registering different sets of aliases to correspond to different bandwidths or other WAN-side characteristics? Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Request for APC numbers
by Sakae Okubo 18 Mar '98

18 Mar '98

Dear Orit Levin, In response to your request, APC-1331 and 1332 have been allocated to your two contributions as attached. Using this opportunity, I would like to draw the attention of Editors that I have allocated APC-numbers to the draft Recommendations which should be elevated to White Contributions at the Yokosuka meeting. Please use these document numbers for your input documents. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ******************************************************************** --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 ---------------------------------------------------------------------

1 0

Migration Indication
by Euchner Martin ZT IK 3 17 Mar '98

17 Mar '98

------------------------------- Der folgende Text gilt nicht fuer SMTP und nur fuer ZT Mitarbeiter! Die MS Mail Adresse Ihres Teilnehmers "Euchner Martin ZT IK 3" ist nur noch bis Juni 98 gueltig und wurde an die neue Exchange Adresse weitergeleitet. Sie finden die neue Adresse in der globalen Adressliste - des MS Mail Client unter "Euchner Martin(Exchange)" - des Exchange Client unter "Euchner Martin" Andere Adressen finden Sie im SCD.Passe

1 0

protocolIdentifier omnipresence
by Paul Long 17 Mar '98

17 Mar '98

I was wondering, why is the protocolIdentifier field present in so many H.225.0 messages? The value must be consistent from message to message, right? In contrast, protocolIdentifier is only transmitted once, in termCapSet, in H.245. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Re: Fast Connect and mediaChannel
by Toby Nixon 17 Mar '98

17 Mar '98

Orit, your proposal seems fine to me on first reading. The way to get this into the implementor's guide would be to submit the text you have below as a written contribution to a rapporteur's meeting so that it can be approved, and then the editor of the implementor's guide will include the text. -- Toby > -----Original Message----- > From: Orit Levin [SMTP:orit@RADVISION.COM] > Sent: Thursday, March 12, 1998 7:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Fast Connect and mediaChannel > > > Toby, Jim, Pete and all others! > > > > During the implementation of Fast Connect Procedure, we found two > > pitfalls regarding the use of Transport Addresses as it are currently > > defined. For compatibility sake I provide following > clarifications > for your revision: > > > > 1. In chapter 8.1.7.1 Proposal, Selection, and Opening of Media > > Channels is written: > > "The mediaChannel element shall be set appropriately according to the > > calling endpoint requirements; different values may be used in > > alternative proposals if desired." > > > > As a part of the "Fast Connect Procedure", it is the responsibility of > > the called endpoint to decide about the coupling of proposed incoming > > and outgoing media streams for each SessionId. According to RTP/RTCP > > specifications, such a couple uses a common RTCP channel. Besides > > there are implementations, that rely on dependency between RTP and > > RTCP ports values. > > As a result of all that, "different values" for proposed (by the > > calling endpoint) mediaChannels can NOT be used within the same > > SessionId. > > It means that in the SETUP message all alternative OpenLogicalChannel > > structures, that propose a channel for transmission from the called > > endpoint to the calling endpoint, shall contain not only the same > > sessionID value but also the same mediaChannel value. > > > > 2. The "Fast Connect Procedure" doesn't explicitly define how the RTCP > > port values are provided. In order to support the general case > > (including one direction media transmission) and in accordance with > > (1) above, the following procedures shall be performed in addition to > > the described in H.323. > > > > In the SETUP message, each OpenLogicalChannel which proposes a channel > > for transmission from the calling endpoint to the called endpoint, > > shall contain mediaControlChannel element (indicating the reverse RTCP > > channel) into the H2250LogicalChannelParameters element of the > > forwardLogicalChannelParameters structure. > > In the SETUP message, each OpenLogicalChannel which proposes a channel > > for transmission from the called endpoint to the calling endpoint, > > shall contain mediaControlChannel element (indicating the RTCP channel > > going in the same direction) into the H2250LogicalChannelParameters > > element of the reverseLogicalChannelParameters structure. > > All mediaControlChannel elements inserted by the calling endpoint for > > the same sessionID for both directions shall have the same value. > > > > When accepting a proposed channel for transmission from the calling > > endpoint to the called endpoint, the called endpoint shall return the > > corresponding OpenLogicalChannel structure to the calling endpoint, > > inserting a valid mediaControlChannel element (indicating the RTCP > > channel going in the same direction) into the > > H2250LogicalChannelParameters element of the > > forwardLogicalChannelParameters structure. > > When accepting a proposed channel for transmission from the called > > endpoint to the calling endpoint, the called endpoint shall return the > > corresponding OpenLogicalChannel structure to the calling endpoint, > > inserting a valid mediaControlChannel element (indicating the reverse > > RTCP channel) into the H2250LogicalChannelParameters element of the > > reverseLogicalChannelParameters structure. > > All mediaControlChannel elements inserted by the called endpoint for > > the same sessionID for both directions shall have the same value. > > > > I propose that we put such sort of clarifications into H.323 > > Implementers Guide. > > What is your opinion and what is the procedural way to do that? > > > > Best Regards, > > Orit Levin > RADVision Inc. E Mail: orit(a)radvision.com > 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 > Mahwah, NJ 07430 Fax: 201-529-3516

1 0

Invitation to Q.12-14/16 Yokosuka meeting
by Sakae Okubo 17 Mar '98

17 Mar '98

Dear Mr. Korpi, >>I noticed that the size of the invitation file shrinks to only >>34kB(!) when I made a PDF-file of it using the Adobe Distiller. >>Since the Word-file is 19MByte, the deduction is significant... You >>may want to put it on the ftp-site. Thank you very much for your effort. I have placed it as: /9804_Yok/Invitation.pdf Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0