- sg16-avd - lists.packetizer.com

Re: No concensus for ASN.1 extension support (was: Re: APC-1265)
by Joerg Ott 06 Sep '97

06 Sep '97

Paul, I am wondering whether you are missing the point here. Jim and Mark have stated clearly how things are supposed to work: - H.225.0 signaling carries a protocol identifier in the mandatory part of all relevant PDUs (RAS as well as call signaling channel) - H.323/H.225.0 describe in each revesion explicitly which version of H.245 to use and which features of this to implement. (And, for clarity, this is *NOT* done in the ASN.1, but in the references section of the document!) … [View More]

1 0

[Q15-ALL] Meeting Updates
by Gary Sullivan 05 Sep '97

05 Sep '97

To all Q15/16 participants and interested parties from Q11-14/16: I have updated the Sunriver Q15 meeting plan and placed it on the Q15 ftp site (file: q15bT2r2.doc). A copy of our document registration list is also available there (file: q15b00r1.doc). The Q15 ftp site is at: ftp://standard.pictel.com/video-site/ and these documents for Sunriver are found in the sunriver.sep97 directory. Within section 2.2 of the meeting plan document is a list of all issues and documents which appear … [View More]

1 0

Re: No concensus for ASN.1 extension support (was: Re: APC-1265)
by Paul Long 05 Sep '97

05 Sep '97

Mark Reid wrote: > A H.323 Version 2 terminal will use H.225.0 Version 2 which does have a > protocol identifier which is carried in all of the Q.931 messages. > A terminal which is H.323 Version 2 will use H.245 Version 3 and will have > to support H.245 features which are called out in H.323 as mandatory. So are you saying that an endpoint can deduce the H.323 version of the remote endpoint based on the version of the underlying H.225.0 or H.245? The last time I looked, H.323 … [View More]version 1 does not specify which version of H.245 it requires. We all know (out-of-band, of course) that it has to be at least version 2, but one cannot deduce the H.323 version based on the H.245 version--a version-1 H.323 endpoint could use any version of H.245. I believe that this is also the case for H.225.0. Assuming that an endpoint cannot know the H.323 version of the remote endpoint, consider this theoretical requirement added to H.323 version 2: "An endpoint shall do X in response to message Y," and Y is represented as an ASN.1 choice extension of UserInputIndication in H.245. What if the sending endpoint relies on the X behavior, a special form of DTMF signaling via Y? The endpoint has no way of knowing whether the remote endpoint will in fact do X, because it doesn't know the H.323 version of the remote endpoint. If it knew that the remote endpoint was in fact a version-1 H.323 endpoint, it might have used fall-back DTMF signaling via message Z which is in the root extension and therefore recognized by all endpoints. And, for several reasons, the endpoint cannot rely on receiving a FunctionNotSupported indication to tell it that the remote endpoint didn't recognize Y. > H.323 > is the document which says what parts of H.245 are mandatory ... not H.245 > ... as it is used by H.310, H.324 ....etc. Now for the second problem. There is not sufficient detail in these prescriptions. For example, "H.323 endpoints shall support the syntax, semantics, and procedures of ... Logical Channel Signaling." Okay, that's clear, but what if the following happens between two version-2 H.323 terminals: A terminal specifies a capability represented by a field is not in the root extension (let's say one of those for H.263+) in an OpenLogicalChannel request, the remote terminal does not recognize extension additions up to that field and acks the open even though it does not support that capability. Whoops! The channel is established and the endpoint transmits a stream that the remote terminal cannot decode. These kinds of things will happen unless we require that endpoints support all of the ASN.1 syntax of the version of H.245 that it indicates in its protocolIdentifier field. > Version 2 lives! The sky is falling! :-) -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/ [View Less]

1 0

None
by Sakae Okubo 05 Sep '97

05 Sep '97

's message of Wed, 3 Sep 1997 10:48:47 +0200 <308240572791420003WIPLIEZ*/G=Christian/S=Wipliez/OU=lannion/PRMD=cnet/ADMD=ATLAS/C=FR/@MHS> Subject: Overhead projector BCC: okubo Dear Mr. Wipliez, >>For the Sun River meeting, I will bring slides of the CNET >>contribution. Is it OK for presenting these slides with a >>projector? Assuming you mean an overhead projector (not 35mm slide projector), I have received the meeting host's confirmation that the meeting room is … [View More]

