January 1999 - 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: Relationship of H.323 and H.245 versions
by Paul Long 29 Jan '99

29 Jan '99

Dave, Sorry, but I won't be in Monterey. I agree with what you say, except that I would go further and state that there is always a one-to-one mapping between H.225.0 and H.245 protocolIdentifiers via H.323. For example, H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => H.323v1 => H.225.0v1 H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => H.323v2 => H.225.0v2 This is already implied by the Summary section of H.323 starting with version 2. I think it's clear, but you could add clarification text if you like. IOW, for example, an EP cannot use H.245v2 and H.225.0v2 in the same call. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Dave Walker [SMTP:dave_walker@Mitel.COM] Sent: Friday, January 29, 1999 9:36 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Relationship of H.323 and H.245 versions This thread seemed to be moving towards a consensus. Is anyone planning to submit a contribution at Monterey? Pete? Paul? Since the developing consensus seemed to be that H.225.0 protocol identifier also identifies the version of H.323, I would like to add a provision that in the absence of any H.245 protocol identifier, that there be an implied linkage between H.323 version and H.245 version. That is, if any ASN.1 structure defined in H.245 is received prior to reception of an H.245 protocol identifier, the H.245 version used shall be that which is explicitly required by the H.323 version identified by the H.225.0 protocol identifier in use. This would apply to an OLC structure in fastStart for example. Dave Walker Mitel Corporation Ontario, CANADA

2 1

Re: Relationship of H.323 and H.245 versions
by Paul Long 29 Jan '99

29 Jan '99

Gary, You be the judge: Summary/H.323v2: "Products claiming compliance with Version 2 of H.323 shall comply with all of the mandatory requirements of this document, H.323 (1998), which references H.225.0 (1998) and H.245 (1998). Version 2 products can be identified by H.225.0 messages containing a protocolIdentifier = {itu-t (0) recommendation (0) h (8) 2250 version (0) 2} and H.225.0 messages containing a protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245 version (0) 3}." Assuming this text is normative, H.323v2 uses H.225.0v2 and H.245v3. Period. IMO, we will be asking for big trouble if we at some point decide that one can mix and match versions and even use subsets or supersets of a particular version. Whatever interoperability problems we have now will be magnified many times over if we head down that slippery slope. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] Sent: Friday, January 29, 1999 1:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Relationship of H.323 and H.245 versions One more question???? > Dave, > > Sorry, but I won't be in Monterey. > > I agree with what you say, except that I would go further and state that there > is always a one-to-one mapping between H.225.0 and H.245 protocolIdentifiers > via H.323. For example, > > H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => H.323v1 => H.225.0v1 > H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => H.323v2 => H.225.0v2 > > This is already implied by the Summary section of H.323 starting with version > 2. I think it's clear, but you could add clarification text if you like. IOW, > for example, an EP cannot use H.245v2 and H.225.0v2 in the same call. > But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be used in the same call??? 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

Re: Relationship of H.323 and H.245 versions
by Paul Long 29 Jan '99

29 Jan '99

