June 1998 - sg16-avd - lists.packetizer.com

subscribing to H.323 mailing list
by Viswanath Math 01 Feb '99

01 Feb '99

Hi I would like to suscribe to your mailing list for discussions on H.323. Thanks Viswanath

3 2

Re: ASN.1 accross revisions
by Pete Cordell 30 Jun '98

30 Jun '98

Dear All, I admit that I am only just hanging in there with this debate, but I think I have a possible solution 5 to throw in as a contender. Looking at the problem a bit laterally, we have RasMessage in UDP packets that we want to sign, and H323-UserInformation in the UUIE that we want to sign. Currently these are the only chunks of ASN.1 in these fields. We could add a second piece of ASN.1 into these fields (UDP packet and UUIE) that contains the signatures, such as: H323Extra ::= CHOICE { icv ICV, ... } This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you would get: RasMessage chunk of ASN.1 H323Extra chunk of ASN.1 typically containing signature Similarly in the UUIE, you would have H323-UserInformation chunk of ASN.1 H323Extra chunk of ASN.1 Note that all the key ids and time stamps etc., would remain in the RasMessage and H323-UserInformation parts (so they get signed). I agree this is not beautiful, but it does not require multiple ASN.1 encodings, and doesn't radically change the format of the message depending on whether you want to sign it or not (as solution 4 seems to). I hope this sounds vaguely as though I know what I'm talking about!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Bancroft Scott[SMTP:baos@OSS.COM] >Sent: 28 June 1998 17:35 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: ASN.1 accross revisions > >On Wed, 24 Jun 1998, Pekka Pessi wrote: > >> The current H.225.0 algorithm for calculating the ICV does not work well >> with the PER extension mechanism. > >Agreed. > >> The above algorithm (AFAIK I have understood it correctly) assumes that >> the sender and receiver can encode the PDU exactly in the same way. >>It is >> a reasonable assumption, as PER produces only one possible (canonical) >> encoding for given PDU. > >PER is not inherently canonical. To get canonical behavior you have to >either do as this set of standards have been doing and stay away from >types REAL and SET OF, or you have to use Canonical PER Aligned or >Canonical PER Unaligned. > >> However, there is a serious problem: the >> canonical representation changes if the ASN.1 SEQUENCE type is extended >> later. > >Correct. > >> When encoding this, the length of extension bitfield is 2. However, >> recipient B is using extended version of Foo like this: >> >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL >> } > >A lot of research has gone into how to most effectively create ICV's >by the designers of the Secure Electronic Payment protocol (SET), >e-check protocol and others. That's why in SET you see the likes of: > > UnsignedCertificate ::= SEQUENCE { > version [0] CertificateVersion, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier >{{SignatureAlgorithms}}, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo >SubjectPublicKeyInfo{{SupportedAlgorithms}}, > issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, > subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, > extensions [3] Extensions -- Required for SET >usage > } > > -- Compute the encrypted hash of this value if issuing a >certificate, > -- or recompute the issuer's signature on this value if validating >a > -- certificate. > -- > EncodedCertificate ::= TYPE-IDENTIFIER.&Type (UnsignedCertificate) > > Certificate::= SIGNED { > EncodedCertificate > } ( CONSTRAINED BY { -- Verify Or Sign Certificate -- } ) > > SIGNED { ToBeSigned } ::= SEQUENCE { > toBeSigned ToBeSigned, > algorithm AlgorithmIdentifier {{SignatureAlgorithms}}, > signature BIT STRING > } > >The key thing to notice is that they DO NOT attempt to sign the >unencoded >certificate (i.e., UnsignedCertficate). The actual signing occurs on >an >open type which has been constrained to carry the value of the >particular >type that is to be signed (TYPE-IDENTIFIER.&Type >(UnsignedCertificate)). >In so doing, a) they clearly identify that the type should be encoded >independently of the ICV, b) they avoid having to do a re-encode of the >data after the CRV has been calculated, c) the type to which the ICV is >to >be applied can be extended with no problem, and d) they prepared >themselves for the possible use of PER by utilizing an open type to >carry >the value to be signed - something that is *crucial* to signing >PER-encoded data. > >> Problems with Non-OPTIONAL Extensions >> >> Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL >> extensions. Let us assume that software C uses following ASN.1 >>definition >> for Foo: >> >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType >> } >> >> There are two kinds of problems with an extension like >>criticalExtension. >> First, the encoder may try to ensure that all encoded PDUs conform >>to the >> specification and signal an error when a PDU without >>criticalExtension is >> encoded. > >That's the correct behavior only if you are originating a message. >Encoders should not complain about criticalExtension being absent >if they are not originating the message. > >> Another problem is that the intermediate representation produced >> by the ASN.1 compiler may not provide means for application to express >> that criticalExtension is not present. (In other words, the produced >> structure usually contains a flag telling whether an optional field is >> present or not. Such flags are not included when the field is not >> optional.) > >It is an error for encoders not to encode extension additions that are >mandatory but missing if such extension additions do not occur within >an >extension addition group and if no other extension addition values >follow >the missing but mandatory extension. (I don't believe H.225 employs >extension addition groups (i.e., the "[[" and "]]" notation.)) This is >indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which >unconditionally mandates that it be possible for decoded components >that >are defined to both the sender and receiver be re-encodable by the >receiver. > >> The presense or absence of the OPTIONAL flag in an extension does not >> change the PER encoding of the SEQUENCE. In order to avoid previously >> mentioned problems, application may use a version of ASN.1 notation that >> has extra OPTIONAL keyword after each extension. > >Neat! A nice and simple solution for use with such compilers. > >> Solution 1: Clarification to the PER Encoding Process >> >> The text in PER document (X.691, 1994) is somewhat ambiguous how many >> bits should be included in the extension present bitfield of >>SEQUENCE. To >> quote verbatim: "Let the number of extension additions in the type being > >Note that it says the *type* being encoded, not the value. That's >distinct from the value. > >> encoded be "n", then a bit-field with "n" bits shall be produced for >> addition to the field-list." (Is the "type being encoded" the abstract >> syntax or an actual value like { bar 1, baz 2 }?) However, the 0 >>bits at >> the end of extension present bitfield can be left out without changing >> the resulting semantics: the corresponding extensions are not present. > >It is true that they can be left out without changing the semantics, >but >this is not what PER mandates (It should have mandated what you >suggest, >but hindsight is 20-20.) Unless everyone encodes according to PER its >canonical nature will be lost. > >> As a result, the PER encoding does not change after a new extension >> is added to the ASN.1 specification. >> This solution, while leaving H.225.0 v2 protocol as it is, requires >> however changes to some existing ASN.1 compilers, and in a pessimal >>case, >> to the X.691 standard text, too. > >Yes, this would work, but as you point out, it requires that PER be >changed. > >> Solution 2: Hack >> >> The receiving application does not decode and the re-encode the PDU, but >> rather removes the ICV from the encoded PDU. In practice, this >>requires that >> application can identify PER-encoded fields within the PDU and it can >> regenerate them, i.e. it has effectively the same functionality as >>a PER >> encoder/decoder. >> >> Solution 3: Calculating ICV Differently >> >> The following algorithm for generating and checking the ICV makes it >> possible to avoid all the previously mentioned problems. The >>problems are >> avoided by breaking the protocol layering, the application changes >>directly >> the PER-encoded PDU: >> >> integrityCheckValue - provides improved message integrity/message >> authentication of the RAS messages. The cryptographically based >> integrity check value is computed by the sender applying a >> negotiated integrity algorithm and the secret key upon the entire >> message. Prior to integrityCheckValue computation an ICV with a >> previously agreed magic value (or key when using MDC) will be >> inserted to this field. The magic value will contain same >> algorithmOID and exactly as many bits in the icv BIT STRING as the >> computed value. After computation, the sender replaces the magic >> value with the computed integrity check value and transmits >> message. The receiver decodes message, replaces the received >> integrity value with the magic value, calculates the ICV and >> compares it with the received value. >> >> NOTE: The sender or receiver can encode the ICV separately and replace >> it directly within the encoded PDU, when the magic ICV and computed >> ICV have exactly the same length. When replacing ICV value within >> an encoded PDU, re-encoding the whole PDU can be avoided. > >I don't like this too much because of the possibility, though low, >of the data containing the magic ICV value. Still I prefer it to >solutions 1 and 2. > >> Solution 4: >> >> Fourth alternative is to treat encoded RasMessage as octet string. IVC >> can be calculated over that octet string and appended to the PDU on >> separate layer. E.g., RAS PDU could be defined as follows: >> >> RasMessage ::= CHOICE { >> -- all previous RasMessage CHOICEs are here >> authenticatedRasMessage SEQUENCE { >> plainRasMessage OCTET STRING, >> ivc IVC, >> ... >> } >> } > >This is effectively what is done in SET and other security-conscious >protocols, though they typically use open type instead of octet string. > >Alternate Solution 1: > >To do exactly as is done in SET, you would define RasMessage without an >ICV, and define a container, AuthenticatedRasMessage, say, that carries >the encoded RasMessage as an open type value (i.e., octet-aligned, and >padded with 0-bits at the end to ensure that it is an integral multiple >of >8 bits) followed by the ICV value. In other words: > > AuthenticatedRasMessage ::= SEQUENCE { > plainRasMessage TYPE-IDENTIFIER.&Type (RasMessage), > ivc IVC > } > >Using this approach, the RasMessage (which would be defined without an >ICV) would be encoded, then the ICV would be calculated using the >encoded >RasMessage, then AuthenticatedRasMessage would be encoded. This >approach >is efficient because RasMessage does not have to be encoded without >the ICV value then re-encoded with it, nor does it require that the >encoded value be tinkered with in any way. > >This technique is good only if backward compatibility is not an issue >(i.e., if you don't already have a deployed version of H.225), for the >open type carries a length component than an ordinary encoded >RasMessage >does not have. > >Alternate Solution 2: > >If backward compatibility is an issue then Solution 4 above is a better >alternative, though I would change it to: > > RasMessage ::= CHOICE { > -- all previous RasMessage CHOICEs are here > authenticatedRasMessage AuthenticatedRasMessage > } > >Open type and octet string produce identical encodings, but I have a >preference for the open type notation because it allows you to clearly >identify what the value is - in this case an encoded RasMessage, and >because it can simplify implementations that may not have a need to >authenticate the RasMessage upon decoding (e.g., line monitors.) > >I am not intimate with H.225, so I don't know for sure of Solution 4 >or this minor variation is backward compatible. It is if the ICV was >just introduced, else I don't think it is. > >------------------------------------------------------------------------ >-- >Bancroft Scott Toll Free >:1-888-OSS-ASN1 >Open Systems Solutions, Inc. >International:1-609-987-9073 >baos(a)oss.com Tech Support >:1-732-249-5107 >http://www.oss.com Fax >:1-732-249-4636 >

2 1

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 30 Jun '98

30 Jun '98

Dear Mr. Toga: Yes, I agreed to bring more concrete proposals along the line that I stated. A good amount of work is needed in this area. Sincerely, Radhika R. Roy AT&T > ---------- > From: Jim Toga[SMTP:jim.toga@INTEL.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, June 29, 1998 3:51 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Report of the Cannes meeting > > Dear Mr Roy, > > Although I was unable to attend the meeting in Cannes, I have read all the > previous reports and have spoken to a number of people that attended. > There were many discussions during the meeting, which are summarized in > the meeting report without re-hashing every detail. My understanding is > that there were no objections from _anyone_ else at the meeting to > progressing the work that has been started in APC-1422. The intent will > be > to have both telephone and email exchanges to further develop this work. > I would look forward to having your constructive input as we move forward. > In the spirit of this, I would like to elicit your input here. > > I would like to point out a couple of misconceptions you might have based > upon the text below and ask you for some concrete proposals in areas where > you feel they're needed... > > Best Regards, > jimt. > > > [SNIP] > > > > >Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > > > >APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > > > >Mr. Roy also pointed out the following: > > If these points were raised in the APC document and covered during the > meeting why do they need to be called out explicitly in the meeting > report? > The list of contributed documents is part of the meeting. > > > > > * H.323 signaling schemes that were developed for > >H.323v1 in view of the LAN-based single GK model > > Both v1 and v2 have never limited GK deployment to one entity (on the LAN > or any other topology) The defined signalling for address resolution > allows for N gatekeepers. > > >(signaling schemes in > >H.323v2 also remain almost the same so far the inter-GK communication is > >concerned) may not be good enough to satisfy all needs when it is applied > in > >the context of multiple gatekeeper environment with different inter-GK > >architectures: Distributive, Centralized, and Hybrid (Distributive + > >Centralized). > > (I think you mean 'Distributed' above) In any case, these different > modes > of operation define models with respect to _media_ distribution, not > control. In this case they would (and do) affect the operation of an MCU. > (this is not to say that the MCU can't be co-located with the GK). > > V1 and V2 (and certainly the intent with V3) allow for many different GK > topologies with hierarchical being one of the more general ones. Flat > peer-peer models may be accomplished by having a degenerative 'hiearchy' > with a depth of 1. > > > * Each inter-GK architecture may need different > >signaling schemes in order to optimize the use of communication resources > >especially in the context large networks for both connectionless and > >connection oriented networks. > > Can you eloborate on this? Are you simply saying that we need to allow > both UDP and TCP signalling (which is in fact specified in section 4 of > APC-1422). > > > > > >APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper > >Communications" > > > >During the discussion of Intel's contribution, Mr. Roy also pointed out > that > >this proposal appears to have the following limitations: > > > > * The relationship between the zone (or internal) > and > >the border (or domain) gatekeeper is not defined: is it hierarchical or > >what? > > As described in section 2 of APC-1422 the only difference (in terms of > protocol interactions) between a GK acting as 'border GK' and an > 'internal' GK is that fact that the border GKs may communicate with border > GKs from other administrative domains. There are no specific models of > deployment within an admistrative domain. Some organizaitons will choose > to develop a hierachical model, others may choose to have a star topology, > or perhaps a flat domain. It makes no difference to the signalling > between > administrative domains and the current signalling can facilitate all of > these models. Can you offer any specific topologies that you believe > will > not work and cannot exploit this signalling? > > > * Does it mandates the use of proprietary protocols > >between the zone (or internal) and domain (or border) gatekeeper? > > It certainly does not _disallow_ proprietary protocols, but the intent > would be to support standard messages internal to an adminstrative domain > (which may be made up of a number of zones BTW...) as well as using these > standard messages between administrative domains. > > > > * The relationship between the multiple domain > >gatekeepers has not been defined: how communications occur in view of the > >multiple domain gatekeepers? > > The definition of 'relationship' is multi-faceted. Many of the aspects of > a 'relationship' may in fact be business related, and outside this realm. > One of the points of annex G is to provide some signalling which will > allow > administrative domains (again an organizational term, not a formal H.323 > topology term) to exchange information so that they can define the > "relationship between the multiple domain..." > > > > > * As if it mandates a specific implementation > scheme > >that may limit its scalability once one starts to use the gatekeeper > >discovery, address translation, admission control, and/or bandwidth/QOS > >control signaling messages for this particular architecture while a large > >network that may use highly distributive, centralized, and hybrid > inter-GK > >architecture. > > I'm really not sure what you asking/saying here...can you clarify this? > > > > >Therefore, Mr. Roy has the following view: > > > > * It requires a fundamental understanding of the > >logical relationships for inter-GK communications in view of the > >distributive, centralized, and hybrid inter-GK architecture that might be > >scaleable in view of large networks for both connectionless and > connection > >oriented networking environment. > > I think you mixing a number of things here (some of which have no > relevance). Can you break this up unto a number simple points - so that a > simple person such as I can understand? :-) > > > > * AT&T's contribution (APC-1382) has been the first > >step in that direction. > > You may note that a number of the definitions and clarificaitons from > Yokuska to Cannes were a direct result of APC-1382 - thank you. > > > > >------------------------------------------------------------------------- > --- > >------------------------------------------------------------------------- > --- > >--- > > > >I would appreciate a prompt action from your end. > > > >Sincerely, > > > >Radhika R. Roy > >AT&T > >Room 1K-330 > >101 Crawfords Corner Road > >Holmdel, NJ 07733 > >Tel: +1 732 949 8657 > >Fax: + 1 732 949 8569 > >e-mail: rrroy(a)att.com > > > > > >> ---------- > >> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > >> Reply To: Mailing list for parties associated with ITU-T Study > Group > >> 16 > >> Sent: Thursday, June 25, 1998 11:49 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Report of the Cannes meeting > >> > >> Dear Q.12-14/16 experts, > >> > >> I have uploaded draft report of the Cannes meeting (APC-1425) at the > >> /Incoming directory. > >> > >> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > >> /APC-1425_w95.zip > >> > >> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > >> with Word 97. w95 is a version converted into Word 6/95; there are > >> obvious errors in section numbering and figures. > >> > >> Please review it in a week time, and give me any comments. I will then > >> complete it, uploade it at /9806_Can directory and send its copies to > >> the SG16 management. > >> > >> Best regards, > >> > >> Sakae OKUBO (Mr.) > >> *********************************************************** > >> Waseda Research Center > >> Telecommunications Advancement Organization of Japan (TAO) > >> 5th Floor, Nishi-Waseda Bldg. > >> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > >> 169-0051 Japan > >> Tel: +81 3 5286 3830 > >> Fax: +81 3 5287 7287 > >> e-mail: okubo(a)giti.or.jp > >> *********************************************************** > >> > > > > > > ***************************************************** > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@itu.ch > *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > ***************************************************** >

1 0

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 30 Jun '98

30 Jun '98

Dear Mr. OKUBO: With respect to the report (APC-1425) of the Cannes meeting, I would appreciate if you would add the following for the completeness of the report: ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------- Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" Mr. Roy also pointed out the following: * H.323 signaling schemes that were developed for H.323v1 in view of the LAN-based single GK model (signaling schemes in H.323v2 also remain almost the same so far the inter-GK communication is concerned) may not be good enough to satisfy all needs when it is applied in the context of multiple gatekeeper environment with different inter-GK architectures: Distributive, Centralized, and Hybrid (Distributive + Centralized). * Each inter-GK architecture may need different signaling schemes in order to optimize the use of communication resources especially in the context large networks for both connectionless and connection oriented networks. APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper Communications" During the discussion of Intel's contribution, Mr. Roy also pointed out that this proposal appears to have the following limitations: * The relationship between the zone (or internal) and the border (or domain) gatekeeper is not defined: is it hierarchical or what? * Does it mandates the use of proprietary protocols between the zone (or internal) and domain (or border) gatekeeper? * The relationship between the multiple domain gatekeepers has not been defined: how communications occur in view of the multiple domain gatekeepers? * As if it mandates a specific implementation scheme that may limit its scalability once one starts to use the gatekeeper discovery, address translation, admission control, and/or bandwidth/QOS control signaling messages for this particular architecture while a large network that may use highly distributive, centralized, and hybrid inter-GK architecture. Therefore, Mr. Roy has the following view: * It requires a fundamental understanding of the logical relationships for inter-GK communications in view of the distributive, centralized, and hybrid inter-GK architecture that might be scaleable in view of large networks for both connectionless and connection oriented networking environment. * AT&T's contribution (APC-1382) has been the first step in that direction. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- --- I would appreciate a prompt action from your end. Sincerely, Radhika R. Roy AT&T Room 1K-330 101 Crawfords Corner Road Holmdel, NJ 07733 Tel: +1 732 949 8657 Fax: + 1 732 949 8569 e-mail: rrroy(a)att.com > ---------- > From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, June 25, 1998 11:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Report of the Cannes meeting > > Dear Q.12-14/16 experts, > > I have uploaded draft report of the Cannes meeting (APC-1425) at the > /Incoming directory. > > ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > /APC-1425_w95.zip > > w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > with Word 97. w95 is a version converted into Word 6/95; there are > obvious errors in section numbering and figures. > > Please review it in a week time, and give me any comments. I will then > complete it, uploade it at /9806_Can directory and send its copies to > the SG16 management. > > Best regards, > > Sakae OKUBO (Mr.) > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > *********************************************************** >

2 1

Re: Report of the Cannes meeting
by Jim Toga 29 Jun '98

29 Jun '98

Dear Mr Roy, Although I was unable to attend the meeting in Cannes, I have read all the previous reports and have spoken to a number of people that attended. There were many discussions during the meeting, which are summarized in the meeting report without re-hashing every detail. My understanding is that there were no objections from _anyone_ else at the meeting to progressing the work that has been started in APC-1422. The intent will be to have both telephone and email exchanges to further develop this work. I would look forward to having your constructive input as we move forward. In the spirit of this, I would like to elicit your input here. I would like to point out a couple of misconceptions you might have based upon the text below and ask you for some concrete proposals in areas where you feel they're needed... Best Regards, jimt. [SNIP] > >Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > >APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > >Mr. Roy also pointed out the following: If these points were raised in the APC document and covered during the meeting why do they need to be called out explicitly in the meeting report? The list of contributed documents is part of the meeting. > > * H.323 signaling schemes that were developed for >H.323v1 in view of the LAN-based single GK model Both v1 and v2 have never limited GK deployment to one entity (on the LAN or any other topology) The defined signalling for address resolution allows for N gatekeepers. >(signaling schemes in >H.323v2 also remain almost the same so far the inter-GK communication is >concerned) may not be good enough to satisfy all needs when it is applied in >the context of multiple gatekeeper environment with different inter-GK >architectures: Distributive, Centralized, and Hybrid (Distributive + >Centralized). (I think you mean 'Distributed' above) In any case, these different modes of operation define models with respect to _media_ distribution, not control. In this case they would (and do) affect the operation of an MCU. (this is not to say that the MCU can't be co-located with the GK). V1 and V2 (and certainly the intent with V3) allow for many different GK topologies with hierarchical being one of the more general ones. Flat peer-peer models may be accomplished by having a degenerative 'hiearchy' with a depth of 1. > * Each inter-GK architecture may need different >signaling schemes in order to optimize the use of communication resources >especially in the context large networks for both connectionless and >connection oriented networks. Can you eloborate on this? Are you simply saying that we need to allow both UDP and TCP signalling (which is in fact specified in section 4 of APC-1422). > >APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper >Communications" > >During the discussion of Intel's contribution, Mr. Roy also pointed out that >this proposal appears to have the following limitations: > > * The relationship between the zone (or internal) and >the border (or domain) gatekeeper is not defined: is it hierarchical or >what? As described in section 2 of APC-1422 the only difference (in terms of protocol interactions) between a GK acting as 'border GK' and an 'internal' GK is that fact that the border GKs may communicate with border GKs from other administrative domains. There are no specific models of deployment within an admistrative domain. Some organizaitons will choose to develop a hierachical model, others may choose to have a star topology, or perhaps a flat domain. It makes no difference to the signalling between administrative domains and the current signalling can facilitate all of these models. Can you offer any specific topologies that you believe will not work and cannot exploit this signalling? > * Does it mandates the use of proprietary protocols >between the zone (or internal) and domain (or border) gatekeeper? It certainly does not _disallow_ proprietary protocols, but the intent would be to support standard messages internal to an adminstrative domain (which may be made up of a number of zones BTW...) as well as using these standard messages between administrative domains. > * The relationship between the multiple domain >gatekeepers has not been defined: how communications occur in view of the >multiple domain gatekeepers? The definition of 'relationship' is multi-faceted. Many of the aspects of a 'relationship' may in fact be business related, and outside this realm. One of the points of annex G is to provide some signalling which will allow administrative domains (again an organizational term, not a formal H.323 topology term) to exchange information so that they can define the "relationship between the multiple domain..." > * As if it mandates a specific implementation scheme >that may limit its scalability once one starts to use the gatekeeper >discovery, address translation, admission control, and/or bandwidth/QOS >control signaling messages for this particular architecture while a large >network that may use highly distributive, centralized, and hybrid inter-GK >architecture. I'm really not sure what you asking/saying here...can you clarify this? > >Therefore, Mr. Roy has the following view: > > * It requires a fundamental understanding of the >logical relationships for inter-GK communications in view of the >distributive, centralized, and hybrid inter-GK architecture that might be >scaleable in view of large networks for both connectionless and connection >oriented networking environment. I think you mixing a number of things here (some of which have no relevance). Can you break this up unto a number simple points - so that a simple person such as I can understand? :-) > * AT&T's contribution (APC-1382) has been the first >step in that direction. You may note that a number of the definitions and clarificaitons from Yokuska to Cannes were a direct result of APC-1382 - thank you. > >---------------------------------------------------------------------------- >---------------------------------------------------------------------------- >--- > >I would appreciate a prompt action from your end. > >Sincerely, > >Radhika R. Roy >AT&T >Room 1K-330 >101 Crawfords Corner Road >Holmdel, NJ 07733 >Tel: +1 732 949 8657 >Fax: + 1 732 949 8569 >e-mail: rrroy(a)att.com > > >> ---------- >> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] >> Reply To: Mailing list for parties associated with ITU-T Study Group >> 16 >> Sent: Thursday, June 25, 1998 11:49 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Report of the Cannes meeting >> >> Dear Q.12-14/16 experts, >> >> I have uploaded draft report of the Cannes meeting (APC-1425) at the >> /Incoming directory. >> >> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip >> /APC-1425_w95.zip >> >> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) >> with Word 97. w95 is a version converted into Word 6/95; there are >> obvious errors in section numbering and figures. >> >> Please review it in a week time, and give me any comments. I will then >> complete it, uploade it at /9806_Can directory and send its copies to >> the SG16 management. >> >> Best regards, >> >> Sakae OKUBO (Mr.) >> *********************************************************** >> Waseda Research Center >> Telecommunications Advancement Organization of Japan (TAO) >> 5th Floor, Nishi-Waseda Bldg. >> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo >> 169-0051 Japan >> Tel: +81 3 5286 3830 >> Fax: +81 3 5287 7287 >> e-mail: okubo(a)giti.or.jp >> *********************************************************** >> > > ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@itu.ch *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