1 0

Number of copies to bring to the Sunriver meeting
by Toby Nixon 05 Sep '97

05 Sep '97

In the original meeting invitation, contributors of documents were asked to bring 50 copies with them. Can you confirm that this is still the correct number, considering the number of participants registered? Thanks. -- 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

2 1

Re: Documents yet to be uploaded
by Pete Cordell 05 Sep '97

05 Sep '97

Dear Mr. Okubo, and SG16 members, Please be advised that due to local coordination problems we will not be >able to present APC-1287 BT Extensions to H.323 for operation over Frame Relay. I apologize for this inconvenience. Please mark this number as deleted. Regards, Pete Cordell ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 643791 ================================= >---------- >From: Sakae … [View More]Okubo[SMTP:okubo@GCTECH.CO.JP] >Sent: 03 September 1997 11:01 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Documents yet to be uploaded > >Dear Q.12-14/16 colleagues, > >Attached please find the (most likely) final list of APC-numbered >documents for the next week meeting. I have not seen the following >documents at the /Incoming directory until 9:30 Wednesday, Tokyo time; >please advise me if there is anything wrong, otherwise please upload >them as soon as possible. > >APC-1261 Editor Draft Annex C to H.323 >APC-1266 Ascend et al > Using H.323 call control for Fax over IP >APC-1287 BT Extensions to H.323 for operation over Frame Relay >APC-1288 BT Conversational URLs >APC-1289 Editor H.MediaMIB Progress Report and Draft >APC-1294 VideoServer > Observations on H.MediaMIB Draft >APC-1295 Editor Draft H.246 >APC-1296 Editor H.323 additions for H.245 Version 3 >APC-1297 PictureTel > General Comments and Proposals for H.323, H.225, > H.245, and H.450.X >APC-1309 Lucent Comments on H.323 >APC-1310 Lucent Support for the Use of AAL2 in H.323 Annex C >APC-1315 BT Comments on H.323 >APC-1316 BT Comments on H.225 >APC-1321 DataBeam > Coordinating H.323 and T.120 Conferences > >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 >******************************************************************** > > Document registration for the Sunriver meeting (8-11 September 1997) > >These documents will be uploaded to: > > ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9709_Sun/ > >and its mirror in the US: > > ftp://standard.pictel.com/avc-site/9709_Sun/ > >Please take a look at 9709_Sun.html for their availability. > >--------------------------------------------------------------------- >Number Source Provisional Title >--------------------------------------------------------------------- >APC-1250 DAVIC CFP9 - IP based technologies >APC-1251 CNET Proposal for the use of Reed-Solomon codes in H.321 > terminals. Application in video satellite > communications. Experimental results on real > communications. >APC-1252 Editor Draft ITU-T H.450.1 >APC-1253 Editor Draft ITU-T H.450.2 >APC-1254 Editor Draft ITU-T H.450.3 >APC-1255 Editor Draft H.323 Version 2 >APC-1256 Editor Draft H.332 >APC-1257 Editor Draft H.225.0 Version 2 >APC-1258 Editor Draft H.321 Version 2 >APC-1259 Editor Draft H.310 Version 2 >APC-1260 Editor Initial draft of H.bmultipoint >APC-1261 Editor Draft Annex C to H.323 >APC-1262 Microsoft et al > Specific Text Changes for Enhanced DTMF Support >APC-1263 CNET Proposal of an ATC class for terminal H.321 > version2 >APC-1264 Ascend More Accurate Call Information in the Direct Call > Model >APC-1265 Q13 Rap Overall DTMF Directions for H.323 >APC-1266 Ascend et al > Using H.323 call control for Fax over IP >APC-1267 Databeam > T.120 Security Requirements >APC-1268 MPEG Proposed Liaison between DMIF adn ITU-T SG16 TD 38 > Geneva March 1997, July 25, 1997 >APC-1269 MPEG MPEG-4 Overview, July 1997 >APC-1270 MPEG DMIF (Delivery Multimedia Integration Framework) > ISO/IEC 14496-6 WD 1.0, July 1997 >APC-1271 Siemens H.235: Message Integrity for the H.225.0 RAS > channel - Revised >APC-1272 Q.2931 Editor > Prososed Changes to Q.2931 >APC-1273 Vocaltec A URL for H.323 Calls >APC-1274 Vocaltec A URL for RAS Requests >APC-1275 Vocaltec ACF & LCF messages should contain Endpoint Type >APC-1276 Vocaltec Using the transport layer address within H.323 PDUs > for Transparent Firewall Operation >APC-1277 Vocaltec DTMF Signaling with H.323 >APC-1278 Vocaltec Access Tokens within H.323 >APC-1279 Vocaltec Dynamic Change of IP Address in Registration >APC-1280 Vocaltec A Progress UUIE for Answer Supervision >APC-1281 Vocaltec ICF Message to Enable Reliability and Security >APC-1282 Vocaltec Announcing a Q.931 message within an IRR >APC-1283 Nokia, Vocaltec > H.245 Support for GSM Speech Codecs >APC-1284 Vocaltec Corrections to the Endpoint Structure >APC-1285 BT Use of H.245 in Supplementary Services >APC-1286 BT Fast Call Setup with Minimal Change >APC-1287 BT Extensions to H.323 for operation over Frame Relay >APC-1288 BT Conversational URLs >APC-1289 Editor H.MediaMIB Progress Report and Draft >APC-1290 Editor Editors draft of H.235 >APC-1291 Mitel Re-determination of Master-Slave Status >APC-1292 Mitel Call Transfer with Consultation Call for > Gatekeeper-Routed Model >APC-1293 VideoServer > Support of ConferenceAlias in H.323 Revision 2 >APC-1294 VideoServer > Observations on H.MediaMIB Draft >APC-1295 Editor Draft H.246 >APC-1296 Editor H.323 additions for H.245 Version 3 >APC-1297 PictureTel > General Comments and Proposals for H.323, H.225, > H.245, and H.450.X >APC-1298 Rap Q12 Proposed Amendments to the common text ITU-T > Recommendation H.222.0|ISO/IEC 13818-1 >APC-1299 Japan Proposed additions to H.310 and H.245 - procedures > for intercommunication between H.310 RAST-1 and > RAST-5 terminals >APC-1300 Japan Proposed correction of Recommendation H.310 > regarding the H.3230/H.321 interoperation mode stack > of RAST-5 terminals >APC-1301 Japan Audiovisual signal processing in H.bmultipoint > Multipoint Processor >APC-1302 Cisco QoS Control in H.323 Version 2 using RSVP >APC-1303 IBM Text proposal for APC-1218 "Clarification on the > H.323 Ad-Hoc Conferencing Expansion" >APC-1304 PictureTel > "replacementFor" Text >APC-1305 Lucent H.245based, H.243-like conference session control > for H.bmultipoint >APC-1306 Intel Fast Connect Sequence for H.323 >APC-1307 Intel RTP payload alignment for H.245/IETF >APC-1308 Korea Telecom > The necessity of standardization on reliable > multicast protocol >APC-1309 Lucent Comments on H.323 >APC-1310 Lucent Support for the Use of AAL2 in H.323 Annex C >APC-1311 VideoServer > H.323 Terminal Default Call Signalling Behavior >APC-1312 ETRI Interworking consideration for H.310 terminals > supporting uni-directional services >APC-1313 ETRI Proposal for broadcast and distribution service > capability in H.310 systems >APC-1314 BT H.310 interoperability issues >APC-1315 BT Comments on H.323 >APC-1316 BT Comments on H.225 >APC-1317 BT Alternate Service Signalling >APC-1318 BT User Location Using H.225/Q.931 Signalling >APC-1319 BT Multicasting H.225/Q.931 Setup for User Location >APC-1320 BT Proposal to improve the ASN.1 syntax used for > Encryption >APC-1321 DataBeam > Coordinating H.323 and T.120 Conferences >APC-1322 CNET Position paper on network interface types for H321 > version 2 >APC-1323 CNET H323 on ISDN B channels >APC-1324 CNET H320 interface to AAL1 >APC-1325 TELES Extensions to H.245 to Support H.263 Video > Redundancy Encoding >--------------------------------------------------------------------- > [View Less]