-----Original Message----- From: Paul Long [SMTP:Plong@SMITHMICRO.COM] Sent: Wednesday, January 20, 1999 8:15 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Relationship of H.323 and H.245 versions The H.323 version number shall be taken to be the same as the version number indicated in the H.225.0 protocolIdentifier field. Each product shall encode and decode the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323. The H.323vM product shall behave according to H.323vM... Didn't anyone notice? I thought this would be the most provocative part of my little proposal. It says that one cannot implement a subset or superset of the H.323 version indicated by the transmitted protocol identifiers. Subsetting results in incomplete, unpredictable, non-compliant, I'd even say, "broken," implementations. Examples of subsetting include * An H.323v2 EP not recognizing the H.323v2/H.245v3 extension addition, openLogicalChannel....h263VideoCapability.h263Options. Such a terminal might mistakenly acknowledge a request for a video channel using these options because it chose to ignore the h263Options component. As a result, it would likely receive a video stream that it cannot decode. (This kind of thing quite concerns me.) * Any terminal not responding to RequestMode. (This is common.) * Any terminal not supporting "the transmission of user input characters 0-9, '*', and '#'" via userInputIndication. (This is common, too.) On the other hand, supersetting produces an incorrect encoding of the abstract syntax for the indicated H.323 version. Examples of supersetting: * An H.323v1 EP encoding the H.323v2/H.225.0v2 fastStart field, even if it is in communication with an H.323v2 EP. (Sounds like some may have already done this or are contemplating it.) * An H.323v1 EP encoding the H.323v2/H.245v3 h235SecurityCapability component in its terminalCapabilitySet. (Just another example.) Here's the normative text for encoding. 8.3/X.691(1994): "Implementations are not required to mirror the procedure specified, provided the bit string produced as the complete encoding of an abstract syntax value is identical to one of those specified in this Recommendation | International Standard for the applicable transfer syntax." The "applicable transfer syntax" is the ASN.1 syntax tree defined in the version of the Recommendation indicated by the protocol identifier. An entity is violating X.691 and therefore H.323 if it transmits an ASN.1 value not specified in the version of the Recommendation that it indicates in the protocol identifier field. It is a violation to transmit a value for an ASN.1 component that is defined in a subsequent version, such as a v1 EP transmitting fastStart. It is also a violation to transmit an incomplete value, such as a v1 EP not transmitting a representation of the slow*MPI and errorCompensation fields of H263VideoCapability (I've seen this one). And here's the normative text for decoding. 8.4/X.691(1994): "Implementations performing decoding are required to produce the abstract syntax value corresponding to any received bit string which could be produced by a sender conforming to the encoding rules identified in the transfer syntax associated with the material being decoded." I'm frankly not sure to which transfer syntax the word, "associated," refers-the encoder's or decoder's-but I believe that this means that an entity must decode and recognize all ASN.1 components defined in the syntax tree for its version of H.323/H.245/H.225.0. If I'm right, the entity cannot choose to not decode or otherwise ignore a component defined in its syntax tree. The h263Options example, above, illustrates this. Paul Long Smith Micro Software, Inc.

2 1

Re: Please allocate APC number
by Sakae OKUBO 28 Jan '99

28 Jan '99

Dear Mr. Duckworth, APC-1507 has been allocated to your contribution "Fixing inconsistency between Annex E and H.283 and Annex G." 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G ----------------------------------------------------------------------

1 0

Re: Ambiguity in H.225.0 Appendix D
by Jim Toga 28 Jan '99

28 Jan '99