Re: ASN.1 across revisions
by Paul Long 29 Jun '98

29 Jun '98

>From: Bancroft Scott[SMTP:baos@OSS.COM] >On Sun, 28 Jun 1998, Paul Long wrote: >> So, Bancroft, are you saying that it would be an error if FooGone, >> below, were encoded where Foo was called for? >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType >> } >> FooGone ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL >> } >X.691:1997 clause 24.14 (X.691:1994 Amd.1 clause "11 >Changes to SEQUENCE") stipulates that if you are originating an encoding >(i.e., not relaying it) you are required to encode criticalExtension. Right, that's what I meant. I should have said, "Are you saying that--if originating the encoding--it would be an error if FooGone were encoded where Foo was called for?" With this qualification, your answer would apparently be, "Yes, it would be an error." > >> Likewise, are you saying that it would be an error if FooOpt, below, >> were encoded, without the value of criticalExtension present, in place >> of Foo, because the extension addition is mandatory in Foo? >> FooOpt ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType OPTIONAL >> } >This change to the type is transparent to the communicating peer. Indeed, >unless you go out of your to indicate to the encoder whether you are >originating and encoding it is impossible in ASN.1:1994 for an encoder to >know whether the absence of criticalExtension is an error. Hey, I just realized something. When you say, "encoder," you are referring strictly to the ASN.1 encoder, right? I often think of the encoder as the larger, "encoding entity," such as an H.323 endpoint, which usually knows more than the encoder. I think you call this the "sender." So if the encoder, using your definition, is presented with FooOpt, above, and a value is not provided to the encoder for criticalExtension, the encoder does not, of course, know that this is an error. What I'm saying is that if the sender, or encoding entity, uses FooOpt in place of Foo, and the value for criticalExtension is not present, the encoder is not at fault for producing an encoding, but the sender is at fault, because it is not using the prescribed definition of Foo for the version of the Recommendation of which it is an implementaion and which is identified in the protocolIdentifier field(s). To look at it from the other direction, the receiver, or decoding entity, doesn't care whether the encoder or the sender is at fault--it just knows that the sender is producing an incorrect encoding. >it is impossible in ASN.1:1994 for an encoder to >know whether the absence of criticalExtension is an error. In ASN.1:1997 >this imprecision is resolved by the use of version brackets. For example, >if you wrote: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > [[, > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL, > criticalExtension OtherType, > ]] > } > >it would be clear that baz - criticalExtension were all added in the same >version, so if any of the optional items are present then criticalExtension >must also be present. Can't the same thing be done in ASN.1:1994 by encapsulating the extension additions of a particular version within a SEQUENCE like this? FooEncap2 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, criticalExtension OtherType } } and this? FooEncap3 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL }, SEQUENCE { importantExtension SomeType OPTIONAL, criticalExtension OtherType } } Seems like this would allow one to produce the same encoding with ASN.1:1994 as what would be produced by the version brackets in ASN.1:1997, or am I missing something? Perhaps this is how we should extend ASN.1 types in the future. > >> So are you saying that if an ASN.1 type in a Recommendation contains an >> extension addition, such as criticalExtension in Foo, above, an >> implementation of that Recommendation _must_ represent that extension >> addition in all encodings of that type? >It is in error only if you are originating the encoding in which >criticalExtension is defined. Okay, yes, I meant that one is originating the encoding. That's really the only way I think about encoding. Again, with this qualification, your answer would be, "Yes, it would be an error." >ASN.1:1994 does not have syntax that makes >it possible for an encoder to determine whether criticalExtension is >unconditionally mandatory (it would be if all four extension additions >were added in the same version), or if it were added after the other >extension additions (in which case it would be mandatory only if the >sender is originating the message.) I'm saying that all four are defined in the same version of ASN.1 syntax and that the sender is originating the message. > >> If so, I assume this would be because, technically, >> another type was being encoded, not the one defined in the >> Recommendation, as in "Let the number of extension additions in _the >> type being encoded_ be 'n'..." >I don't follow what you mean here. Sorry. I meant that this citation from 18.7/X.691:1994 indicates to me that, for an originator, all extension additions defined for a type must be represented--one cannot simply leave off one or more trailing extension additions from a type that is defined in the version of the Recommendation that the sender has implemented, as would be the case if FooGone were used in place of Foo, for example. Likewise, for an originator, Foo is "the type being encoded," and an invalid encoding would be produced if FooOpt was used in place of Foo, and a value was not provided for criticalExtension. Paul Long