3 3

APC-1326 uploaded
by Joerg Ott 05 Sep '97

05 Sep '97

Dear Mr. Okubo, thank you for assigning the document number. I have uploaded APC-1326 in the Incoming directory of ftp.gctech.co.jp. Best regards, Joerg ------------------------------------------------------------------------------- Joerg Ott jo(a)tzi.org Universitaet Bremen, Germany fax + 49 421 218-2085 TELES AG voice + 49 421 218-7000

1 0

Re: No concensus for ASN.1 extension support (was: Re: APC-1265)
by Mark Reid 04 Sep '97

04 Sep '97

A H.323 Version 2 terminal will use H.225.0 Version 2 which does have a protocol identifier which is carried in all of the Q.931 messages. A terminal which is H.323 Version 2 will use H.245 Version 3 and will have to support H.245 features which are called out in H.323 as mandatory. H.323 is the document which says what parts of H.245 are mandatory ... not H.245 ... as it is used by H.310, H.324 ....etc. Version 2 lives! Mark To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Mark … [View More]Reid/PicTel) From: plong(a)SMITHMICRO.COM Date: 09/04/97 08:40:45 PM Subject: Re: No concensus for ASN.1 extension support (was: Re: APC-1265) Jim Toga wrote: > You are correct in that a newer version of the protocol shall not require > older versions to comply with new functionality (and must provide backward > compatiblity). Of course. I think this is obvious. > This is not to say that a new version cannot have required > additional functionality. I am referring to H.245. The version of H.323 is not exchanged between endpoints. Therefore, there is no such thing as an H.323 version-2 (or -3 or -4, etc.) endpoint as far as another endpoint can descern, and the version of H.245, Q.931, or RAS that an endpoint advertises does not imply which H.323 version the endpoint has implemented. Therefore, how can something be mandatory in one version of H.323 but not in another if the version is not observable? But that's really a different, but just as important, issue. What I'm trying to say is that an implementation may signal support for any H.245 version and yet support whatever extensions it wishes or none at all. And remember that all _messages_ added after version 1 are extensions. There is no correlation between an endpoint's behavior and the value of the protocolIdentifier field in its termCapSet--this field is therefore useless. Don't depend on an endpoint that advertises support for H.245 version 3, for example, to exhibit any behavior required by H.245 version 3. This is because--and I wish it weren't true--an endpoint is not required to process all or any of the sequence extension additions or choice extensions defined in the version of H.245 for which it indicates support. Mr. Skran's proposal in APC-1265 that a certain form of H.245 DTMF signaling be made mandatory for H.323v2, where it is not mandatory for v1, is a case in point of the problems with versioning and ASN.1 extensions in H.245. Let's take a pont-to-point call, for example. If a terminal cannot know upon what version of H.323 the remote terminal is based and if the advertised H.245 version of the remote terminal is meaningless, how can it depend on the remote terminal recognizing and processing a particular form of H.245 DTMF signaling? The remote terminal may ignore the new syntax either because it was not defined for the version of H.245 that it supports or because the implementors simply chose not to recognize the extension additions upon which it is based. > In terms of 'version 2' compliance, I believe that when interopability > trials a run to test this, any non-conforming implementation will be > high-lighted Right, but we are informally signaling version information out-of-band at interops. In the field, however, there is no such thing as "version 2." Entities cannot depend on any version-specific behavior because, in H.323's case, the version is not available, and in H.245's case, the version is available but meaningless. Therefore, Recommendations shall be augmented or clarified in subsequent versions, but shall not be constrained. Version N+1 may include additional requirements relative to version N but shall not further constrain any version-N behavior, because N is either not known or is meaningless to another entity. > It is curious that anyone would implement v2 when it isn't > finalized. I agree. > For that matter, much of v1 isn't implemented by most of the > vendors currently showing their products. Again, it sounds like you are talking about the H.323, not H.245, although the same thing can be said about H.245. > If vendors want to utilize some of the constructs from v2 in their v1 > implementations (and other entities recognize and respond to them) there is > no 'rule' against this. Precisely--there are no rules. I'd much prefer rules to the interoperability problems I foresee when we start having implementations out there of different versions trying to talk to each other. We tried it, already, with H.324, using H.245 version 2 in a world of version-1's. We backed off because of the differing interpretations as to what was required of both the transmitting and receiving terminals. I would be happier if we required that an endpoint signaling support for version N of H.245, truely supported Decided version N of H.245. Specifically, it did not encode any extensions defined in a subsequent version, it encoded all extension additions defined in version N for a particular sequence, and it treated missing extension additions as a semantic error. I believe we would have a lot fewer problems in the months ahead if this would happen. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/ [View Less]

