February 1999 - sg16-avd - lists.packetizer.com

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 02 Feb '99

02 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