1 0

Re: ASN.1 accross revisions
by Bancroft Scott 29 Jun '98

29 Jun '98

On Wed, 24 Jun 1998, Pekka Pessi wrote: > The current H.225.0 algorithm for calculating the ICV does not work well > with the PER extension mechanism. Agreed. > The above algorithm (AFAIK I have understood it correctly) assumes that > the sender and receiver can encode the PDU exactly in the same way. It is > a reasonable assumption, as PER produces only one possible (canonical) > encoding for given PDU. PER is not inherently canonical. To get canonical behavior you have to either do as this set of standards have been doing and stay away from types REAL and SET OF, or you have to use Canonical PER Aligned or Canonical PER Unaligned. > However, there is a serious problem: the > canonical representation changes if the ASN.1 SEQUENCE type is extended > later. Correct. > When encoding this, the length of extension bitfield is 2. However, > recipient B is using extended version of Foo like this: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL > } A lot of research has gone into how to most effectively create ICV's by the designers of the Secure Electronic Payment protocol (SET), e-check protocol and others. That's why in SET you see the likes of: UnsignedCertificate ::= SEQUENCE { version [0] CertificateVersion, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier {{SignatureAlgorithms}}, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo{{SupportedAlgorithms}}, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions -- Required for SET usage } -- Compute the encrypted hash of this value if issuing a certificate, -- or recompute the issuer's signature on this value if validating a -- certificate. -- EncodedCertificate ::= TYPE-IDENTIFIER.&Type (UnsignedCertificate) Certificate::= SIGNED { EncodedCertificate } ( CONSTRAINED BY { -- Verify Or Sign Certificate -- } ) SIGNED { ToBeSigned } ::= SEQUENCE { toBeSigned ToBeSigned, algorithm AlgorithmIdentifier {{SignatureAlgorithms}}, signature BIT STRING } The key thing to notice is that they DO NOT attempt to sign the unencoded certificate (i.e., UnsignedCertficate). The actual signing occurs on an open type which has been constrained to carry the value of the particular type that is to be signed (TYPE-IDENTIFIER.&Type (UnsignedCertificate)). In so doing, a) they clearly identify that the type should be encoded independently of the ICV, b) they avoid having to do a re-encode of the data after the CRV has been calculated, c) the type to which the ICV is to be applied can be extended with no problem, and d) they prepared themselves for the possible use of PER by utilizing an open type to carry the value to be signed - something that is *crucial* to signing PER-encoded data. > Problems with Non-OPTIONAL Extensions > > Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL > extensions. Let us assume that software C uses following ASN.1 definition > for Foo: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL, > criticalExtension OtherType > } > > There are two kinds of problems with an extension like criticalExtension. > First, the encoder may try to ensure that all encoded PDUs conform to the > specification and signal an error when a PDU without criticalExtension is > encoded. That's the correct behavior only if you are originating a message. Encoders should not complain about criticalExtension being absent if they are not originating the message. > Another problem is that the intermediate representation produced > by the ASN.1 compiler may not provide means for application to express > that criticalExtension is not present. (In other words, the produced > structure usually contains a flag telling whether an optional field is > present or not. Such flags are not included when the field is not > optional.) It is an error for encoders not to encode extension additions that are mandatory but missing if such extension additions do not occur within an extension addition group and if no other extension addition values follow the missing but mandatory extension. (I don't believe H.225 employs extension addition groups (i.e., the "[[" and "]]" notation.)) This is indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which unconditionally mandates that it be possible for decoded components that are defined to both the sender and receiver be re-encodable by the receiver. > The presense or absence of the OPTIONAL flag in an extension does not > change the PER encoding of the SEQUENCE. In order to avoid previously > mentioned problems, application may use a version of ASN.1 notation that > has extra OPTIONAL keyword after each extension. Neat! A nice and simple solution for use with such compilers. > Solution 1: Clarification to the PER Encoding Process > > The text in PER document (X.691, 1994) is somewhat ambiguous how many > bits should be included in the extension present bitfield of SEQUENCE. To > quote verbatim: "Let the number of extension additions in the type being Note that it says the *type* being encoded, not the value. That's distinct from the value. > encoded be "n", then a bit-field with "n" bits shall be produced for > addition to the field-list." (Is the "type being encoded" the abstract > syntax or an actual value like { bar 1, baz 2 }?) However, the 0 bits at > the end of extension present bitfield can be left out without changing > the resulting semantics: the corresponding extensions are not present. It is true that they can be left out without changing the semantics, but this is not what PER mandates (It should have mandated what you suggest, but hindsight is 20-20.) Unless everyone encodes according to PER its canonical nature will be lost. > As a result, the PER encoding does not change after a new extension > is added to the ASN.1 specification. > This solution, while leaving H.225.0 v2 protocol as it is, requires > however changes to some existing ASN.1 compilers, and in a pessimal case, > to the X.691 standard text, too. Yes, this would work, but as you point out, it requires that PER be changed. > Solution 2: Hack > > The receiving application does not decode and the re-encode the PDU, but > rather removes the ICV from the encoded PDU. In practice, this requires that > application can identify PER-encoded fields within the PDU and it can > regenerate them, i.e. it has effectively the same functionality as a PER > encoder/decoder. > > Solution 3: Calculating ICV Differently > > The following algorithm for generating and checking the ICV makes it > possible to avoid all the previously mentioned problems. The problems are > avoided by breaking the protocol layering, the application changes directly > the PER-encoded PDU: > > integrityCheckValue - provides improved message integrity/message > authentication of the RAS messages. The cryptographically based > integrity check value is computed by the sender applying a > negotiated integrity algorithm and the secret key upon the entire > message. Prior to integrityCheckValue computation an ICV with a > previously agreed magic value (or key when using MDC) will be > inserted to this field. The magic value will contain same > algorithmOID and exactly as many bits in the icv BIT STRING as the > computed value. After computation, the sender replaces the magic > value with the computed integrity check value and transmits > message. The receiver decodes message, replaces the received > integrity value with the magic value, calculates the ICV and > compares it with the received value. > > NOTE: The sender or receiver can encode the ICV separately and replace > it directly within the encoded PDU, when the magic ICV and computed > ICV have exactly the same length. When replacing ICV value within > an encoded PDU, re-encoding the whole PDU can be avoided. I don't like this too much because of the possibility, though low, of the data containing the magic ICV value. Still I prefer it to solutions 1 and 2. > Solution 4: > > Fourth alternative is to treat encoded RasMessage as octet string. IVC > can be calculated over that octet string and appended to the PDU on > separate layer. E.g., RAS PDU could be defined as follows: > > RasMessage ::= CHOICE { > -- all previous RasMessage CHOICEs are here > authenticatedRasMessage SEQUENCE { > plainRasMessage OCTET STRING, > ivc IVC, > ... > } > } This is effectively what is done in SET and other security-conscious protocols, though they typically use open type instead of octet string. Alternate Solution 1: To do exactly as is done in SET, you would define RasMessage without an ICV, and define a container, AuthenticatedRasMessage, say, that carries the encoded RasMessage as an open type value (i.e., octet-aligned, and padded with 0-bits at the end to ensure that it is an integral multiple of 8 bits) followed by the ICV value. In other words: AuthenticatedRasMessage ::= SEQUENCE { plainRasMessage TYPE-IDENTIFIER.&Type (RasMessage), ivc IVC } Using this approach, the RasMessage (which would be defined without an ICV) would be encoded, then the ICV would be calculated using the encoded RasMessage, then AuthenticatedRasMessage would be encoded. This approach is efficient because RasMessage does not have to be encoded without the ICV value then re-encoded with it, nor does it require that the encoded value be tinkered with in any way. This technique is good only if backward compatibility is not an issue (i.e., if you don't already have a deployed version of H.225), for the open type carries a length component than an ordinary encoded RasMessage does not have. Alternate Solution 2: If backward compatibility is an issue then Solution 4 above is a better alternative, though I would change it to: RasMessage ::= CHOICE { -- all previous RasMessage CHOICEs are here authenticatedRasMessage AuthenticatedRasMessage } Open type and octet string produce identical encodings, but I have a preference for the open type notation because it allows you to clearly identify what the value is - in this case an encoded RasMessage, and because it can simplify implementations that may not have a need to authenticate the RasMessage upon decoding (e.g., line monitors.) I am not intimate with H.225, so I don't know for sure of Solution 4 or this minor variation is backward compatible. It is if the ICV was just introduced, else I don't think it is. -------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636

2 1

Re: ASN.1 across revisions
by Paul Long 29 Jun '98

29 Jun '98

>From: Bancroft Scott[SMTP:baos@OSS.COM] >It is an error for encoders not to encode extension additions that are >mandatory but missing if such extension additions do not occur within an >extension addition group and if no other extension addition values follow >the missing but mandatory extension. (I don't believe H.225 employs >extension addition groups (i.e., the "[[" and "]]" notation.)) This is >indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which >unconditionally mandates that it be possible for decoded components that >are defined to both the sender and receiver be re-encodable by the >receiver. So, Bancroft, are you saying that it would be an error if FooGone, below, were encoded where Foo was called for? Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType } FooGone ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL } Likewise, are you saying that it would be an error if FooOpt, below, were encoded, without the value of criticalExtension present, in place of Foo, because the extension addition is mandatory in Foo? FooOpt ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType OPTIONAL } > >> Solution 1: Clarification to the PER Encoding Process >> >> The text in PER document (X.691, 1994) is somewhat ambiguous how many >> bits should be included in the extension present bitfield of SEQUENCE. >>To >> quote verbatim: "Let the number of extension additions in the type being > >Note that it says the *type* being encoded, not the value. That's >distinct from the value. > >> encoded be "n", then a bit-field with "n" bits shall be produced for >> addition to the field-list." (Is the "type being encoded" the abstract >> syntax or an actual value like { bar 1, baz 2 }?) However, the 0 bits >>at >> the end of extension present bitfield can be left out without changing >> the resulting semantics: the corresponding extensions are not present. > >It is true that they can be left out without changing the semantics, but >this is not what PER mandates (It should have mandated what you suggest, >but hindsight is 20-20.) Unless everyone encodes according to PER its >canonical nature will be lost. So are you saying that if an ASN.1 type in a Recommendation contains an extension addition, such as criticalExtension in Foo, above, an implementation of that Recommendation _must_ represent that extension addition in all encodings of that type? IOW, although it may be "easy" to encode the type without that extension addition (the extension-addition bit-map does not contain a corresponding bit for that extension addition, the bit-map length value reflects this shortening, and the open type containing the value is not encoded), the encoding would be in error? If so, I assume this would be because, technically, another type was being encoded, not the one defined in the Recommendation, as in "Let the number of extension additions in _the type being encoded_ be 'n'..." > Paul Long

2 1

Files at the ftp site
by Sakae OKUBO 28 Jun '98

28 Jun '98

Dear Jean-Pierre, I have sorted out the files at the /Incoming directory of Q.12-14/16 ftp site. There are three gif files: TD-97, TD-98, TD-99. TD-99 has zero byte, and the remaining two appear irrelevant to the meeting. Do you have any ideas? I cannot find your TD-19 "Exhibition of a H.323 decentralized conference" anywhere. Could you please upload it? Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Minutes from Multimedia MIB audio call o
by George Kajos 26 Jun '98

26 Jun '98

SQ16 Q14 Multimedia Management Information Base Audio Call 6/24 Minutes Agenda 1. IETF submission/coordination 2. APC 1380 GW, MC, MP Annexes 3. Cannes summary The call started late because George gave out incorrect bridge numbers and it took the first 15 minutes of the call to try to get people onto the bridge. As a result a number of people couldn't get into the conference. Actual participants: Attendees Mike Thatcher, Cisco Zvi Mizrahy, Pnina Vortman, IBM Haifa Orit Levin, RadVision Joon Maeng, VTEL Bill Strahm, Mark Baugher, Intel Picturetel Ghislaine Griswold, Lucent Don Dewar, George Kajos, David Reich, Irina Suconick, VideoServer People unable to attend because of the phone number problem: Nicole Gallant, Nortel David Walker, Ashok Ganesan, and Annette Lanteigne, Mitel I apologize for the mistake. IETF It was agreed at the Cannes meeting to obtain IETF input to the Multimedia MIB. The procedure appears to be for George to send email to the Operations and Maintenance Area Directors requesting a working group, stating the interest of the number of companies involved and the existing body of work. George will volunteer to co-chair the working group. It was discussed whether the IETF would find a qualified co-chair, but we will wait until we get a response to the email request. George will put together a strawman charter and send this request by 6/26/98. A poll was taken as to whether there would be adequate representation at the August meeting and it was clear that there would be a number of companies in attendance. A recurring issue is whether the work is going to be performed at the IETF or the ITU-T. The model discussed is the details of content are clearly ITU charter work, while SNMP and MIB format and organization are inputs we expect to be likely from the IETF. The Multimedia MIB document APC-1380 is organized as a main document and a series of Annexes representing individual pieces. Yet some of the attendees though it might be more appropriate to separate the Annexes into possibly 3 MIB submissions; H323, H320, H245. This caused some confusion as to where the GW MIB would go. It was decided to finish the Annexes of the Multimedia MIB document before concluding the format of the submission to the IETF. GW, MC, MP The GW, MC, and MP Annexes did not get submitted to the meeting at Cannes for the June ITU meeting. Zvi Mizrahy and Prina Vortman of IBM Haifa indicated they would send the gateway Annex APC1393 to the mailing list. One of the questions which was discussed was how to place the gateway in the overall hierarchy. It could probably be brought up to the main level rather than under H.323. The decision was deferred until the next meeting after the group had a chance to understand the proposal. One other element of the proposal was that there would be a set of definitions which would likely be moved up into the textual conventions and registration file. George also placed it in the avc-site\incoming directory on the Picturetel FTP site. VideoServer reiterated their intent to develop an MC and MP contribution of the next 2-3 weeks. Cannes review A brief summary of the Cannes meeting was discussed. First APC 1380 was presented which outlined the hierarchy and MIB organization. RTP was shown as Annex 1 in the document, but it is still an issue as to where it should appear. George, Irina and Joon discussed individual proposals. The RAS MIB and indexing issues reappeared. There was more discussion about correlation between admission and call signalling tables, but there's no conclusion. Gary Thom did not get feedback from his liaison to ITU SG4 on management. Thus, the whole effort is still on a dual path. Many present expressed a need to keep this work moving as rapidly as possible. Next Meeting: Wednesday, July 8, 1998 11:00 - 1:00 PM EST. Current Action Items: 1. George Kajos - Publish meeting minutes (this report) and schedule next conference. 2. George Kajos - Confer with ISO and IETF network management experts regarding placement of H.Multimedia MIB - generate request to O&M Area Director 3. Group - Admission table indices - Issue of index uniqueness waiting for example of a problem. 4. Group - Admission and CallSignalling Tables index correlation. 5. Group - review APC1393 (GW) from Zvi Mizrahy and Prina Vortman 6. VideoServer - Gernerate MC and MP proposal George Kajos VideoServer, Inc 63 Third Avenue Burlington, MA 01803 781-505-2193 (phone) 781-505-2101 (fax)

1 0

test
by Dale L. Skran 26 Jun '98

26 Jun '98

This is a test; please ignore. Dale

1 0

H.225.0/RAS ICV calculation
by Pekka Pessi 26 Jun '98

26 Jun '98

Hello, While debugging our ASN.1/PER encoder, I noticed a problem with the way ICV is calculated in H.225.0. Briefly, the PER encodings change when a SEQUENCE type is further extended, even if the new extension additions are not included in the SEQUENCE value. The issue prevents interoperability between software using H.225.0 version 2 and software using any version, it should be solved before any version 2 devices are released. Pekka Pessi h2250-integrityCheckValue-problem.txt Pekka Pessi <pessi(a)research.nokia.com> $Revision: 1.1 $ Nokia Research Center June 1998 Comments on H.225.0 (1998): Problems When Calculating integrityCheckValue The current H.225.0 algorithm for calculating the ICV does not work well with the PER extension mechanism. In order to interwork, each H.323 device needs a separate PER encoding function for each version of H.225.0 ASN.1 definitions. Algorithm for Calculating integityCheckValue According to the H.225.0 v2, integrityCheckValue is defined and calculated as follows: ICV ::= SEQUENCE { algorithmOID OBJECT IDENTIFIER, -- the algorithm used to compute the signature icv BIT STRING -- the computed cryptographic integrity check -- value or signature } integrityCheckValue - provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message. The above algorithm (AFAIK I have understood it correctly) assumes that the sender and receiver can encode the PDU exactly in the same way. It is a reasonable assumption, as PER produces only one possible (canonical) encoding for given PDU. However, there is a serious problem: the canonical representation changes if the ASN.1 SEQUENCE type is extended later. PER Encoding of an Extended ASN.1 SEQUENCE In the PER encoding of extensions to SEQUENCE types, the encoder first encodes the number of extensions as a normally small non-negative integer, then a bit field with one bit for each extension followed by the extensions itself (bit is one if the extension is present, zero if not). The encoding of each extension is preceded by the length of their encoding in octets. Now, if the sender A uses following ASN.1 definition for a SEQUENCE Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL } When encoding this, the length of extension bitfield is 2. However, recipient B is using extended version of Foo like this: Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL } B decodes the Foo, removes ICV and encodes the packet again. In the resulting encoding, the length of extension bitfield is 3, and the ICV that B regenerates is different that A generated and sent to B. B is not able to interwork with systems using earlier version of the ASN.1 spec. ASN.1 Compilers Don't Grok Unknown Extensions There are also problems because the way some ASN.1 compilers behave. Using our previous example, when A receives Foo with the importantExtension field from B, A has somehow to include the value when it is re-encoding Foo in order to calculate the ICV. However, it may be very hard to present an value of an unknown extension to the ASN.1 encoding functions. As a possible solution the ICV calculation could be included in the ASN.1 decoding process. Problems with Non-OPTIONAL Extensions Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL extensions. Let us assume that software C uses following ASN.1 definition for Foo: Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType } There are two kinds of problems with an extension like criticalExtension. First, the encoder may try to ensure that all encoded PDUs conform to the specification and signal an error when a PDU without criticalExtension is encoded. Another problem is that the intermediate representation produced by the ASN.1 compiler may not provide means for application to express that criticalExtension is not present. (In other words, the produced structure usually contains a flag telling whether an optional field is present or not. Such flags are not included when the field is not optional.) The presense or absence of the OPTIONAL flag in an extension does not change the PER encoding of the SEQUENCE. In order to avoid previously mentioned problems, application may use a version of ASN.1 notation that has extra OPTIONAL keyword after each extension. Solution 1: Clarification to the PER Encoding Process The text in PER document (X.691, 1994) is somewhat ambiguous how many bits should be included in the extension present bitfield of SEQUENCE. To quote verbatim: "Let the number of extension additions in the type being encoded be "n", then a bit-field with "n" bits shall be produced for addition to the field-list." (Is the "type being encoded" the abstract syntax or an actual value like { bar 1, baz 2 }?) However, the 0 bits at the end of extension present bitfield can be left out without changing the resulting semantics: the corresponding extensions are not present. As a result, the PER encoding does not change after a new extension is added to the ASN.1 specification. This solution, while leaving H.225.0 v2 protocol as it is, requires however changes to some existing ASN.1 compilers, and in a pessimal case, to the X.691 standard text, too. Solution 2: Hack The receiving application does not decode and the re-encode the PDU, but rather removes the ICV from the encoded PDU. In practice, this requires that application can identify PER-encoded fields within the PDU and it can regenerate them, i.e. it has effectively the same functionality as a PER encoder/decoder. Solution 3: Calculating ICV Differently The following algorithm for generating and checking the ICV makes it possible to avoid all the previously mentioned problems. The problems are avoided by breaking the protocol layering, the application changes directly the PER-encoded PDU: integrityCheckValue - provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation an ICV with a previously agreed magic value (or key when using MDC) will be inserted to this field. The magic value will contain same algorithmOID and exactly as many bits in the icv BIT STRING as the computed value. After computation, the sender replaces the magic value with the computed integrity check value and transmits message. The receiver decodes message, replaces the received integrity value with the magic value, calculates the ICV and compares it with the received value. NOTE: The sender or receiver can encode the ICV separately and replace it directly within the encoded PDU, when the magic ICV and computed ICV have exactly the same length. When replacing ICV value within an encoded PDU, re-encoding the whole PDU can be avoided. NOTE: The above algorithm does not require directly changing the PER-encoded PDU. Like the current algorithm, ICV can be replaced with a new value above presentation layer then PDU will be re-encoded. It makes it easy, however: as the magic value is a very unique octet-aligned bit pattern (random data of 64 bits or more, probably), it should be easy to spot and replace it from the encoded PDU. NOTE: It is not advisable to use magic value as the key to MAC algorithm. Example code: int icv_replace( u_char *msg, size_t len, u_char const *icv, u_char const *magic, size_t ilen) { u_char *m, *mim; size_t i, j, ilen_in_octets, ilen_in_full_octets; ilen_in_octets = (ilen + 7) >> 3; ilen_in_full_octets = ilen >> 3; /* find magic value from message */ for (m = msg, mim = NULL; m - msg < len - ilen_in_octets; m++) { /* NOTE: the magic value/icv may not be integral number of octets */ for (i = 0; i < ilen_in_full_octets; i++) { if (m[i] != magic[i]) break; } if (i == ilen_in_full_octets) { if (mim) return -2; /* failure: two or more magic values found */ mim = m; } } if (mim == NULL) { return -1; /* failure: no magic value found */ /* replace magic value with icv */ for (i = 0; i < ilen_in_octets; i++) { mim[i] ^= magic[i] ^ icv[i]; } return 0; /* success */ } Solution 4: Fourth alternative is to treat encoded RasMessage as octet string. IVC can be calculated over that octet string and appended to the PDU on separate layer. E.g., RAS PDU could be defined as follows: RasMessage ::= CHOICE { --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- -- all previous RasMessage CHOICEs are here --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- authenticatedRasMessage SEQUENCE { plainRasMessage OCTET STRING, ivc IVC, ... } }

