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

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

Re: Minor H.225.0 Corrections
by Karl Klaghofer 30 Oct '97

30 Oct '97

Glen, I can not even imagine that the 131 as a max. size for UUIE was suitable for H.225.0V1 - was it ? (thinking on the various arguments with its sequences of alias addresses, etc.) The number 131 comes from the max. length definition of UUIE out of ISDN UU Service 2 and 3. I agree that we have to extend it in H.225.0V2. Karl ================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ================================================== 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

2 1

H.Chat vs. T.Chat: what is best for H.323?
by Toby Nixon 29 Oct '97

29 Oct '97

Many of you will recall that at the Sunriver meeting I volunteered as editor for "H.chat", the carrying of T.140 text chat over H.323. I've recently found the bandwidth to do some thinking on this, and would like to raise some issues with the group. "H.chat", as I understand it, would describe protocols and procedures for running T.140 "raw" on its own logical channel (negotiated via H.245), rather than over T.120 using the application protocol entity described in draft T.134. At first glance, it can appear that running T.140 directly on a TCP channel is simple and easy to implement, and that's probably true in the trivial point-to-point case. However, as soon as you start expanding to multipoint chat (which should be a requirement for T.140 over H.323), quite a lot of complexity is introduced, and before long you find that you're duplicating most of the functionality already provided by T.125 MCS. > Our primary concern is that if there are two (or more) ways to > implement T.140 text chatting in H.323 terminals, some implementers > will do one, and some will do the other. The result will be that at > least some portion of the users will not be able to engage in T.140 > chats with some other portion of the users. This would not be a > desirable outcome of our efforts, the goal of which is to replace > (over time) the variety of incompatible text telephone conventions > around the would with a single worldwide interoperable standard that > works over a variety of transports. Furthermore, we fear that if ITU > defines a "simpler" protocol for one data application, we'll set a > precedent that could result in demands for similar accommodation of > other data applications (such as file transfer), further dividing the > market and reducing interoperability. Why do we want to torpedo T.120 > after putting so much effort into it? Shouldn't we endeavor to > specify a single T.140 chat architecture in each H-series system, so > as to maximize interoperability and minimize the complexity of > gateways between various H-series systems? T.140 is about the purest > "data conferencing" application there is; why not use ITU's standard > data conferencing architecture as a transport? > There have been arguments against mandating T.120 by some H.323 implementers in the past, particularly in the context of T.130 discussions. However, the issue there was that some H.323 products, such as standalone phones, would need NO data capability, and they didn't want to have to implement T.120 just to participate in T.130 conference control. However, Microsoft believes that H.323 terminals that implement T.140 will be more capable devices with adequate resources to implement T.120 and fully participate in multipoint data conferences; the resource issue is not compelling. > It probably makes some sense to be able to carry T.140 directly on an > H.223 channel in H.324, since H.324 devices are fundamentally > point-to-point. But this doesn't carry over to H.323 systems, which > live in a fundamentally multipoint environment. Gateways from H.324 to > H.323 are going to have to be relatively complex anyway, and a > commercially successful gateway will require T.120 support. Adapting > T.140 on H.223 into T.140 on T.120 should not be a significant burden > to such a system. > So what are the compelling motivations for developing a standard for carrying T.140 directly on an H.323 logical channel opened using H.245, rather than within the context of T.120? In other words, why do we need H.chat when we have T.chat? -- 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 >

1 0

Minor H.225.0 Corrections
by Lior Moscovici 28 Oct '97

28 Oct '97

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

2 1

List hiccup....
by Jim Toga 28 Oct '97

28 Oct '97

Greetings, I'm aware that there is something strange going on with the listserver - I'm checking into it. I will post again when it is identified and/or resolved..... 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 1