- sg16-avd - lists.packetizer.com

FW: TIA to create IP phone performance & interoperability reqts s td
by Nancy-M Greene 03 Feb '99

03 Feb '99

The following may be of interest to some of you. The Telecommunications Industry Association (TIA) has started a new project (TR-41.3.4) to create a standard for "Performance and Interoperability Requirements for VoIP Telephone Terminals. First meeting will be the Monday of the next TIA meeting Feb 15-19 in Sarasota. They plan to establish relationships with related work in the IETF, ITU and ETSI. > Press release is online at > http://www.tiaonline.org/pubs/press_releases/1999/99-11.html > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: APC-1495 uploaded
by Sakae OKUBO 03 Feb '99

03 Feb '99

Dear Mr. Kajos, > APC1495.zip has been uploaded to the incoming directory. This has been moved to /9902_Mon directory. > Please leave H341wht6.{zip,doc} in the incoming directory a few > days to allow people on the reflector to get the document. Many > people can't get mail attachments of files that large. Understood. 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

APC numbers
by Sakae OKUBO 02 Feb '99

02 Feb '99

Dear Ping Wang, Dear Robert Callaghan, Dear Francois Audet, In response to your requests, APC numbers have been allocated to your contributions as attached. 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 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber ----------------------------------------------------------------------

1 0

Re: TPKT in H.225.0
by Tom-PT Taylor 02 Feb '99

02 Feb '99

I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I can't find it there now. > -----Original Message----- > From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] > Sent: Tuesday, February 02, 1999 4:05 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: TPKT in H.225.0 > > Hi Paul, > > I received two responses to my question, one from you and one from Tom > Taylor. The fact that there are at least two people that know about it > (and > several dozens more that have actually implemented the protocol stacks), > makes it hard to believe that this is an "oversight" in the > recommendation. > In fact, not knowing about this makes it impossible to implement an > interoperable protocol stack! Shouldn't action be taken to get this into > the > recommendation ASAP (e.g. through the Implementor's Guide)? > > Regards, > > Frank > > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 01 February 1999 18:50 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: TPKT in H.225.0 > > > TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that > has > never been fixed in the Recommendation. > > Paul Long > Smith Micro Software, Inc.

1 0

Re: Madge contributions for Monterey Meeting
by Sakae OKUBO 02 Feb '99

02 Feb '99

Dear Mr. Purvis, In response to your request, APC-1510, 1511 and 1512 have been allocated to your three contributions as attached. 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 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide ----------------------------------------------------------------------

1 0

Re: TPKT in H.225.0
by Derks, Frank 02 Feb '99

02 Feb '99

Hi Paul, I received two responses to my question, one from you and one from Tom Taylor. The fact that there are at least two people that know about it (and several dozens more that have actually implemented the protocol stacks), makes it hard to believe that this is an "oversight" in the recommendation. In fact, not knowing about this makes it impossible to implement an interoperable protocol stack! Shouldn't action be taken to get this into the recommendation ASAP (e.g. through the Implementor's Guide)? Regards, Frank -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: 01 February 1999 18:50 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: TPKT in H.225.0 TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that has never been fixed in the Recommendation. Paul Long Smith Micro Software, Inc.

1 0

APC-1492, 3, 4
by Sakae OKUBO 02 Feb '99

02 Feb '99

Dear Mr. Roy > I am enclosing the following contributions for posting in the ITU-T > SG16 Web site for the upcoming conference: > > <<APC-1492.DOC>> <<APC-1493.ppt>> <<APC-1494.doc>> They have been zipped and placed at the following directory: ftp://standard.pictel.com/avc-site/9902_Mon/ or http://standard.pictel.com/ftp/avc-site/9902_Mon/ 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

Reminder for Monterey meeting document submission
by Sakae OKUBO 01 Feb '99

01 Feb '99

Dear Q.12-14/16 experts, This is a reminder for the document submission to the Monterey meeting. /// Registration of the document: by 5 February /// /// Distribution of the document: by 8 February /// /// Use the ftp site (or e-mail reflector) for distribution /// The current list of registered documents is attached. Please note the following excerpt from Section 2/APC-1485 (Report of the Torino meeting): ------------------------------------------------------------------- The meeting notes that contributors are requested to upload the documents on time, otherwise their proposals can legitimately be rejected on the ground that the group members lack reviewing time. Contributors are also requested to pay attention to the ITU-T copyright policy when producing their documents. ------------------------------------------------------------------- Please quickly advise me if anyone is planning to submit a contribution or have discussion on the security aspects at the Monterey meeting. This question has been placed by some security experts. 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: TPKT in H.225.0
by Tom-PT Taylor 01 Feb '99