4 5

Report of the Cannes meeting
by Sakae OKUBO 26 Jun '98

26 Jun '98

Dear Q.12-14/16 experts, I have uploaded draft report of the Cannes meeting (APC-1425) at the /Incoming directory. ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip /APC-1425_w95.zip w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) with Word 97. w95 is a version converted into Word 6/95; there are obvious errors in section numbering and figures. Please review it in a week time, and give me any comments. I will then complete it, uploade it at /9806_Can directory and send its copies to the SG16 management. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

how many port pairs in a call/conference?
by grm＠ZURICH.IBM.COM 25 Jun '98

25 Jun '98

OK, I thought these were easy questions but maybe people wonder 'what does he mean by RTP Session?' Let me rephrase: (A) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in a two-party call with two-way audio? (B) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in an n-party conference with everybody sending and receiving audio and using distributed multi-unicast? Marcel Graf IBM Zurich Research Lab > I'm trying to find an answer to the question (A) "how many RTP > Sessions are there for a two-party call with two-way audio?", and to > the related question (B) "how many RTP Sessions are there for an > n-party conference with each participant being an audio Source and an > audio Sink and using distributed multi-unicast?". > > What I already know is that, assuming unidirectional Logical > Channels, in the first case there are two Logical Channels, and in > the second case there are n*(n - 1) Logical Channels. > > H.245 says about the sessionID: "The sessionID is a unique RTP or > T.120 Session Identifier in the conference. It is used by the > transmitter to refer to the session to which the logical channel > applies. Only the master can create the session identification. By > convention, there are three primary sessions. The first primary > session with a session identification of 1 is the audio session, the > second primary session with a session identification of 2 is the > video session, and the third primary session with a session > identification of 3 is the data session." > > Can I interpret this paragraph as saying that in case (A) there is > only one RTP Session, and in case (B) there is only one RTP Session, > too? > > If that is correct, then the following paragraph from H.323 section > 6.2.8.2 "Logical channel signalling" comes into play: "If a > corresponding reverse channel is opened for a given existing RTP > session (identified by the RTP sessionID), the mediaControlChannel > transport addresses exchanged by the OpenLogicalChannel process shall > be identical to those used for the forward channel. Should a > collision occur where both ends attempt to establish conflicting RTP > sessions at the same time, the master endpoint shall reject the > conflicting attempt as described in Recommendation H.245. The > rejected OpenLogicalChannel attempt may then be retried at a later > time." > > What type of conflict does this paragraph refer to? Given there is a > single RTP Session, and (multi-)unicast is used, each endpoint > chooses the RTP and RTCP port it is listening on independently of the > others. (The paragraph can't be talking about multicast, because it > is the MCs responsibility to allocate multicast addresses.) > > I also made the following observation: The "primary session > convention" established in the cited H.245 paragraph seems to be > contradicted by the samples shown in H.323 Appendix I "Sample MC to > Terminal Communication Mode Command" which uses the sessionIDs 2 and > 3 differently. Maybe the convention is only meant for two-party calls? > > > Marcel Graf > IBM Zurich Research Lab

