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

Call Clearing related
by Sunil Chandra 02 Nov '99

02 Nov '99

Dear Paul, Question 1: This is specifically in regards to call clearing in which both endpoints have pregranted ARQs and the call is GK routed. If the GK closes the call signalling channel, how would the GK know of the call clearing? possibilities : a) both endpoints send a DRQ (even if they have pregranted ARQ). b) GK peeps into the H.245 channel and treats the EndSessionCommand as the request for call clearing. c) (Assuming that GK has requested for IRRs.) On detection of 'n' missed IRRs, the GK decides to poll the endpoint and gets no answer or negative answer, Gk assumes that the call has been released. (But it may have serious implications on billing.) Question 2: If the possibility (a) is TRUE, is the DRQ mandatory for a registered endpoint whether it has sent ARQ or not and whether it sends a subsequent RELEASE COMPLETE or not. Question 3: If the possibilty (c) is TRUE, should it not be mandatory to specify irrFrequencyInCall in either ACF or RCF, if the GK does not want to retain the call signaling channel? With regards, Sunil Chandra Hughes Software System

3 4

White contributions for decision in Feb. 2000
by Sakae OKUBO 31 Oct '99

31 Oct '99

Dear Q12-14/16 experts, JS> The H.248 white draft has been uploaded to the PictureTel ftp archive JS> (ftp://standard.pictel.com/avc-site/Incoming/h248-whitedraft.zip). CG> The H246annexC whitepaper is now stored on the pictel website. CG> The file is whitepaper_H246annexC_clean.zip GH> In the Incoming directory of standard.pictel.com/avc-site , GH> I have uploaded a white document for decision GH> in the meeting in Geneva of SG16 in february. GH> It is H.323 Annex G, Text Conversation and Text SET. All of these files have been moved to /0002_Gen directory. Please see the following index: http://standard.pictel.com/ftp/avc-site/0002_Gen/0002_Gen.html 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

Report of the Red Bank meeting APC-1748a
by Sakae OKUBO 31 Oct '99

31 Oct '99

Dear Q.12-14/16 experts, I have refined the report of the Red Bank meeting APC-1748 and uploaded it to the ftp site: ftp://standard.pictel.com/avc-site/Incoming/APC-1748a.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1748a.zip Changes from the preliminary version are as follows: - Some clarifications from Rapporteurs have been added. - Various editorial refinements have been made. - List of participants has been included - still to be updated - Annexes have been included. Please review this draft and return your comments by the end of Thursday at your local time, so that I can send the final version to the SG16 management. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

H246 Annex C Whitepaper
by Christian Groves 29 Oct '99

29 Oct '99

G'Day all, The H246annexC whitepaper is now stored on the pictel website. The file is whitepaper_H246annexC_clean.zip please disregard the .doc file as it is corrupted. Cheers, Christian

1 0

Re: [Robustness] group formed
by Roy, Radhika R, ALARC 29 Oct '99

29 Oct '99

Hi, Maureen: It is nice to see that a conference call will be held to discuss "robustness mechanisms for H.323." In the last Red Bank meeting, I proposed that the contribution D.225 - "Framework for Reliable H.323 Gatekeeper Architectures" submitted in the last SG16 May'99, Santiago, Chile, should also be included in the terms of reference. I believe that the Rap. of Q.13 has included this in meeting report. However, I could not attend the H.323 robustness group meeting because of conflicting schedules with other H.323 activities. When I noticed that TD-28 did not contain any reference to D.225, I gave an electronic copy of D.225 to one of the participant group members of TD-28. Even then I found that TD-28 had not been modified to include any reference to D.225. As a first step, I would request to look into D.225 and examine how the robustness in H.323 can be also addressed in view of D.225. I will try to attend the conference call on November 16 (Tuesday, 11-12 EST). By the way, is this time of the conf. call in EST of USA? Please clarify this in the subsequent mail. Again, my thanks to you for hosting the conference call. Best Regards, Radhika R. Roy AT&T + 1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Maureen.Stillman(a)NOKIA.COM [SMTP:Maureen.Stillman@NOKIA.COM] > Sent: Wednesday, October 27, 1999 6:07 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Robustness] group formed > > A new group has formed to study the area of providing robustness > mechanisms > for H.323. This group has agreed to work on items together. Attached is > TD-28 written in Red Bank which outlines terms of reference for work to be > undertaken towards providing robustness mechanisms in H.323 and identifies > a > number of potential future work areas. > The group decided to initially work on defining a set of terms for > robustness via the mailing list. Please send contributions of relevant > terms (and optionally their definitions). Please put [Robustness] in the > subject line for those who want to filter e-mail. The group will schedule > occasional conference calls open to any interested parties. Nokia will > host > the first conference call. > > Conference Call Agenda: > > A. terms submitted on the mailing list > B. next steps for the group > > I propose Tuesday, November 16 as the first conference call to be held > from > 11-12 EST. > Please send e-mail to me at: maureen.stillman(a)nokia.com if you wish to > participate or if the time is not good, but you wish to participate. > > The TD-28 document is attached and the Web site is: > > ftp://standard.pictel.com/avc-site/9910_Red/TD-28.zip > > <<TD-28 robust.doc>> > > -- maureen > > Maureen Stillman > Member of Scientific Staff Voice: (607)273-0724 x62 > Nokia IP Telephony Fax: (607)275-3610 > 127 W. State Street Mobile: (607)227-2933 > Ithaca, NY 14850 > e-mail: maureen.stillman(a)nokia.com > www.nokia.com > << File: TD-28 robust.doc >>

1 0

AW: H246annexC Progress Indicators
by Horvath Ernst 29 Oct '99

29 Oct '99

I recommend to keep the two Progress indicators since both public and private ISDNs (QSIG) allow it, so the H.323 gateway should allow it as well. Especially if a private ISDN is involved there are cases where a 2nd progress indicator can occur. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Gesendet am: Donnerstag, 28. Oktober 1999 23:33 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H246annexC Progress Indicators > > G'Day, > > In my H246 annex C draft recommendation section C.6.1.4.2 > I've said that > an Alerting and Progress can contain two progress indicator > elements. I > can't find anything in H.225 or H.323 that forbids this. > > ie. > Progress indicator > Progress indicator information elements possibly present in the access > transport parameter of the Call Progress Message (CPG) are transferred > into the message sent to the calling user. If the calling user is a > H.323 end system it need not interpret this information element. > In addition, progress indicator information elements are > created by the > Interworking function according to the coding of the Call Progress > Message (CPG). Table 15 shows the sending criteria of each value. > Every message sent to the access (ALERTING or PROGRESS) may > contain two > progress indicator information elements. When more than two progress > indicator information elements are to be sent, the supplementary > progress indicator information elements are sent in a > PROGRESS message. > > Are people happy to leave this in or do you only want to see one > supported?? > > Cheers, Christian >

1 0

H.248 white draft uploaded
by John Segers 29 Oct '99

29 Oct '99

All, The H.248 white draft has been uploaded to the PictureTel ftp archive (ftp://standard.pictel.com/avc-site/Incoming/h248-whitedraft.zip). The file is a zipped Word97 document. It was created by deleting all IETF-specific text (RFC header and such) from a master ITU-IETF document. Also, I deleted all macros used in the master document, but Word still thinks the document contains macros. You can disable the macros when opening the document. Regards, John Segers (ITU editor) Brian Rosen (IETF editor) -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

Re: H246annexC Progress Indicators
by Francois Audet 28 Oct '99

28 Oct '99

Why would we need two Progress indicators? > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Thursday, October 28, 1999 2:33 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H246annexC Progress Indicators > > > G'Day, > > In my H246 annex C draft recommendation section C.6.1.4.2 > I've said that > an Alerting and Progress can contain two progress indicator > elements. I > can't find anything in H.225 or H.323 that forbids this. > > ie. > Progress indicator > Progress indicator information elements possibly present in the access > transport parameter of the Call Progress Message (CPG) are transferred > into the message sent to the calling user. If the calling user is a > H.323 end system it need not interpret this information element. > In addition, progress indicator information elements are > created by the > Interworking function according to the coding of the Call Progress > Message (CPG). Table 15 shows the sending criteria of each value. > Every message sent to the access (ALERTING or PROGRESS) may > contain two > progress indicator information elements. When more than two progress > indicator information elements are to be sent, the supplementary > progress indicator information elements are sent in a > PROGRESS message. > > Are people happy to leave this in or do you only want to see one > supported?? > > Cheers, Christian >

1 0

Re: Red Bank Meeting Minutes
by Sakae OKUBO 28 Oct '99

28 Oct '99

Dear Mr. Zacharias, > In which TDs may I find the general minutes and the minutes of Q14 from > Red Bank ITU Meeting? Please find attached my message distributed the other day. It will soon be refine and upload it as APC-1748a. 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 *********************************************************** Date: Mon, 25 Oct 1999 18:55:51 +0900 From: Sakae OKUBO <okubo(a)GITI.OR.JP> Subject: Provisional report of the Red Bank meeting Dear Q12-14/16 experts, Please be advised that a provisional report of the Red Bank meeting is available at the following place: ftp://standard.pictel.com/avc-site/Incoming/APC-1748.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1748.zip This is an integration of TD-53a (general, Q12), TD-54a (Q13) and TD-47c (Q14) with minimum editing. I will later refine it with all Annexes and the list of participants. I hope this will be useful for your debriefing. Please also be advised that all TDs and missing APC documents have been uploaded to /9910_Red directory. 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

H246annexC Progress Indicators
by Christian Groves 28 Oct '99

28 Oct '99

G'Day, In my H246 annex C draft recommendation section C.6.1.4.2 I've said that an Alerting and Progress can contain two progress indicator elements. I can't find anything in H.225 or H.323 that forbids this. ie. Progress indicator Progress indicator information elements possibly present in the access transport parameter of the Call Progress Message (CPG) are transferred into the message sent to the calling user. If the calling user is a H.323 end system it need not interpret this information element. In addition, progress indicator information elements are created by the Interworking function according to the coding of the Call Progress Message (CPG). Table 15 shows the sending criteria of each value. Every message sent to the access (ALERTING or PROGRESS) may contain two progress indicator information elements. When more than two progress indicator information elements are to be sent, the supplementary progress indicator information elements are sent in a PROGRESS message. Are people happy to leave this in or do you only want to see one supported?? Cheers, Christian

1 0