- sg16-avd - lists.packetizer.com

Re: H.323 delta doc
by Bruce Allen 11 Jan '98

11 Jan '98

DUh. I forgot to attach it! -----Original Message----- From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] Sent: Friday, January 09, 1998 6:01 PM To: ITU-SG16(a)mailbag.jf.intel.com Subject: H.323 delta doc Hi all, Attached is the Delta document for H.323. I did not include any changes for nonStandard or Fast Start as I did not hear a widely accepted proposal. If I missed anyones comments, please let me know. 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 ------------------------------------------------------ << File: H323DL.DOC >>

2 1

H.323 delta doc
by Gary A. Thom 09 Jan '98

09 Jan '98

Hi all, Attached is the Delta document for H.323. I did not include any changes for nonStandard or Fast Start as I did not hear a widely accepted proposal. If I missed anyones comments, please let me know. 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

Changes to the H.450.1 and H.450.2 white drafts
by Korpi Markku PN VS LP3 09 Jan '98

09 Jan '98

Greetings, Attached is a delta document describing the the changes to the H.450.1 and H.450.2 white drafts to address the issues discussed on the reflector. There are currently no changes to H.450.3. The intent is for this change document and the final documents to be submitted next week for distribution to the SG16 meeting. Please let me know if I've missed anything. Best Regards, Markku ---------------------------- Markku Korpi korpim(a)scn.de Siemens Private Communication Networks Tel +49 89 722 34570 Mobile +49 171 3345338 Fax +49 89 722 39335

1 0

Phase transition in H.310 and H.324
by Sakae Okubo 09 Jan '98

09 Jan '98

Dear SG16 colleagues, Attached please find my correspondence with Seung ho SHIN, Korean Telecom, regarding the phase change from A4 (logical channels setup) to B (audiovisual communication) in H.310 terminals. The same discussion will apply to the phase change from D (initialization) to E (communication) in H.324 terminals. I hope my understanding in the reply is correct. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Dear Seung ho SHIN, >In phase A4(logical channels setup), which is one of H.310 call phases >for native H.310 communication, H.310 terminal establishes multiple >logical channels. After completing logical channels setup, H.310 >terminal transit from phase A4 to phase B. The out-going terminal can >know the instant that H.245 completes multiple logical channels setup. >But the in-coming terminal can't know it. > >The in-coming terminal can't know how many the out-going terminal >attempts to setup logical channels. Therefore, the in-coming terminal >doesn't know when it transits from phase A4 to phase B. > >How can I solve this problem? Communication phases set out in Section 7 of H.310 are to describe the communication steps from the start to the end of an H.310 call, not necessarily to specify state machines of the terminal. In case of moving from phase A4 (logical channels setup) to Phase B (audiovisual communication), there is no clear state transition of the terminal as a whole. As soon as a logical channel is in the ESTABLISHED state, its corresponding media content (either of audio, video, data, or video frame synchronous signalling) can be transmitted, thus communication can start. Transmission of multiple media contents can be synchronous, or can be audio first and video later, or can be left as they start according to the terminal design. Data, in particular, may usually start some time after audio and video communications have started. Therefore even in the transmitting side, transition from phase A4 to phase B differs from one logical channel to another. Identification of phase transition at the receiving side similarly depends on each logical channel. Please note, however, that H.245 defines state machines for their signalling entities to assure their operation. I hope this information would help your resuming H.310 terminal implementation. END

1 0

T.120/H.323 Harmonization Changes
by Pat Galvin 08 Jan '98

08 Jan '98

