November 1997 - sg16-avd - lists.packetizer.com

Q.12-14/16 meeting in April 1998
by Sakae Okubo 20 Nov '97

20 Nov '97

Dear Q.12-14/16 experts, Please note that Japan hosting committee is going to invite the subject meeting to Yokosuka during 14-17 April 1998. Fill this date in your 1998 calendar. 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 Japan ********************************************************************

1 0

SG16 meeting during 26 January - 6 February 1998
by Sakae Okubo 20 Nov '97

20 Nov '97

/// This may reach you twice since it was posted during Mr. Toga's /// // effort to solve the looping problem. /// Dear Q.12-14/16 experts, Please note that information regarding the next SG16 meeting (26 January - 6 February 1998) is available as follows: TSB Collective-letter 3/16 http://www.itu.ch/itudoc/itu-t/com16/coll/003_41377.html TSB Circular 73 http://www.itu.ch/itudoc/itu-t/circ/circ2/073_41826.html 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 Japan ********************************************************************

1 0

List problems cleared?
by Jim Toga 19 Nov '97

19 Nov '97

Hello, I would like to apologize for the recent hiccup (maybe more like accute nausea) that occured on the sg-16 list. It resulted from a site which was responding to errors back to the list as opposed to the original sender. We have tightend up loop checking on the list server which should terminate these exchanges. Please let me know (many of you already do...!) if you see anything 'funny' in the future. In addition I would like to request that anyone that has subscribed to the sg-16 list with an address that is an internal mail list exploder, verify that it behaves 'well' on internal errors. In other words, errors from internal members are not generated towards the sg-16 listserv. Best Regards, jimt. ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

MultipointCapability's in H2250Capability
by Hong Linh Truong 19 Nov '97

19 Nov '97

Could anybody help me to shed more light into the meaning of the various MultipointCapability's that have to be coded within the H2250Capability? I went through its specification in H245 and the related sections in H323 and came to the following conclusions, which I'd like to ask for comments: Point 1: receiveMultipointCapability This "indicates the receive capabilities of a terminal in a multipoint conference" (H.245 section 7.2.2.4). If I understand H323 correctly, an endpoint should only support the following four multipoint capabilities (H323 section 6.8): (i) centralized audio and centralized video, (ii) distributed audio and distributed video, (iii) centralized audio and distributed video, and (iv) distributed audio and centralized video. Control and data are always centralized. The above capabilities are coded within the mediaDistributionCapability of the receiveMultipointCapability. "Centralized" means the endpoint cannot mix/switch the media stream; the mixing/switching has to be done by means of an MP. "Distributed" means the endpoint can do the mixing itself. In case of "centralized" the endpoint can receive the mixed/switched media stream either via an unicast or a multicast address; multi-unicast is not relevant in this context. In case of "distributed" the endpoint can receive the multiple media streams either via multi-unicast or via a multicast address and do the mixing/switching itself. The support of multicast address or multi-unicast is indicated in multicastCapability and multiUniCastConference. Resumee: The H245 receiveMultipointcapability is appropriate to describe the receive capabilities of a terminal in a multipoint conference. Point 2: transmitMultipointCapability This "indicates the transmit capabilities of a terminal in a multipoint conference". >From a transmit point of view "centralized" or "distributed" are not relevant. Relevant are only whether the endpoint support multicast and/or multi-unicast. Therefore the mediaDistributionCapability (mandatory) within the transmitMultipointCapability has no meaning and I'd propose to ignore it. Point 3: receiveAndTransmitMultipointCapability After having coded the receiveMultipointCapability and transmitMultipointCapability I don't know what kind of "new" information should an endpoint put into this parameter. Since all three are mandatory I'd propose to ignore that parameter! Point 4: H323 Section 6.8.1 "Centralized multipoint capability", last sentence: "Optionally, distributedAudio and distributedVideo may be used to indicate multicast distribution of media streams". I don't understand the meaning of that sentence, which is new added to H323 version 2. I thought, distributedAudio and distributedVideo indicate the endpoint capability of mixing/switching the media streams itself. The indication of whether multicast and/or multi-unicast is supported is done by means of multicastcapability and multiUniCastConference, and not by mediaDistributioncapability as stated in that sentence. I'd appreciate if somebody could give me an explanation of that sentence. I'd also appreciate any comments to the conclusions I put together above. Regards, Linh ----------------------------------------------------------- TRUONG Hong Linh email: hlt(a)zurich.ibm.com IBM Zurich Research Laboratory tel : +41 1 724 8434 CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955

1 0

test message
by Jim Toga 18 Nov '97

18 Nov '97

Sorry about the noise - please ignore. ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Test message, ignore.
by Jim Toga 18 Nov '97

18 Nov '97

************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0