Chris... I don't think we gauge final 'agreement' over the list, in any case I believe the exact text for the implementers guide has to be covered/approved at a Raportours' meeting and then ratified at a SG meeting. I would propose that text be brought into the Montery meeting (along with the collection of changes requested since the last SG meeting) and we collectively go over it... (BTW, I _think_ we do have agreement) jimt. At 07:31 PM 1/28/99 -0000, Chris Purvis wrote: >Jim, > >Following discussion, I take the point. >Do we take it that we have agreement over the original point, though? This >was my proposal to change the documentation of what ports are used for what >(1718 for multicast RAS messages, 1719 for unicast), especially with >reference to the LRQ case? Do we have sufficient agreement for it to make >it into the implementer's guide? > >Chris > >> -----Original Message----- >> From: Jim Toga [mailto:jim.toga@intel.com] >> Sent: 18 January 1999 6:33 >> To: Mailing list for parties associated with ITU-T Study Group 16 >> Cc: CPurvis(a)MADGE.COM >> Subject: Re: Ambiguity in H.225.0 Appendix D >> >> >> Chris, >> >> The problem is that it is a _client_ issue as much as a GK issue. The >> (enterprise) site administrator, wants to be assured that no >> rougue client >> will get on the network and simple start conferencing... If he has >> 'compliant' stacks than he can be assured that GK policy will >> be followed.... >> >> Regards, >> jimt. >> >> At 05:59 PM 1/18/99 -0000, you wrote: >> >Jim, >> > >> >Surely this could be left as a configuration option for the >> administrator. >> >If he doesn't want the assurance you describe, why shouldn't >> he be allowed >> >to configure it out of suitably-written gatekeepers? I >> would expect it to >> >be an unusual thing to want to do, bearing in mind your >> comments, but is it >> >the place of the standard to deny such possibilities? >> > >> >Chris >> > >> >> -----Original Message----- >> >> From: Jim Toga [mailto:jim.toga@INTEL.COM] >> >> Sent: 15 January 1999 1:47 >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> >> Subject: Re: Ambiguity in H.225.0 Appendix D >> >> >> >> >> >> There is a point behind having a GK respond to all GRQ messages. >> >> >> >> The administrator must be able to be assured that >> >> unauthorized endpoints >> >> (with compliant stacks) do not conference. H.323 stipulates >> >> that _if_ GKs >> >> are present, then endpoints must use them.... so if the GK >> >> are present and >> >> none of them will allow a particular endpoint to register - >> >> then it is not >> >> supposed to make/receives H.323 calls. >> >> >> >> The endpoint on the other hand, must be able to reasonably >> detect the >> >> difference between the complete absence of GKs and the >> >> absence of 'their' >> >> GK (especially if some specific control/policy is in place). >> >> >> >> If the GK receives a GRQ, it must respond with a (directed) >> >> GCF or GRJ. >> >> >> >> jimt. >> >> >> >> >> >> At 10:55 AM 1/13/99 -0800, you wrote: >> >> >Hi, >> >> > >> >> >This is wrt the second problem in the attached mail. >> >> >Chris Purvis mentioned that GK needs to know whether >> >> >a GRQ or LRQ is received via multicast or unicast so that >> >> >the response could be different. >> >> > >> >> >Actually, H.323 V2 specifies different multicast and unicast >> >> >responses only in case of LRQ. In case of GRQ, spec specifically >> >> >mentions that even in multicast case a response shall be >> >> >given (Section 7.2.1 para three which _only_ talks about >> >> >multicast GRQs). >> >> > >> >> >I believe spec should not mandate a GK to respond to >> >> >a multicast GRQ. It should be left to the implementor whether >> >> >a response should be sent out to a multicast GRQ or not. >> >> >The GK may have some additional information like redirecting >> >> >the endpoint to a different GK with altGKInfo etc, otherwise it >> >> >is just plain waste of bandwidth to mandate GK's to respond to >> >> >multicast GRQ's. The endpoints would time out if they >> >> >haven't received a single GCF. >> >> > >> >> >May be the following line in para 3 of section 7.2.1: >> >> > >> >> >"If a Gatekeeper does not want the endpoint to register to it, >> >> >it shall return Gatekeeper Reject (GRJ)" >> >> > >> >> >should be changed to something like: >> >> > >> >> >"On receiving a multicasted GRQ, if a Gatekeeper does not want >> >> >the endpoint to register to it, it MAY return Gatekeeper >> >> >Reject (GRJ)" >> >> > >> >> >Comments? >> >> > >> >> >Regards, >> >> >-Kishore. >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Mailing list for parties associated with ITU-T >> Study Group 16 >> >> >> [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis >> >> >> Sent: Thursday, January 07, 1999 9:33 PM >> >> >> To: ITU-SG16(a)mailbag.cps.intel.com >> >> >> Subject: Ambiguity in H.225.0 Appendix D >> >> >> >> >> >> >> >> >> We have had an ambiguity show up during interoperability >> >> >> testing, which >> >> >> I would like clarified by means of the implementer's guide >> >> and future >> >> >> versions of the standard. Any objections, please shout in >> >> the usual >> >> >> way! >> >> >> >> >> >> The problem comes in 19.1.1.1 where UDP port numbers are >> >> defined. The >> >> >> standard currently (I'm looking at version 2) says: >> >> >> Gatekeeper UDP Discovery Port 1718 >> >> >> Gatekeeper UDP Registration and Status Port 1719 >> >> >> >> >> >> There are two problems with this. The first is that it >> >> >> implies that the >> >> >> LRQ message (which is nothing to do with discovery) always >> >> needs to be >> >> >> sent to port 1719, which is a problem for multicast LRQs, >> >> because only >> >> >> one IP address and port number pair has been registered with >> >> >> the IETF - >> >> >> 224.0.1.41:1718. >> >> >> >> >> >> The second problem is, if anything, more subtle... The >> >> standard also >> >> >> seems to imply by the above that GRQ, which is a >> discovery message, >> >> >> should always be sent to port 1718, whether it is sent to the >> >> >> multicast >> >> >> discovery port or not. >> >> >> The reason this is a problem is that gatekeepers need to >> >> know whether >> >> >> these messages (GRQ and LRQ) have arrived by multicast or >> >> by unicast, >> >> >> because the failure response is different in the two cases >> >> >> (no response >> >> >> to a multicast xRQ, but xRJ response to a unicast xRQ). >> The only >> >> >> indication that most IP stacks give as to how a message >> >> has arrived is >> >> >> by a port number, however, so if all GRQs appear to port >> >> 1718 (and all >> >> >> LRQs to port 1719), there is no way for the gatekeeper to >> >> tell whether >> >> >> the message arrived by unicast or multicast. >> >> >> >> >> >> Common (but not universal - at least in products under >> >> development!) >> >> >> usage, driven by these practical considerations, seems to >> >> be that the >> >> >> most common implementations send both sorts of multicast >> >> addresses to >> >> >> the registered address - 224.0.1.41:1718, and unicast >> GRQ and LRQ >> >> >> messages to port 1719 (unless there is some private arrangement >> >> >> specifying other special usage). >> >> >> >> >> >> My suggestion is that this common usage is standardised, >> >> initially via >> >> >> the implementer's guide, and then when appropriate in future >> >> >> versions of >> >> >> H.225.0. >> >> >> >> >> >> Regards, >> >> >> Chris >> >> >> >> >> > >> >> +1-503-264-8816(voice) Intel - Hillsboro, OR >> >> mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int >> >> PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >> >> >> > >> +1-503-264-8816(voice) Intel - Hillsboro, OR >> mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int >> PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >> > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: Ambiguity in H.225.0 Appendix D
by Chris Purvis 28 Jan '99

