- sg16-avd - lists.packetizer.com

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

Fellow MS Outlook users.
by Ryan Holmqvist 28 Oct '97

28 Oct '97

Fellow MS Outlook users, When posting to reflectors with MS Outlook, *please* make sure that you turn off Tools:Options:Sending:TrackingOptions. When these are turned on, my MS Outlook *automatically* replies to the reflector when I read your email. This explains the unreadable attachments some of you have been indirectly getting from me. If anyone knows how I can make my MS Outlook not respond to people's email, please let me know. I feel guilty wasting valuable internet bandwidth that could be used to read the Dilbert Web Site ;-) Thanks, Ryan -------------------------------------------- Ryan Holmqvist Lucent Technologies (Bell Labs Innovations) Voice: (610)709-1161 Fax: (610)709-1076 Lab: (610)709-1083 email: ryanh(a)lucent.com --------------------------------------------

1 0

Read: H.245 v1 and v2 will not interoperate
by Ryan Holmqvist 27 Oct '97

27 Oct '97

1 0

Delivered: cc:Mail SMTPLINK Undeliverable Message
by Postmaster 27 Oct '97

27 Oct '97

Your message To: ITU-SG16(a)mailbag.jf.intel.com Subject: cc:Mail SMTPLINK Undeliverable Message Sent: 10/13/97 15:12:16 PM was delivered to the following recipient(s): Phillippy, John D. on 10/27/97 13:28:44 PM

1 0

Re: Registering gateway resources
by Mark Reid 24 Oct '97

24 Oct '97

Hi, The original proposal for that capability set had a "number of calls" field per data rate. During one of the evening sessions it was argued that given the complexity of gateway resources (e.g. DSP's for transcoding and the varying call capacity based on 384 or 128 calls), that the number of calls would not be included because the number of calls would be changing dynamically and no matter what structure was chosen to represent the caps, the race condition between the GK and the GW could not be fixed. Instead, the capabilities simply notify the GK that the GW is willing to accept calls of that rate. The GK is not told how many. When a GW runs out of capacity (for whatever reason) for a particular call type it can send a ResourcesAvailable 225 RAS message which no longer has that data rate included. When the GW is again available for calls of that rate, it sends the message again with that rate included. So for your questions, a gateway which can do calls at 384K or 128K would register with 64K and a multiplier of 2 and 384K with a multiplier of 1 assuming it is bonding itself. If at some point the number 2B calls rendered it without the capability to accept a 384K call, it would send a resourceAvailable message to the GK with only the 64K-2 capability (assuming it could still accept that type of call) Mark >10 instances of H.320 dataRatesSupported indicating channel rates of 64K and channel multipliers of 2,1 instance of H.320 dataRatesSupported with channel rates of 128K and channel multiplier of 10? channelrate=64, multiplier 2 (No information on max number of calls) channel rate=384, multiplier 1 The former isn't that scaleable for large systems with 100s of ports, but does allow a gatekeeper to know that it might need two E.164 numbers to make the connections. As a side question, how do you signal that you have 10 384k channels that can also be used as 30 128k channels? Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Registering gateway resources
by Pete Cordell 24 Oct '97

24 Oct '97

Dear All, When I register a gateway I have the opportunity to register a list of base channel rates and a channel multiplier. If I have a gateway that has 10 2B H.320 interfaces, assuming I want to register the ports in the same message, do I register it as: 10 instances of H.320 dataRatesSupported indicating channel rates of 64K and channel multipliers of 2, 1 instance of H.320 dataRatesSupported with channel rates of 128K and channel multiplier of 10? The former isn't that scaleable for large systems with 100s of ports, but does allow a gatekeeper to know that it might need two E.164 numbers to make the connections. As a side question, how do you signal that you have 10 384k channels that can also be used as 30 128k channels? Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Revision of APC-1327
by Sakae Okubo 24 Oct '97

24 Oct '97

Dear Q.12-14/16 experts, To send the Sunriver meeting report to Mr. Tosco and others, I have reviewed APC-1327 and found some editorial errors. The refined version is now available at the ftp site as /9709_Sun/APC-1327.zip which has change marks against the previous version. 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