2 1

Re: SNMP audio call
by Tom-PT Taylor 24 Jun '98

24 Jun '98

Please reserve a port for Nortel. Nicole Gallant will be taking part on our behalf. > -----Original Message----- > From: George Kajos [SMTP:gkajos@VIDEOSERVER.COM] > Sent: Tuesday, June 23, 1998 9:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: SNMP audio call > > Hello folks, > I'm resuming the Multimedia MIB audio call tomorrow, June 24 at 11-1:00 > EST. Please let me know if you desire a bridge number to attend the call. > My agenda is to discuss the August IETF meeting and to get commitments > for the 3 missing H.323 annexes - GW, MC, and MP. > > Thank you, > George Kajos > VideoServer > 63 Third Avenue > Burlington, MA 01803 > tel: (781) 505-2193 > fax: (781) 505-2101 > email: gkajos(a)videoserver.com

1 0

Re: conferenceListChoice
by Stewart, Glenn 23 Jun '98

23 Jun '98

Chris, Actually I agree with you, getting a list of conferences to Join in response to a create is kind of odd... The reason this occurs is that unlike T.120 there is no initial query function in H.323 call setup for the calling terminal to find out the nature of the called terminal. In general terminals (H.323 and H.320 for that matter) provide users a simple phone call model UI. The user provides an address and the terminal calls it. In this interface (unless the terminal requires or caches information about the nature of the target) the terminal is not aware of the intent of the call. In fact the user may not be aware of the ultimate intent of the call. Much of the time the user just wants to make a simple point to point connection and so one model is that the calling terminal simply asks the called party/terminal to create a conference. If the called party does not want to create the conference it refuses the connection and provides potential information on how to proceed. One of these possible responses is a list of conferences the terminal software can present to the user allowing the user to select conference he or she would like to join. I should point out there are terminals that make the user determine a priori the nature of the call (i.e., the user must indicate they are calling an MCU (or conference service) and would like to join a conference). While obviously being technically clean and correct, I personally, find them difficult to use. The model provided above, although "strange", is actually more intuitive in my opinion. glenn > -----Original Message----- > From: Chris Purvis WVdevmt-WS [mailto:cpurvis@madge.com] > Sent: Tuesday, June 23, 1998 5:10 AM > To: gstewart(a)sonusnet.com > Cc: mbozier(a)madge.com; jim.toga(a)intel.com; gthom(a)delta-info.com; > gkajos(a)videoserver.com > Subject: RE: conferenceListChoice > > > Glenn, > > Thanks for the response. It still seems a little strange offering an > endpoint a choice of conferences to JOIN when it has asked to > CREATE a new > conference, but at least it now seems reasonably clear what > you intended. > Don't worry about lack of clarity, by the way - that's the > fault of everybody > who had a chance to comment on the text, not just the person > who submitted it > in the first place. > Would you like to squirt some clarification back out on the > reflectors? > > Jim: Can something go in the implementor's guide on this, please? > > Chris > ---------------------------------------------------- > Chris, > > The conferenceListChoice element is only to provide a list of > conferences that the calling endpoint can join. The ability of the > calling endpoint to create a conference at the MCU is a choice left to > the MCU manufacturer. Assuming the MCU will allow a "create" then use > of the supplied GCID is sufficient. > > Your second (more serious) point reveals a lack of clarity in the text > (supplied by me I'm afraid). Not explicitly stated is that the > "Facility" message is a routeCallToMC in which the MCU Call Signaling > Address and the conference list are supplied. The calling > endpoint then > sends new Setup to the supplied Call Signaling Address with > the selected > conference (see section 8.4.3.7). > > My apologies for not making this more clear in the originally supplied > text. > > glenn > > Glenn Stewart > ~~~~~~~~~~~~~~~~~~~~~~~ > gstewart(a)sonusnet.com > Sonus Networks > ~~~~~~~~~~~~~~~~~~~~~~~ > PS: Gary - I'm not sure if your still editing H.323, but I thought the > editor should have a copy of this. Can you please forward this as > appropriate? > > > -----Original Message----- > > From: Chris Purvis WVdevmt-WS [mailto:cpurvis@MADGE.COM] > > Sent: Thursday, June 18, 1998 1:07 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: conferenceListChoice > > > > > > All, > > > > H.323 version 2 states in 8.4.3.1 A2d) and 8.4.3.4 that an > MCU can use > > conferenceListChoice to give a version 2 endpoint the choice > > between a number > > of possible conferences of which one it would like to > > create(!). I have two > > points with regard to this: > > 1. Surely it would also be sensible to have a similar method > > for joining > > extant conferences (rather than just sending ReleaseComplete > > when CIDs don't > > match)? Would'nt this be an easy (no extra ASN.1!) and > > useful addition? > > 2. (more serious) I can't see how an endpoint tells the MCU > > which conference > > from the list it has chosen! > > Is it up to the endpoint to release the call and send a new > > setup message > > with the appropriate conference alias in, or does it send > > back a similar > > facility message to the one it was sent, with a single > > ConferenceList in > > rather than a sequence of same? > > > > Chris > > ---------------------------------------- > > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > > Phone:+44 1753 661359 email: cpurvis(a)madge.com >