28 Jan '99

Jim, Following discussion, I take the point. Do we take it that we have agreement over the original point, though? This was my proposal to change the documentation of what ports are used for what (1718 for multicast RAS messages, 1719 for unicast), especially with reference to the LRQ case? Do we have sufficient agreement for it to make it into the implementer's guide? Chris > -----Original Message----- > From: Jim Toga [mailto:jim.toga@intel.com] > Sent: 18 January 1999 6:33 > To: Mailing list for parties associated with ITU-T Study Group 16 > Cc: CPurvis(a)MADGE.COM > Subject: Re: Ambiguity in H.225.0 Appendix D > > > Chris, > > The problem is that it is a _client_ issue as much as a GK issue. The > (enterprise) site administrator, wants to be assured that no > rougue client > will get on the network and simple start conferencing... If he has > 'compliant' stacks than he can be assured that GK policy will > be followed.... > > Regards, > jimt. > > At 05:59 PM 1/18/99 -0000, you wrote: > >Jim, > > > >Surely this could be left as a configuration option for the > administrator. > >If he doesn't want the assurance you describe, why shouldn't > he be allowed > >to configure it out of suitably-written gatekeepers? I > would expect it to > >be an unusual thing to want to do, bearing in mind your > comments, but is it > >the place of the standard to deny such possibilities? > > > >Chris > > > >> -----Original Message----- > >> From: Jim Toga [mailto:jim.toga@INTEL.COM] > >> Sent: 15 January 1999 1:47 > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: Ambiguity in H.225.0 Appendix D > >> > >> > >> There is a point behind having a GK respond to all GRQ messages. > >> > >> The administrator must be able to be assured that > >> unauthorized endpoints > >> (with compliant stacks) do not conference. H.323 stipulates > >> that _if_ GKs > >> are present, then endpoints must use them.... so if the GK > >> are present and > >> none of them will allow a particular endpoint to register - > >> then it is not > >> supposed to make/receives H.323 calls. > >> > >> The endpoint on the other hand, must be able to reasonably > detect the > >> difference between the complete absence of GKs and the > >> absence of 'their' > >> GK (especially if some specific control/policy is in place). > >> > >> If the GK receives a GRQ, it must respond with a (directed) > >> GCF or GRJ. > >> > >> jimt. > >> > >> > >> At 10:55 AM 1/13/99 -0800, you wrote: > >> >Hi, > >> > > >> >This is wrt the second problem in the attached mail. > >> >Chris Purvis mentioned that GK needs to know whether > >> >a GRQ or LRQ is received via multicast or unicast so that > >> >the response could be different. > >> > > >> >Actually, H.323 V2 specifies different multicast and unicast > >> >responses only in case of LRQ. In case of GRQ, spec specifically > >> >mentions that even in multicast case a response shall be > >> >given (Section 7.2.1 para three which _only_ talks about > >> >multicast GRQs). > >> > > >> >I believe spec should not mandate a GK to respond to > >> >a multicast GRQ. It should be left to the implementor whether > >> >a response should be sent out to a multicast GRQ or not. > >> >The GK may have some additional information like redirecting > >> >the endpoint to a different GK with altGKInfo etc, otherwise it > >> >is just plain waste of bandwidth to mandate GK's to respond to > >> >multicast GRQ's. The endpoints would time out if they > >> >haven't received a single GCF. > >> > > >> >May be the following line in para 3 of section 7.2.1: > >> > > >> >"If a Gatekeeper does not want the endpoint to register to it, > >> >it shall return Gatekeeper Reject (GRJ)" > >> > > >> >should be changed to something like: > >> > > >> >"On receiving a multicasted GRQ, if a Gatekeeper does not want > >> >the endpoint to register to it, it MAY return Gatekeeper > >> >Reject (GRJ)" > >> > > >> >Comments? > >> > > >> >Regards, > >> >-Kishore. > >> > > >> > > >> >> -----Original Message----- > >> >> From: Mailing list for parties associated with ITU-T > Study Group 16 > >> >> [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis > >> >> Sent: Thursday, January 07, 1999 9:33 PM > >> >> To: ITU-SG16(a)mailbag.cps.intel.com > >> >> Subject: Ambiguity in H.225.0 Appendix D > >> >> > >> >> > >> >> We have had an ambiguity show up during interoperability > >> >> testing, which > >> >> I would like clarified by means of the implementer's guide > >> and future > >> >> versions of the standard. Any objections, please shout in > >> the usual > >> >> way! > >> >> > >> >> The problem comes in 19.1.1.1 where UDP port numbers are > >> defined. The > >> >> standard currently (I'm looking at version 2) says: > >> >> Gatekeeper UDP Discovery Port 1718 > >> >> Gatekeeper UDP Registration and Status Port 1719 > >> >> > >> >> There are two problems with this. The first is that it > >> >> implies that the > >> >> LRQ message (which is nothing to do with discovery) always > >> needs to be > >> >> sent to port 1719, which is a problem for multicast LRQs, > >> because only > >> >> one IP address and port number pair has been registered with > >> >> the IETF - > >> >> 224.0.1.41:1718. > >> >> > >> >> The second problem is, if anything, more subtle... The > >> standard also > >> >> seems to imply by the above that GRQ, which is a > discovery message, > >> >> should always be sent to port 1718, whether it is sent to the > >> >> multicast > >> >> discovery port or not. > >> >> The reason this is a problem is that gatekeepers need to > >> know whether > >> >> these messages (GRQ and LRQ) have arrived by multicast or > >> by unicast, > >> >> because the failure response is different in the two cases > >> >> (no response > >> >> to a multicast xRQ, but xRJ response to a unicast xRQ). > The only > >> >> indication that most IP stacks give as to how a message > >> has arrived is > >> >> by a port number, however, so if all GRQs appear to port > >> 1718 (and all > >> >> LRQs to port 1719), there is no way for the gatekeeper to > >> tell whether > >> >> the message arrived by unicast or multicast. > >> >> > >> >> Common (but not universal - at least in products under > >> development!) > >> >> usage, driven by these practical considerations, seems to > >> be that the > >> >> most common implementations send both sorts of multicast > >> addresses to > >> >> the registered address - 224.0.1.41:1718, and unicast > GRQ and LRQ > >> >> messages to port 1719 (unless there is some private arrangement > >> >> specifying other special usage). > >> >> > >> >> My suggestion is that this common usage is standardised, > >> initially via > >> >> the implementer's guide, and then when appropriate in future > >> >> versions of > >> >> H.225.0. > >> >> > >> >> Regards, > >> >> Chris > >> >> > >> > > >> +1-503-264-8816(voice) Intel - Hillsboro, OR > >> mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > >> PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 > >> > > > +1-503-264-8816(voice) Intel - Hillsboro, OR > mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >

1 0

Re: APC number allocation
by Sakae OKUBO 27 Jan '99

27 Jan '99

Dear Mr. Klaghofer, > Please allocate APC numbers for the following two contributions for the > Monterey meeting: > > > * "Draft H.450.8 - Conference out of Consultation Supplementary > Service for H.323" > > and > > * "CallIdentifier and ConferenceIdentifier value setting in H.450.2 > and H.450.3" APC-1505, APC-1506 have been allocated, respectively. I have indicated the source as Editor (M korpi) and Siemens in the attached list. Please advise me if this is not correct. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 ----------------------------------------------------------------------

1 0

Re: Voice stream multiplexing
by 星徹 27 Jan '99

27 Jan '99

Ronen Goory wrote: > > I would like to know if the VoIP forum decided on a standard for voice > stream multiplexing? > Is there any proposals except the Hitachi proposal? There are two proposals from Hitachi and Nokia. > > IETF AVT working group proposed at least 4 drafts to implement it, does the > VoIP forum intend to corporate with IETF on that issue? In my understanding, VoIP Forum closed the discussions about multiplexing, because the IETF started the discussion on the same topic. Those two proposals having been submitted to VoIP Forum are submitted to IETF avt-wg -- Tohru Hoshi Network Technology Development Center Systems Development Laboratory, Hitachi,Ltd. 292 Yoshida-cho, Totsuka-ku, Yokohama 244 Japan TEL:045-881-1241 (ext 4845), FAX:045-860-1675 email:hoshi@sdl.hitachi.co.jp