Hi everyone, Alas, someone has found a problem with the proposal that was posted on Tuesday. The problem is as follows: When communicating through a "pass-through" Gateway to an H.320 endpoint, it is possible for the H.320 endpoint to issue an unsolicited Query at any time. Normally this won't happen after a T.120 connection has been established. But it can happen during the establishment of the T.120 connection. So, if the H.323 endpoint initiates an OLC, and is told by the Gateway to issue a Query, it is possible that the H.320 endpoint will also issue a Query before the T.120 connection is actually established. In this case, the Gateway MUST know the address of the H.323 endpoint (in order to forward the Query), even though it has already told that endpoint to place the call. This illustrates a case where one endpoint needs the address of the other for unpredictable reasons. The easiest way to ensure that endpoints will always have the addresses they need is to mandate that BOTH endpoints shall ALWAYS include their transport address in the OLC exchange (in both the OLC and the OLC Ack), and that those transport addresses will remain valid for the duration of the logical channel. The point of these proposals is to increase the flexibility of the OLC procedures to handle even the most complex cases. But there has been some concern that there is not enough guidance on how to handle the simple cases. To this end, a new sentence has been added stating that if neither one of the endpoints has a preference on setting up the T.120 call, then the call will follow the direction of the H.323 call. Endpoints that need to do something different can override this default behavior on an as-needed basis. The suggested changes to Tuesday's proposal are as follows: CHANGE #1: The following sentences: If the initiator is the slave, it shall include a transport address in the openLogicalChannel message. If the initiator is the master, it may decide whether or not to include a transport address in the openLogicalChannel message. In either case the peer endpoint may choose to ignore the transport address. will change to: The initiator shall include a transport address in the openLogicalChannel message. The peer endpoint may choose to ignore the transport address. CHANGE #2: The following sentences: In the openLogicalChannelAck, the responder shall include a transport address to be used for set-up of the T.120 connection if it expects the initiator to originate the T.120 call (this will always be the case if it did not receive a transport address from the initiator). Otherwise, the transport address shall be absent. In all cases, the transport address for the T.120 connection shall be carried in the separateStack parameter. will change to: In the openLogicalChannelAck, the responder shall include a transport address, even if it expects the initiator to originate the T.120 call. In all cases, the transport address shall be carried in the separateStack parameter, and shall remain valid for the duration of the logical channel. CHANGE #3: In the next two paragraphs, the text explains how the t120SetupProcedure is to be used. For each choice, in each paragraph, there is a sentence describing when to include a transport address. All of these sentences will be removed, since the transport address will always be included. CHANGE #4: In the paragraph on how the responder uses the t120SetupProcedure, the following sentence will be added: If neither endpoint has a preference, the T.120 call should be established in the same direction as the H.323 call. If these changes are OK with everyone, I will merge them into the document posted on Tuesday before providing it to the editors of H.323 and H.245. Thanks. ------------------------------------ Pat Galvin pgalvin(a)DataBeam.com Phone: +1-910-854-3551 Fax: +1-910-854-1983

1 0

Comments on Seection_8_rev
by Li Yan 08 Jan '98

08 Jan '98

Dear Mr. Okubo, Mr Harasaki, and other Q.12/16 experts, Attached please find some comments regarding open logical channel and Section_8_rev.mw6. Best regards, Li Yan **************************************************************** Lucent Technologies Phone: 732-957-3877 2E-433, 200 Laurel Ave., Fax: 732-957-5627 Middletown, NJ, 07733 E-amil:lyan@lucent.com U.S.A. **************************************************************** 1. Open logical channels for the 1st terminal, 2nd terminal, etc. SO> One point I need your views is the way to open logical channels. In SO> Section 8.3.1 (first terminal added to the conference), the text SO> reads As follows: SO> "After establishment of the additional VC(s), the procedures of SO> H.245 shall be used to open the desired video, audio, data, and/or SO> control logical channels using logical channel signaling protocol SO> and bi-directional logical channel signaling protocol defined in SO> H.245." SO> In Sections 8.3.2 (second terminal added to the conference) and SO> 8.3.3 (third terminal added to the conference), however, it reads as SO> follows: SO> "An MCU shall open the desired video, audio, data, and/or control SO> logical channels using the logical channel signaling protocol and SO> bi-directional logical channel signaling protocol defined in H.245." SO> The difference is intentional? If uni-directional logical channel SO> Signaling is used, not only MCU but also the terminal should SO> establish the logical channel, otherwise we cannot have SO> bi-directional video transmission, for example. If all logical SO> channels are bi-directional, then there is a reason for MCU to open SO> them because it is the master. Note that H.310 strongly recommends SO> to use the bi-directional logical channel signaling if the media is SO> bi-directional. SO> The first description is applicable to all the cases, while the SO> second description may be more appropriate to the current multipoint SO> case. In the latter case, we need to add some language that the SO> logical channels should always be bi-directional. SO> Any thoughts? My original text was focus only on tightly coupled MCU ( VC connection configuration a)), where bi-directional logical channels are always used for all the terminals connected to MCU. Now, since we want the procedures to cover other connection configurations, such as in Figure 2, b), c), and d), your changes to use the first description to replace others are more proper. 2. Can we change the "under working" in 8.5.2, 8.6, and exceptional procedures to "For further study"?

1 0

Missing references (in all H.323 standards)
by Orit Levin 08 Jan '98

08 Jan '98

Dear editors! We think that the following references should be added: In all of H.323 standards reference to X.680 Amendment 1 (Rules of Extensibility) In addition in H.450.1 reference to X.681 Amendment 1 (Rules of Extensibility) Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516

1 0

Fast start and call centres
by Pete Cordell 08 Jan '98

08 Jan '98

Jim (or anybody else), Please can you run through how fast start would work if H.323 was used to connect to a call centre which first played you a message saying something like "Thank you for your call. You are in a queue...", and then when an agent freed up, it connected you to the agent. Giving me an example might help me to understand better where you are coming from. Thanks, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: corrections to H.225.0 V2
by Pete Cordell 08 Jan '98