1 0

Re: SNMP audio call
by Chris Gindel 23 Jun '98

23 Jun '98

George, Please send me a number for the call. Thanks, Chris > -----Original Message----- > From: George Kajos [SMTP:gkajos@VIDEOSERVER.COM] > Sent: Tuesday, June 23, 1998 9:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: SNMP audio call > > Hello folks, > I'm resuming the Multimedia MIB audio call tomorrow, June 24 at > 11-1:00 > EST. Please let me know if you desire a bridge number to attend the > call. > My agenda is to discuss the August IETF meeting and to get commitments > for the 3 missing H.323 annexes - GW, MC, and MP. > > Thank you, > George Kajos > VideoServer > 63 Third Avenue > Burlington, MA 01803 > tel: (781) 505-2193 > fax: (781) 505-2101 > email: gkajos(a)videoserver.com

1 0

SNMP audio call
by George Kajos 23 Jun '98

23 Jun '98

Hello folks, I'm resuming the Multimedia MIB audio call tomorrow, June 24 at 11-1:00 EST. Please let me know if you desire a bridge number to attend the call. My agenda is to discuss the August IETF meeting and to get commitments for the 3 missing H.323 annexes - GW, MC, and MP. Thank you, George Kajos VideoServer 63 Third Avenue Burlington, MA 01803 tel: (781) 505-2193 fax: (781) 505-2101 email: gkajos(a)videoserver.com

