- sg16-avd - lists.packetizer.com

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

Re: Problems with the ASN.1 Syntax in H.235
by Jim Toga 31 Oct '97

31 Oct '97

Claudio, (Thanks for the comments) Yes, I am aware of this syntax error.... in the rush to file the white paper it snuck through. It along with anything else will be corrected in Geneva. As for the second point, hmmm.....? You are correct in that the implication is that timeStamp and generalID are to be required for use in the PwdCertToken. I'll have to go back and look at the recommendation, but I thought that the current construct implies that they must be present (along with any other optional values desired). If this is incorrect, it will certainly be fixed. Regards, jimt. At 02:58 PM 10/31/97 +0100, you wrote: >While working with the H.235 ASN.1 Symtax, I found a syntax error and >also a definition which seems to be wrong: > >1. A closing ')' is missing in the line > > EncodedGeneralToken ::= TYPE-IDENTIFIER.&Type (ClearToken) -- general usage token > --------^ > >2. PwdCertToken ::= ClearToken (WITH COMPONENTS {..., timeStamp, generalID }) > > As far as I understand this line, timeStamp and generalID should be > mandatory inside a PwdCertToken (if they should still be optional > there is no need to use a WITH COMPONENTS). Without the '...' we would > have a 'FullSpecification' and in this case the above line would > mean that timeStamp and generalID are now mandatory. However, this is > a 'PartialSpecification;, in which case no PresenceConstraint means that > no constraint is imposed (see x680, 45.8.9.3). > > The correct line would therefore be > > PwdCertToken ::= ClearToken > (WITH COMPONENTS {..., timeStamp PRESENT, generalID PRESENT}) > > Is this assumption correct? > >Thanks, > >Claudio Fleiner (cfl(a)zurich.ibm.com) > > ************************************************************************* *** +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

Re: H.320
by Toby Nixon 31 Oct '97

31 Oct '97

These standards are available from the ITU, either in paper or electronic form. Ordering information is available on http://www.itu.int/publications/bookshop.htm and http://www.itu.int/publications/online.htm. Pre-publication drafts of SOME documents are available on ftp://standards.pictel.com/avc-site, but these are not indexed for easy reference but those not actively participating in SG16 work, and may be different in technically significant ways from the published text. -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com > -----Original Message----- > From: Abdur Rafay Badar [SMTP:rafay@THEOFFICE.NET] > Sent: Friday, October 31, 1997 3:23 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.320 > > Hello, > > Can you plase send me all technical information about H.320 and other > including the G. standerds for voice. > > I will really appreciate you help on this. > > Regards. > Rafay Badar

1 0

H.320
by Abdur Rafay Badar 31 Oct '97

31 Oct '97

Hello, Can you plase send me all technical information about H.320 and other including the G. standerds for voice. I will really appreciate you help on this. Regards. Rafay Badar

1 0

Re: H.Chat vs. T.Chat
by Gunnar Hellstrom 30 Oct '97

30 Oct '97

Toby Nixon asks if there really is a need for a simple logical channel approach for text chatting with T.140 in H.323, or if we could do with the T.120-based T.134 solution for all H.323 implementations. If you remember how this started in March in Geneva, I came in with the view that the T.120 solution for text conversation would mean maximum compatibility for least work. However, first recations came from the H.324 side, asking for a simple solution in a logical channel. Then, in the Herliza meeting, apparently text chatting was discussed in a group that was aiming at the simple Internet Phone applications, who said that there should be a similar solution in H.323 if I wanted full coverage in H.323 products. I agree that it complicates the implementations to have T.120 as the solution to invoke if we turn out to enter a multipoint situation, and otherwise use plain H.323 data channel for point-to-point. It is easy for Toby to say that T.120 should be the base. He usually has enough power and memory around. I would like to get the view from Internet Phone people as well. If this is the text telephone of the future, it should be suiable to attach to any implementation of voice and video telephony. On H.320 dedicated simple videophones, it seems to be common to have a connector that can be used for T.120 application attachment. Can that be the way to add T.120 to Internet phones also? A summary of Sunriver activities in the text chat area: -A general purpose character by character text chat protocol based on Unicode was determined, named T.140. -A way to carry T.140 in a simple T.120 APE was determined, named T.134. -A way to carry T.140 in a simlpe H.324 logical channel was edited into H.324 and H.245. -V.18 - the PSTN text telephone modem - was changed to point at T.140 instead of having its own presentation layer. -Work was initiated to define a way to carry T.140 in a simple data channel in H.323 - H.245 - H.225.0 If you want to take a look at T.140 and T.134, they are available in http://www.pi.se/~omnitor/standd.htm Can all H.323 producers have room for T.120LITE and T.134 ? Best regards Gunnar Hellström ------------------------------------------------ Gunnar Hellström Omnitor Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 701 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: public-www.pi.se/~omnitor ------------------------------------------------

1 0

None
by Steve Auer 30 Oct '97

30 Oct '97

My name is Steve Auer and I work at VTEL Corporation in San Jose, CA. My email ID is "sauer(a)vtel.com." A predecessor of mine, Charlie Sauer, who no longer works at VTEL, used the same email ID - - "sauer(a)vtel.com." I continue to receive mountains of unsolicited email of all types on a daily basis, which are meant for Mr. Sauer. He's told me that he has already resubscribed to his areas of interest under his new email accounts. Please remove me from your mail lists. Thank you, Steve Auer (a.k.a. "sauer(a)vtel.com")

1 0

Re: Minor H.225.0 Corrections
by Lior Moscovici 30 Oct '97

30 Oct '97

Some more corrections: The needResponse field in IRR should be OPTIONAL. The reason is that the field is completely irrelevant to IRR that is a response to IRQ. We propose to say that the field shall (may?) be included only in unsolicited IRRs, and thus its presence can indicate it is an unsolicited IRR. After a closer look we found that the altGkIspermanent is mandatory also in ARJ, BRJ, DRJ and LRJ, but optional in GRJ, RRJ and URJ. We think it should be optional in all, and appear only if the alternateGatekeeper field is also present, but in any case, the optionality has to be consistent throughout. The integrity field in GCF is defined to be a SEQUENCE OF IntegrityMechanism. It seems the intent was a single IntegrityMechanism, not a SEQUENCE, namely the one chosen by the gatekeeper. Is it so? Lior -------- On 10/28/97 02:28 PM MST ggf(a)lucent.com wrote: Lior, Thanks for the note. In addition, I have the following corrections: TimeToLive should be INTEGER(1..4294967295) instead of 4294967296. With the addition in V2 of supplementary services, fast call setup, and other items, the length of the User-user IE specified in the tables for each of the various Q.931 messages should be extended from 2-131 to something larger (any suggestions?). The callReferenceValue definition (at least in ARQ) should be modified to remove the statement that the CRV comes from the Q.931 message. If you find other needed corrections, please let me know. Glen Lior Moscovici wrote: > > There are two corrections we would like to suggest in H.225.0: > In the Endpoint structure: "destinationInfo" field should be > "remoteExtensionInfo". This was our original intent in the Sunriver > contribution, but we had a typo, we ourselves overlooked. We apologize > for the incovenience. The change has to be reflected in the ASN.1 > section. > In the INAK PDU the field altGkIsPermanent should be OPTIONAL, as it is > in all other reject PDUs. > > Sincerely, > > Lior Moscovici -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0