01 Feb '99

TPKT is a necessary addition to TCP-based messaging, to provide advance delineation of individual messages. TCP by itself doesn't do this very well, since it is stream-oriented. See RFC 1006 as you indicate. > -----Original Message----- > From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] > Sent: Monday, February 01, 1999 12:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: TPKT in H.225.0 > > > I am trying to make some sense out of H.225.0. Section 6.1 (in versions 2 > and 3) refers twice to TPKT: "In IP implementations as outlined in > Appendix > D, this packet is defined by TPKT". Appendix D shows an unnumbered figure > that indeed has the acronym "TPKT" in it. However, from this it is still > not > quite clear what TPKT is. What is the purpose of mentioning it 6.1 if it > is > not specified/explained anyway? If TPKT is nothing else than one (whole) > Q.931/H.245 PER encoded message (pre-pended with the relevant Q.931 fields > in the case of "Q.931") then the recommendation could be less ambiguous > about it. The reference to the appendix leads one to believe that further > inofrmation can be found there, whereas the preceding text already > explains > what TPKT is. > > Furthermore, the list of abbreviations does not list it either. > > > Regards, > > Frank > > > P.S. > > Does this "TPKT" have anything to do with "TPKT" as used in RFC1006? > > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > Advanced Development |Fax +31 35 6891030 | > Philip Business Communications |P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:f.derks@pbc.be.philips.com | > WWW: http://www.business-comms.be.philips.com | > ----------------------------------------------------- > > <<Frank Derks (E-mail).vcf>> << File: Frank Derks (E-mail).vcf >>

1 0

Re: TPKT in H.225.0
by Paul Long 01 Feb '99

01 Feb '99

TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that has never been fixed in the Recommendation. Paul Long Smith Micro Software, Inc.

1 0

TPKT in H.225.0
by Derks, Frank 01 Feb '99

01 Feb '99

I am trying to make some sense out of H.225.0. Section 6.1 (in versions 2 and 3) refers twice to TPKT: "In IP implementations as outlined in Appendix D, this packet is defined by TPKT". Appendix D shows an unnumbered figure that indeed has the acronym "TPKT" in it. However, from this it is still not quite clear what TPKT is. What is the purpose of mentioning it 6.1 if it is not specified/explained anyway? If TPKT is nothing else than one (whole) Q.931/H.245 PER encoded message (pre-pended with the relevant Q.931 fields in the case of "Q.931") then the recommendation could be less ambiguous about it. The reference to the appendix leads one to believe that further inofrmation can be found there, whereas the preceding text already explains what TPKT is. Furthermore, the list of abbreviations does not list it either. Regards, Frank P.S. Does this "TPKT" have anything to do with "TPKT" as used in RFC1006? ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com | ----------------------------------------------------- <<Frank Derks (E-mail).vcf>>

1 0

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 Chris Purvis 01 Feb '99

01 Feb '99

Paul (and others), Consider the case of a v1 gatekeeper routing H.225.0 and NOT H.245 in a call between two v2 endpoints. The gatekeeper certainly MAY relegate the H.225.0 messages to v1. This may be a policy decision, or it may be due to stack capabilities. Note that the gatekeeper may not always desire to relay messages entirely transparently, and is entirely within its rights to make this sort of alteration (although people writing H.323 stacks for gatekeepers would probably be well advised to implement relaying of messages or message fragments). Certainly the standard should not mandate that message relay should be entirely transparent. Anyway, the upshot of this is that all H.225.0 messages in the call will be relegated to v1 by the gatekeeper. The H.245 session runs directly end-to-end and will hence be version 3, so both endpoints in the call need to be able to cope with an H.245 session of a different version from that implied by the H.225.0 session. Similar discrepancies may occur in the opposite direction (later version of H.225.0 than H.245) for similar, but marginally more complex reasons. So what do we gain by insisting on an endpoint supporting EXACTLY version 3 of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice versa? Although I agree that it is what is currently specified I'm unconvinced it buys us anything. Regards, Chris > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 29 January 1999 8:09 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Relationship of H.323 and H.245 versions > > > 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 > ------------------------------------------------------ >

2 1

SUD white paper
by Chris Purvis 01 Feb '99

01 Feb '99