1 0

how many RTP Sessions in a call/conference?
by grm＠ZURICH.IBM.COM 19 Jun '98

19 Jun '98

I'm trying to find an answer to the question (A) "how many RTP Sessions are there for a two-party call with two-way audio?", and to the related question (B) "how many RTP Sessions are there for an n-party conference with each participant being an audio Source and an audio Sink and using distributed multi-unicast?". What I already know is that, assuming unidirectional Logical Channels, in the first case there are two Logical Channels, and in the second case there are n*(n - 1) Logical Channels. H.245 says about the sessionID: "The sessionID is a unique RTP or T.120 Session Identifier in the conference. It is used by the transmitter to refer to the session to which the logical channel applies. Only the master can create the session identification. By convention, there are three primary sessions. The first primary session with a session identification of 1 is the audio session, the second primary session with a session identification of 2 is the video session, and the third primary session with a session identification of 3 is the data session." Can I interpret this paragraph as saying that in case (A) there is only one RTP Session, and in case (B) there is only one RTP Session, too? If that is correct, then the following paragraph from H.323 section 6.2.8.2 "Logical channel signalling" comes into play: "If a corresponding reverse channel is opened for a given existing RTP session (identified by the RTP sessionID), the mediaControlChannel transport addresses exchanged by the OpenLogicalChannel process shall be identical to those used for the forward channel. Should a collision occur where both ends attempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject the conflicting attempt as described in Recommendation H.245. The rejected OpenLogicalChannel attempt may then be retried at a later time." What type of conflict does this paragraph refer to? Given there is a single RTP Session, and (multi-)unicast is used, each endpoint chooses the RTP and RTCP port it is listening on independently of the others. (The paragraph can't be talking about multicast, because it is the MCs responsibility to allocate multicast addresses.) I also made the following observation: The "primary session convention" established in the cited H.245 paragraph seems to be contradicted by the samples shown in H.323 Appendix I "Sample MC to Terminal Communication Mode Command" which uses the sessionIDs 2 and 3 differently. Maybe the convention is only meant for two-party calls? Marcel Graf IBM Zurich Research Lab