1 0

No concensus for ASN.1 extension support (was: Re: APC-1265)
by Paul Long 04 Sep '97

04 Sep '97

Toby Nixon wrote: > Paul Long wrote: > >> 1. It shall be mandatory for all H.323 V2 terminals to promote > >> interoperability. > > > >Please, Mr. Nilsson or Mr. Toga, correct me if I'm wrong, but I don't > >believe it can be made mandatory at this time. A newer version of a > >Recommendation can augment and clarify but cannot constrain previous > >versions. > > But a new version of a recommendation CAN add new mandatory requirements > … [View More]on terminals claiming compliance to that new version. For example, if > "X" was optional in Version 1, version 2 could make "X" mandatory for > terminals claiming compliance to version 2. Or, if "X" was mandatory in > version 1, and version 2 specifies an improved technique "XX", version 2 > could require that two version 2 terminals communicating with each other > use "XX" instead of "X" even though both implement "X" for backward > compatibility with version 1. A new version should always require > backward compatibility by continuing to mandate fallback to mechanisms > required in previous versions. Because the only version information currently exchanged between all endpoints is the H.245 protocol identifier--in particular, the version of the H.323 Recommendation is not exchanged--I assume you are referring to the version of the H.245 Recommendation "in use." And there's the rub. The protocol identifier is practically useless because extensions not in the root extension may be implemented at the vendor's discretion, "shall" or not. Case in point: Hasn't at least one vendor released product based on the Determined H.245 version 2 syntax, which is different than the Decided syntax? That means that even though this vendor's terminal advertises "version 2," it does not recognize the extension additions that were added after being Decided. Some may not need to be recognized, such as a new field in a capability; others _shall_ be recognized and processed, such as a new command. Therefore, an endpoint cannot assume that another endpoint will recognize (and therefore process) _any_ extension additions and must take this possible lack of behavior into consideration. And this is not just the behavior of an obscure implementation ;-). Correct me if I'm wrong, Dave, but I believe this is also Dave Lindbergh's interpretation. I talked with Bancroft Scott about this, and he said that a system that uses ASN.1 usually requires implementations to encode all extension additions in a particular version of the syntax for that system. IOW, an implementor can't just encode the first 5 of a possible 9 extension additions in a given version of a syntax tree. However, version information about the syntax tree is not typically presented to the receiver; therefore, the receiver cannot _expect_ a particular number of extension additions to be present. (In addition to sequence fields, this also applies to choices not in the root extension.) In other words, all extension additions are in a sense optional (of course, there cannot be a gap in a sequence of fields), and all implementations must be able to handle this. Transmitters must not assume that a message (a choice) or field (a choice or sequence component) not in the root extension will be recognized by the receiver, and receivers must not treat the absence of an extension addition as an error. I don't like this. I would prefer that if an endpoint advertises that it supports version N syntax, it supports _all_ of version N syntax, and other endpoints can rely on that support. For example, if an endpoint receives only 5 of the 9 extension additions defined in the version of the H.245 syntax tree that the transmitting endpoint advertised that it supports, it shall treat it as an error--a malformed message. Likewise, a transmitting endpoint can assume that a receiver that advertises support for version N syntax will recognize and process, according to the applicable Recommendations, all extensions defined in that version of the tree. I believe that there is a serious ommission in the Recommendations about what to do about extensions. We must come to some concensus about what the rules are and document them. Soon. I meant to prepare a contribution for Sunriver about this; however, I have not had the time due to circumstances beyond my control. Back to the original problem, since the only version information exchanged between terminals is for H.245 and since receiving terminals are free to implement whatever extensions they wish to, I go back to my original assertion. A newer version of the H.245 Recommendation can augment and clarify but cannot constrain previous versions. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/ [View Less]

2 2

Re: APC-1295, 1296, and 1297
by Mark Reid 04 Sep '97

04 Sep '97

Dear Mr. Okubo, I have placed apc-1295.doc, apc-1296.doc, and apc-1297.doc in the Incoming directory of the gctech ftp site. Mark Reid PictureTel Corporation 100 Minuteman Drive M/S 713 Andover MA 01810 USA office: +1 508-292-5863 fax: +1 508-292 3309 reid(a)pictel.com

1 0