Joerg, Many apologies for the delay in sending these comments. I've studied your contribution on Single Use Devices, and have a number of points and questions, both editorial and substantive: Substantive: 1. How does a third party know whether a SUD with which it is communicating is conference-aware? Section 7.3.4.9 states that certain capabilities shall be assumed to be "TRUE/FALSE as appropriate, default FALSE", and I am not clear as to how someone communicating with it knows what to assume. 2. (Also in conferencing.) It is possible for an MCU to detect a need for the common mode of a conference to change (someone may join it without capability for the current common mode of the conference, while there is still an alternative common mode). Section 7.3.5 states that "Open Logical Channel messages outside the FastConnect procedure shall only be used to alter media transport parameters", which I take to exclude a change of audio mode, and in 7.7.2.3 CommunicationModeCommand is specifically given as optional (I understand it to be mandatory in "real" H.323, although I appreciate that not everybody understands it). How can I achieve a change of mode of a conference-aware SUD which is already in a conference? This will affect interoperability with real MCUs. 3. If the procedure described in section 7.6.1 (on third-party initiated pause and rerouting) is considered useful, maybe it should be added as an option for calls which have been fastConnected in full version 2 endpoints? I see it as yet another option that would need to be supported, but if it needs to be supported for SUDs we may as well support it in the standard for everybody. Using H.450.Hold is probably a better solution, but is harder work for the SUD. 4. A number of points in the paper give details of what to assume in cases where no capability exchange has happened. These can apply equally well to calls involving only "full" H.323 endpoints using fast connect procedures, and should be added to the main standard (probably initially through the implementer's guide). I refer in particular to sections 7.3.4.4-7.3.4.9. 5. Sections 7.1 and 7.2 both refer to the "sud" component of the H.225.0 EndpointType. I can not find this in H.225.0 version 2, which I understand to be the relevant version. I assume the purposes of this are a) to mandate a gatekeeper to route call signalling b) to inform the gatekeeper not to try to do real capset exchange. 6. Incidentally, you are mandating gatekeepers to route H.225.0 AND H.245 messaging (not many do the latter yet!), and to cope with routing a call from an endpoint which does not support faststart with one that does not support "traditional" H.245 procedures. This gives me an uncomfortable feeling, because the caller may, for example, not be able to give its capabilities until after Connect (yes, there ARE endpoints around that act like this), but the callee requires the information in Setup. Is the gatekeeper required to setup a whole call on one side (including starting billing, which is what "Connect" implies) before even ringing the phone on the other side? Or should it fall back on an assumption of G.711? Given the significant amount of work this requires from what are described as "SUD-aware gatekeepers", it may be useful to document the responsibilities of such an entity. 7. In section 7.3.2.7, I am not convinced about the interpretation of H.245 EndSession as call termination. As I understand it, it does not have that meaning to a "full" H.323 endpoint as long as the H.225 session is still up. 8. If I understand correctly what you're trying to say in the statement immediately before section 7.3.2.1, it is actually making two separate points that need to be stated explicitly, namely: a) If a SUD Audio terminal receives a tunnelled H.245 message it doesn't understand, it should ignore it and continue as if it had not received it (certainly not crash). b) Other devices attempting to interoperate with SUDs need to be aware that tunnelled H.245 messages not specifically mentioned in Annex F may be ignored, and need to be able to cope with this possibility without bad failure conditions occurring. What is the reasoning behind ignoring these messages rather than returning "functionNotSupported" or "functionNotUnderstood"? Editorial: 9. I find figure 1 less than helpful. It appears to me to be ambiguous and even misleading. 10. A few times "audion" appears in place of "audio". Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

1 0

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

H.323 text conversation contributions
by Gunnar Hellstrom 27 Jan '99

27 Jan '99

Dear Mr. Okubo, I would like to register two contributions for the upcoming meeting. - H.323 Annex "Text", Text Conversation Capable SUD. (First proposal) - Text conversation in H.323. (Proposed structure ) Please assign two APC numbers. Both are proposals, I suggest that both are discussed under "point 3, discussion of new SUDs, even if the second is of a more general nature even valid for full Multimedia systems and gateway implementations. Best regards, Gunnar Hellström SWEDEN _____________________________________ Gunnar Hellström Omnitor Alsnögatan 7, 4 tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 Text: (V.21) +46 8 556 002 02 e-mail gunnar.hellstrom(a)omnitor.se www: http://www.pi.se/~omnitor Video +46 8 556 002 05 -------------------------------------

2 2

Re: Multiple aliases in ARQ destinationInfo
by Chris Purvis 27 Jan '99

27 Jan '99

