March 1998 - sg16-avd - lists.packetizer.com

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

H.225.0 V2 decided and Anenx D to H.323 determined
by Sakae Okubo 17 Mar '98

17 Mar '98

Dear SG16 colleagues, The subject documents are available at the following locations: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/H2250v2w.zip ftp://standard.pictel.com/avc-site/9801_Gen/H2250v2w.zip ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/h323-annexD.zip ftp://standard.pictel.com/avc-site/9801_Gen/h323-annexD.zip 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

Upcoming SG16 experts meetings in Yokosuka
by Kiyoshi SAKAI 17 Mar '98

17 Mar '98

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 **********************************************************************

1 0

New files on q11-site (lbc-site)
by Tom Geary 17 Mar '98

17 Mar '98

Forwarded to the ITU email reflector for SG16/Q.11in hopes that some if not all of the ITU member experts will get it during the time the normal q.11 reflector is not operating. Thanks, Tom Geary -------------------- Forwarded by Tom A Geary/RSS/Rockwell on 16-03-98 22:42 --------------------------- Tom A Geary 14-03-98 21:04 To: sg16.lbc(a)research.kpn.com, webberr(a)pictel.com cc: Subject: New files on q11-site (lbc-site) Dear SG16 Q.11 Experts: I have uploaded files for the proposed agendas for Yokosuka and Tampere Q.11 experts meetings, q11dtd2.doc an q11etd2.doc. Also I have assigned a number to the invitation (and in the case of Tampere, the registration) letters from our gracious hosts and have uploaded these as well, q11d01.doc for Yokosuka and q11e01.doc along with q11e05.doc for Tampere. I have also uploaded a document for each meeting, q11d04.doc and q11e04.doc which is the updated SG16 Q.11 meeting report (with change marks from the one presented in the WP2 meeting in Geneva adding missing TD numbers and revising the agenda of the Yokosuka and Tampere meetings) as discussed in the WP2 meeting. Mr. Webber: Can you move all files with q11dnn.ccc names to the /yokosuka.April98 folder and all with q11enn.ccc names to the /tampere.April98 folder. (Also you can delete file Q11_trac from the /lbc-site/dropbox, it was just a reference file for the Q.11 documents to the January Geneva meeting and .) Also please move files h223c_13_details.zip and h324c_21_details.zip to the /lbc-site/LBCmobile/documents directory. Thanks, Tom Geary

1 0

IETF iptel working group
by Scott Bradner 14 Mar '98

14 Mar '98

fyi - the IETF IPTEL working group has been formed and will be meeting during the IETF meeting in LA the end of the month. The charter for the working group, along with information about subscribing to the mailing list can be found at http://www.ietf.org/html.charters/iptel-charter.html Scott

1 0

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

13 Mar '98

------------------------------- 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 Exchange Adresse im Adressbuch - des MS Mail Clients unter "Globaler Adressliste -> Euchner Martin(Exchange)" - des Exchange Clients unter "Globaler Adressliste -> Euchner Martin". Passen Sie ggf. Ihr pers. Adressbuch an. MfG SBS CS

1 0

None
by Stefan.Leuenberger＠ASCOM.CH 13 Mar '98

13 Mar '98

subscribe itu-sg16

1 0

Request for APC-Numbers
by Sakae Okubo 12 Mar '98

12 Mar '98

Dear Mr. Korpi, In response to your request, the following APC numbers have been allocated to your three contributions: APC-1328 Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) APC-1329 Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup APC-1330 Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 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

Fast Connect and mediaChannel
by Orit Levin 12 Mar '98

12 Mar '98

> 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

Re: GK-handled call diversion.
by Korpi Markku PN VS LP3 11 Mar '98

11 Mar '98

See my in-line comments below: --Markku Korpi >-----Original Message----- >From: Michele Bozier WVdevmt-WS [SMTP:mbozier@MADGE.COM] >Sent: Wednesday, March 11, 1998 6:19 PM >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Fwd: GK-handled call diversion. > >Hi all, > >I have a question about the H450.3 Call Diversion recommendation when the >gatekeeper handles the diversion. > >Figure 12 in section 10 shows the signalling flow for Call forwarding >unconditional being handled by a gatekeeper. My concern is that the figure >shows the gatekeeper informing the 'called' user that the call has been >diverted away from it, using an H.225 Setup message. In order for this not >to create confusion, the gatekeeper must know that the called user >understands H450.2 (e.g. if the called user were a Version 1 endpoint then >it would surely wrongly interpret this Setup as an incoming call). >[MKo] The Notification Setup of H.450.2 contains in the Bearer >Capability/Octet 3 "call independent signaling connection". Since the BC is >a mandatory IE in H.323 version 1, the correct response should be Release >Complete message with Cause=Mandatory information element error. Therefore >the interpretation of the Notification as an incoming call is not legal >according to H.323 V.1. > >The text in the standard which relates to the sending of this information to >the called user (H450.2 APDU divertingLegInformation4), states that this >message is sent by the gatekeeper only if the option 'served user >notification' applies. As far as I can see, this option is a local >configuration matter at the served endpoint. My question is, how does a >gatekeeper work out whether or not this option is set in a standard way? >[MKo] The GK would have some network management functions, by means of which >the local configuration can be influenced either by the user or by the >network manager or by both. >Therefore we do not need signaling capabilities in the H.450.3 for this >purpose. > >Thanks for your help >Michele >---------------------------------------- >Michele Bozier >Principal Development Engineer >Madge Networks, Wexham Springs, Framewood Rd, Wexham, >Slough SL3 6PJ, England >Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 >email:mbozier@madge.com

1 0