08 Jan '98

Glen, One thing mentioned on the reflector was moving the CallIdentifier to the H323-UU-PDU part of the message rather than including it separately in each constituent part of the message. This moves it to the highest layer of commonality and also means that it is in the same place for all messages. This is important as the module that decides which call the message belongs to should not really have to know large amounts about the format of each message. Below should show the change I mean: H323-UU-PDU ::= SEQUENCE { h323-message-body CHOICE { setup Setup-UUIE, callProceeding CallProceeding-UUIE, connect Connect-UUIE, alerting Alerting-UUIE, userInformation UI-UUIE, releaseComplete ReleaseComplete-UUIE, facility Facility-UUIE, ..., progress Progress-UUIE, empty NULL -- used when a FACILITY message is sent, -- but the Facility-UUIE is not to be invoked -- (possible when transporting supplementary -- services messages) }, nonStandardData NonStandardParameter OPTIONAL, ..., h4501SupplementaryService SEQUENCE OF OCTET STRING OPTIONAL, -- each sequence of octet string is defined as one -- H4501SupplementaryService APDU as defined in -- Table 3/H.450.1 callIdentifier CallIdentifier } Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Glen Freundlich[SMTP:ggf@LUCENT.COM] >Sent: 07 January 1998 22:54 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: corrections to H.225.0 V2 > ><<File: h2250v2x.doc>> >Dear colleagues, > >Attached is a document describing changes to the H.225.0 V2 white draft >to address various issues I've seen through email. The intent is for >this change document to be submitted to the SG16 meeting. Please review >the document as soon as possible and let me know if I've missed >anything >or made some other error. I have not yet addressed issues regarding the >pointer to RFC2190 for H263. > >In addition, I've compiled the ASN.1 but would appreciate if someone >else could also compile it to be sure it is sane. > >Thank you, >Glen > > >-- >Glen Freundlich ggf(a)lucent.com >Lucent Technologies office: +1 303 538 2899 >11900 N. Pecos fax: +1 303 538 3907 >Westminster, Colorado 80234 USA > >

1 0

Comments on H.bmultipoint
by Li Yan 08 Jan '98

08 Jan '98

Dear Mr. Okubo, Mr. Harasaki and other Q.12/16 experts, Attached please find some comments on the suggestions/changes proposed by Mr. Okubo and Mr.Haraski. Thanks, Li Yan **************************************************************** Lucent Technologies Phone: 732-957-3877 2E-433, 200 Laurel Ave., Fax: 732-957-5627 Middletown, NJ, 07733 E-amil:lyan@lucent.com U.S.A. **************************************************************** 1. Structure of Chapter 5 and Chapter 7 SO> I would suggest to leave in Chapter 5 the current 5.1 Various VC SO> connection configurations, explanations of "meet-me" and "dial-out" SO> and general configuration of MCU as described in 5.2 and illustrated SO> in Figure 3, but to move other materials (5.3 and subsequent SO> sub-sections) to Chapter 7 and merge them with the materials there. If SO> this idea is agreeable, the title of the current 5.2 should exclude SO> "characteristics" and the description should be without "shall". This is fine with me. 2. Figure 3 and functions of MC, MP, MR and network Interface SO> MC handles DSS2 call signaling and H.245 control signaling in AAL SO> or higher layers of each port to the terminal. In addition to them, MC SO> contains intelligence on top of DSS2 and H.245 handling to manage SO> multiple ports participating in a multipoint conference. This SO> intelligence corresponds to "Call Management" in Figure 2/H.310. The SO> "Call Control" in MC should more appropriately be named "Call SO> Management". This is just a possibility. Another possible implementation is that MC handles all H.245 related control and some of the DSS2 call control management (on top of DSS2) while network interface card handles DSS2 and below layer3 functions. SO> MP handles audio, video and data signals in AAL or higher layers. I thank so too. SO> MR handles ATM cells in the ATM layer? Or it handles signals above SO> ATM (between ATM and AAL)? Is this implementation dependent? HH>According to your and Mr. Okubo's comments, I have put revised Figure 3 HH> as hbmul3v2.ppt in incoming directory of ftp.gctech.co.jp.The PowerPoint HH> file Have two figures. One is single physical network interface HH> version, the other is virtual network interface per peer version like HH> H.231. HH> Which figure is better? HH> Should we need to include "call control" next to Network Interface? Either one is ok with me. But I don't want to exclude the possibility of implementing DSS2 call control in Network Interface. We could either include "call control" next to network Interface or put some text to explain it. 3. H.245 for multipoint and Video mixing in Section 8 I will get back to you tomorrow.

2 1