Santo, Well let's forward it to the implementers' list and see if that adds to the breadth of the discussion. I may be being naive in expecting a large intersection of subscribers... More comments of mine inline. Regards, Chris > -----Original Message----- > From: Santo Wiryaman [mailto:swiryaman@VIDEOSERVER.COM] > Sent: 26 January 1999 4:18 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Multiple aliases in ARQ destinationInfo > > > Hi Chris, > Yes, we do need an agreement. On the WHAT part, may I suggest the > following: how should a GK treat multiple aliases in an ARQ? > > The answer should consider the following (and some others > which I might > have missed): > 1. ARQ from the caller (this is the main topic for the question) > 2. SETUP. In a GK-routed, pre-granted situation, the GK does > not get the > ARQ so the SETUP may contain multiple aliases > 3. ARQ from the callee. Would this ARQ contain multiple > alias, too? If so, > what does it mean? > 4. ARQ from the caller contain multiple aliases and > destCallSignalAddress > What ought the GK do? > 5. What should be returned in the ACF? > 6. What to do with LRQ's (rules for sending, receiving)? I'll agree with all of those. > Here is my vote: > 1. At a minimum, a GK shall do interpretation #1: use the > first alias and ignore the rest > 2. The GK may optionally look at the other aliases. The > interpretation of these multiple aliases shall be > determined by the particular site / administrative > domain. I would prefer to standardise what happens in 2, because of problems across multiple zones/sites/administrative domains. > Incidentally, I just realized that these discussions were on the SG-16 > mailing list > and not on the h323Implementors list. I wonder if that might > be a reason > for not > hearing from other folks? There's only one way of finding out! > I also have a question on what you mean by consistency check > of the GK dbase > during the ARQ. What are you trying to detect in this case? > I re-read your > previous > email and got the following: > > >Hence what I believe SHOULD happen is that the gatekeeper > >1. If it can match anything within its zone, should ensure > that different > >aliases in the ARQ do not point to different destinations > within the zone. > >If there is such disagreement, the GK should return ARJ. > > It seems that the above check would prevent Paul Long from > doing what he was > suggesting, i.e. call "#@home, #@work, #@mobile_phone, #ofFaxMachine", > because more than one of those devices may be in the same zone. What I meant was that if a user's home AND work numbers are specified in an ARQ, a sufficiently clever, sufficiently configured gatekeeper may be able to work out that they refer to the same people and work out what best to do with the request (if, for instance, it knows that currently the only way to get hold of this person is via their mobile phone, this is what it will return in an ACF). If on the other hand two numbers in an ARQ specify different people (Fred and Joe's separate work phone numbers) I would consider the most sensible behaviour to be to reject the request with a useful (TBD) error code. There are arguments against this: What do you do with an ARQ containing one number you've heard of and one you haven't? If you accept this (which seems sensible with regard to gateways for example), there is the problem of what happens when the number you used not to have heard of suddenly appears on the system? The answer is that now the user who used to get a sensible result when he tried to make a call from his address book doesn't any more. Is this acceptable? Maybe best would be to specify in the implementer's guide that only one alias is to be used in the ARQ? I don't like this though, because I'd like to be able to use gateways without complicated prefixes (maybe this is never going to be possible). Regards, Chris > > > Regards, > > -santo > > > > > -----Original Message----- > > From: Chris Purvis [SMTP:CPurvis@MADGE.COM] > > Sent: Tuesday, January 26, 1999 5:05 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Multiple aliases in ARQ destinationInfo > > > > > From the various views expressed in this thread, I think it > > > is clear that > > > until at least a consensus is formed on the semantics of > > > multiple aliases in > > > ARQ's destinationInfo, an EP had better send a single alias > > > if the user has > > > any hope of predictable--not necessarily > > > deterministic--behavior. As with many > > > things H.323, _caveat transmittor_. > > > > Do we really think this is acceptable? Frankly I'll > happily ensure that > > the > > Madge gatekeeper does any of the sensible options in the > interests of > > predictable behaviour! My vote would be for checking consistency of > > aliases > > within the GK's database (because it really ought to enable > endpoints to > > give the user more meaningful error messages than a wrong > number), but we > > can go with first past the post if we can reach concensus that way. > > > > We COULD make it configurable, but I have a bad feeling about that. > > 1. What does it gain anybody over specifying something > (except even more > > user-confusion)? > > 2. Assuming we want to define the same behaviour for LRQs > in a multiple > > gatekeeper environment (which seems sensible), people may > get results that > > surprise them due to different gatekeepers being > differently configured. > > > > Can we start by agreeing over whether we need agreement (I > say we do), and > > then, if we DO think we need agreement, agree on WHAT? > > > > Regards, > > Chris > > -- > > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > > ENGLAND > > Phone: +44 1753 661 359 email: cpurvis(a)madge.com >

1 0