1 0

Proposed Corrections to Phase B (for Implementors Guide)
by Dave Walker 27 Jan '99

27 Jan '99

I would like to hear people's opinion on whether we should modify the requirements of Call Signalling Procedures Phase B (section 8.2 of H.323v2). In particular, I want to remove the requirements that Terminal Capability Set be the first message sent on the H.245 Control Channel, and the requirements that terminal capability exchange and Master-Slave determination complete before anything else is permitted on the control channel (this requirement may only be implied). I think that it was probably only due to oversight that these changes weren't included in version 2 when other text was approved which necessitated less stringent requirements. So my proposal is that these changes be captured in the Implementors Guide and then rolled into H.323 version 3. To show the proposed changes to the text in ASCII, I'll bracket text to be inserted like this: <ADD>new text to be inserted</ADD> and text to be removed like this: <DEL>existing text to be removed</DEL>. The first paragraph of 8.2 requires that an H.245 Control Channel be established once the Phase A call signalling exchange is completed. This requirement should not always apply, for example, where Fast Connect has been used. So the proposed change is: Once both sides have exchanged call set-up messages from Phase A, the endpoints shall<ADD>, if required,</ADD> establish the H.245 Control Channel. The procedures of Recommendation H.245 are used over the H.245 Control Channel for the capability exchange and to open the media channels. Paragraph 3 requires that the first H.245 message sent shall be the terminalCapabilitySet. This is not always necessary or desireable. For example, - The Fast Connect procedure was used, and now I simply want to send a UserInputIndication through the available but as yet unused H.245 tunnel (TerminalCapabilitySet and Master- Slave Determination messages haven't been sent yet). At least partial support for UserInputIndication is mandatory, so I shouldn't have to go through full capability exchange and Master-Slave Determination just to send a keypress. Section 8.2 does not actually require that TCS procedures *complete* prior to the next H.245 message being sent (so a userInputIndication could be sent in another message immediately after sending the message containing the TCS). But section 8.1.7.2 states that where Fast Connect has been used, "When H.245 procedures are activated, all mandatory procedures of H.245 that normally occur upon initiation of an H.245 connection shall be completed prior to initiation of any additional H.245 procedures". This implies (by the requirements of 8.2) TCS exchange and Master-Slave Determination. Regardless, at least two TCP messages are required to get the UserInputIndication sent. - In the white paper for H.323 Annex F, H.245 tunnelling support is mandatory (at least for transmission of UserInputInd, and possibly other reasons such as "conference-awareness"), yet a SUD may only send an empty TCS. But reception of an empty TCS at the peer has the effect of resetting H.245 state, and probably closing media channels. - Both endpoints have a priori knowledge of each other's capabilities, obviating the need for successful completion of the terminal capability exchange procedure prior to performing other H.245 operations. So the proposed change is: Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message <DEL> shall</DEL><ADD>should</ADD> be the first H.245 message sent.<ADD> If, prior to successful completion of terminal capability exchange, any other H.245 procedure fails, is rejected, is not understood, or not supported, and the reason for such an outcome is the incomplete nature of the capabilities exchange, then before retrying the procedure the terminal capability exchange should be performed as specified in Recommendation H.245.</ADD> There are a couple of minor associated changes that I will list at the bottom. The fourth paragraph contains a requirement that Master-Slave determination take place. Master-Slave Determination is used for a variety of purposes, such as to choose MC for a conference, for determining a master for resolving conflicting requests such as may arise in opening bi-directional channels, and for assigning sessionIds. Endpoints exist which will use only well-known sessionIds, will never issue a potentially conflicting request and which will not act as an MC. Therefore the proposal is to change the text as follows: <ADD>Except as otherwise allowed by this clause, the</ADD><DEL>The </DEL>master-slave determination procedure of H.245 shall take place as described in 6.2.8.4. In cases where both endpoints in a call have MC capability, the master-slave determination is used for determining which MC will be the active MC for the conference. The active MC may then send the mcLocationIndication message. The procedure also provides master-slave determination for opening bidirectional channels for data.<ADD> An endpoint which will not act as an MC and which will not require a master entity on the call may choose not to initiate the master-slave determination procedure, however if that procedure is initiated by a peer endpoint, the procedure must be supported as described in Recommendation H.245.</ADD> The proposed changes to capability exchange and master-slave determination requirements also affect the final paragraph of section 8.2, which should be changed as so: Following <DEL>this exchange of capabilities</DEL><ADD>successful completion of the requirements of Phase B</ADD>, the endpoints shall proceed directly to the desired operating mode, <DEL>i.e. </DEL><ADD>normally</ADD> Phase C. In addition to redundantly requiring exchange of capabilities and master-slave determination, Phase C of the H.323 Call Signalling procedures currently implies that these procedures must be followed by opening logical channels. There exist circumstances where there is no need to open logical channels at this time, so that the first paragraph of section 8.3 should be clarified to read: <DEL>Following the exchange of capabilities and master-slave determination, the procedures of Recommendation H.245 shall then be used to open logical channels for the various information streams. </DEL><ADD>Following the opening of the H.245 Control Channel in Phase B, only the procedures of Recommendation H.245 shall be used to open logical channels for the various information streams.</ADD> The audio and video streams, which are transmitted in the logical channels set-up in H.245, are transported over dynamic TSAP Identifiers using an unreliable protocol (see Recommendation H.225.0). Data communications which is transmitted in the logical channels set-up in H.245, are transported using a reliable protocol (see Recommendation H.225.0). Regards, Dave Walker Mitel Corporation Ontario, CANADA

1 0