1 0

H.321/H.322
by Gary A. Thom 19 Jun '98

19 Jun '98

All, I am putting together a report on the maturity of some of the H-Series recommendations. I am trying to find out if anyone produces or plans to produce products which comply with H.321 or H.322. If you do, or if you know that someone else does, could you please drop me an e-mail. Thanks Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------

1 0

conferenceListChoice
by Chris Purvis WVdevmt-WS 18 Jun '98

18 Jun '98

All, H.323 version 2 states in 8.4.3.1 A2d) and 8.4.3.4 that an MCU can use conferenceListChoice to give a version 2 endpoint the choice between a number of possible conferences of which one it would like to create(!). I have two points with regard to this: 1. Surely it would also be sensible to have a similar method for joining extant conferences (rather than just sending ReleaseComplete when CIDs don't match)? Would'nt this be an easy (no extra ASN.1!) and useful addition? 2. (more serious) I can't see how an endpoint tells the MCU which conference from the list it has chosen! Is it up to the endpoint to release the call and send a new setup message with the appropriate conference alias in, or does it send back a similar facility message to the one it was sent, with a single ConferenceList in rather than a sequence of same? Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Proposal for Common RDC Protocol is available
by Mark Duckworth 18 Jun '98

18 Jun '98

This proposal for work on a common RDC protocol is submitted to the Q3 meeting next week in Colorado Springs. I uploaded it to: ftp://ftp.imtc-files.org/imtc-site/incoming/Common_RDC_Proposal.zip Bruce DeGrasse, please move it to ftp://ftp.imtc-files.org/imtc-site/T120-top/t120_colorado98 Summary: This proposal continues the work of recent RDC audio conferences and the Q11-14/16 meeting in Cannes. The proposed approach is to use a common RDC protocol (V.RDC) which can be carried within a T.120 APE (T.RDC) or without T.120 (H.RDC) in an H.245 logical channel. H.323 systems will use H.RDC for both point to point and multipoint, with T.RDC being optional. This paper includes the following: - suggestions for separating the common protocol from the T.120 specifics, in the current T.RDC (ftp://www.imtc.org/imtc-site/T120-top/t120_ky98/TRDCreva.doc) - changes to camera control to make it H.281 compatible - start/continue/stop - predefined device identifiers - presets - changes to camera control to make it more useful and usable - automatic pointing - coordinates in terms of field of view rather than degrees - a list of work still to do in defining the ASN.1 syntax for H.RDC Mark Duckworth

1 0

Re: GloballyUniqueID duplicates
by Douglas Clowes 17 Jun '98

17 Jun '98

At 18:43 16/06/98 -0700, you wrote: >>---------- >>From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >>On reading the text in H.225.0 describing the construction of a globally >>unique identifier, it seems to me that duplicates are possible if the clock >>has not advanced since the last identifier was generated. >That's what the clock sequence value is for. > >Paul Long >Smith Micro > Perhaps, but on my reading, it's not what the document says! Douglas Clowes OzEmail Interline

2 1

Re: GloballyUniqueID duplicates
by Paul Long 17 Jun '98

17 Jun '98

>---------- >From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >On reading the text in H.225.0 describing the construction of a globally >unique identifier, it seems to me that duplicates are possible if the clock >has not advanced since the last identifier was generated. That's what the clock sequence value is for. Paul Long Smith Micro

1 0

GloballyUniqueID duplicates
by Douglas Clowes 17 Jun '98

17 Jun '98

On reading the text in H.225.0 describing the construction of a globally unique identifier, it seems to me that duplicates are possible if the clock has not advanced since the last identifier was generated. This may occur if the clock ticks at a slow rate (say ten milliseconds), if the CPU is sufficiently fast, or there is more than one CPU. In the case of a slow clock, say ten milliseconds, this can be compensated for with the low order bits of the time field being cleared and used as a sequence number for identifiers generated in the same clock tick. In what has been called a "Carrier Class Gateway," with tens of thousands of SCN ports and more than one CPU, it may be possible to generate a duplicate identifier, for a CallIdentifier, within the same 100-nanosecond interval. In this event, a possible action is to increment the clock sequence if the time "has not advanced" rather than "has gone backward." Thus, if the current UTC is less that *or equal* to the saved value, or the saved value was lost, the clock sequence is incremented. Douglas Clowes OzEmail Interline

1 0