- sg16-avd - lists.packetizer.com

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 29 Oct '99

29 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

Red Bank Meeting Minutes
by Bilalis Zacharias 28 Oct '99

28 Oct '99

Dear Mr. Okubo, In which TDs may I find the general minutes and the minutes of Q14 from Red Bank ITU Meeting? Thank you Best Regards Zacharias Bilalis SIEMENS ICN WN CS EC D12 > Schertlinstr. 8 > D-81359 Muenchen > Germany > Tel: + 49 89 722 28391 Fax: + 49 89 722 61243 Mail to: zacharias.bilalis(a)icn.siemens.de

1 0

Inclusion of H.323 Annex G in the main document
by Gunnar Hellström 28 Oct '99

28 Oct '99

Paul, I assume that it is the intention to collect all annexes in the main H.323 document. Therefore, please include H.323 Annex G in the main H.323 version 4 document. Annex G, as agreed in Red Bank is found in TD-60, in the form it was entered as a white document to TSB for decision in Geneva. (Annex G, Text Conversation and Text SET, should be possible to implement already in a version 3 compliant environment.) Best regards Gunnar ______________________________________________ Gunnar Hellström LM Ericsson Sweden Tel +46 8 556 002 03 Mob: + 46 708 204 288 Txt and video +46 8 556 002 05 Fax +46 8 556 002 06 e-mail: gunnar.hellstrom(a)omnitor.se

1 0

[Robustness] group formed
by Maureen.Stillman＠NOKIA.COM 27 Oct '99

27 Oct '99

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

1 0

Re: Question on Intels new annex-j h.246 proposal..
by Reddy, Paul K 27 Oct '99

27 Oct '99

Dear Christian, You are correct, the scope of the H.246 Annex E has not been defined. I will bring in contributions based on Red Bank, NJ, USA, APC-1671,APC-1672 to the H.323 Mobility Ad Hoc group's interim meeting on November 17, 1999 from 8:00 AM to 10:00 AM (Pacific Standard Time (PST))as one of the agenda item to discuss the scope and need for H.246 Annex E. Thanks, Paul Paul K. Reddy Intel Architecture Labs, Intel Corporations, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA. Phone# +1 (503)-264-9896 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] Sent: Tuesday, October 26, 1999 6:06 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Question on Intels new annex-j h.246 proposal.. G'Day Paul and Edgar, I believe that according to the meeting notes the scope of the annex has yet to be defined. The meeting report called for contributions on this area. What worried me at the meeting was the overlap with the Mobility groups work in this area. They are defining scope and requirements which may or may not lead to this work needing to be done. Anything on H246annexE should be done in light of this. I don't think we should assume GSM or ANSI-42 at this time. Cheers, Christian "Reddy, Paul K" wrote: > > Dear Edgar, > > The new annex is H.246 Annex-E not h.246 Annex-J, which is essentially a > mapping of MAP (mobile application part) of GSM or ANSI-41 or PDC networks > to H.225.0. > > Please refer to Intel's proposals (APC-1671, APC-1672)at ITU-SG16 reflector > (Red Bank Meeting) for more details. > > Edgar Martinez's Question: > Does Intel foresee the same concepts, that is using an adjunct (switched/IP) > Gateway used with the legacy Class-5 switches PSTN? to support H.323 > terminals on Class 5 switches? > > Paul Reddy's Answer: > Intel's focus is on interworking PLMNs with H.323 networks at MAP level. > Other groups already working on the PSTN interworking with H.323 networks, > which may provide the support of H.323 terminals on Class 5 Switches. > > -Paul > > Paul K. Reddy > Intel Architecture Labs, > Intel Corporations, > 2111 NE 25th Avenue, > Hillsboro, OR - 97124, USA. > Phone# +1 (503)-264-9896 > > -----Original Message----- > From: Edgar Martinez [mailto:martinze@cig.mot.com] > Sent: Sunday, October 24, 1999 1:35 PM > To: paul.k.reddy(a)intel.com; ITU-SG16(a)mailbag.cps.intel.com > Subject: Question on Intels new annex-j h.246 proposal.. > Importance: High > > Dear Paul, > > An offical new annex-j for h.246 has been > opened, > proposed by Intel. Which is Interworking > H.323 terminals with the legacy GSM and ANSI > wireless > networks. What this is proposing is a > (MSC+VLR) > Gateway that provides H.323 access to the > Public Land > Mobile Network (PLMN). All the voice and > supplementary services will still be provided > by the Legacy > MSCs. And the data services only by H.323. > APC > 1671 "H.323 with USIM and PLMN Interworking" > and > APC 1672 "User Mobility and Service Mobility > Services for > Wireless Subscribers with H.323 terminals > accessing > MM over IP and PLMN Networks" > > Question: > > Does Intel foresee the same concepts, that is > using an adjunct (swithed/IP) Gateway used > with the legacy Class-5 switches PSTN? to > support > H.323 terminals on Class 5 switches? > > Thanks, > Edgar Martinez

1 0

Re: Mailing list subscription question
by Meyer, Greg W 27 Oct '99

27 Oct '99

All: I can understand that there are probably several (many?) people that have subscribed to this mail list and have misplaced the instructions and information. Below is a copy of the Welcome message that you received when you subscribed, which has some general information to help you. Please save this message for future reference. Thanks. ------------------------------------- Welcome to the ITU-SG16 mail list. Remember - to POST messages to the list send to: itu-sg16(a)mailbag.intel.com - to interact with listserver.... send to: listserv(a)mailbag.intel.com In addition it is requested, that contact information be provided so that the current list of correspondents on this list be provided to ITU-TSB if so requested. [Full Name] [Organization] [contact number] Please send this information in the body of a message to 'greg.w.meyer(a)intel.com', set the "subject" of the mail to "SG16 Contact". Listed below are some hints on interacting with this mailing list: **************************************************************************** * mail reflector: (sent to listserv(a)mailbag.intel.com) Subscribe: BODY of the text set to subscribe itu-sg16 <your email address> <your name> Unsubscribe: signoff itu-sg16 You can get more information on commands by sending a message with the body of the message containing either 'help' or 'info' to: listserv(a)mailbag.intel.com List Digests: If you feel like you lost some list messages or simply want to get a chronological chunk of them, you can do so. Send a message to "listserv(a)mailbag.intel.com" with the body of the message index itu-sg16 This will get you a list of all the digest files. After choosing which files you want, send another message to "listserv(a)mailbag.intel.com" with the body of the message get itu-sg16 [filename] Finally, you may always contact me (via any of the methods in my signature) with any questions. Greg Meyer ************************************************************************* *** 503.264.9506(voice) 503.264.0170(fax) *** *** greg.w.meyer(a)intel.com Intel - Hillsboro, OR. *** ************************************************************************* -----Original Message----- From: Ken Krechmer [mailto:krechmer@CSRSTDS.COM] Sent: Tuesday, October 26, 1999 9:54 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Mailing list subscription question Sorry to splatter this to all, but I have a similar problem to Anders, sans coffee. I too need to learn how to access the list server and make such a change. Ken Krechmer At 12:55 PM 10/26/99 +0200, you wrote: >Due to a computer crash (incompatibility of lap-top and coffee) I have lost the e-mail address for the list server and instructions on how to subscribe/unsubscribe. > >As I am changing e-mail address I need to unscribe the old one and subscribe the new address. > >Could someone who has the list server address and instructions please post them to me. > >Thanks in advance > >Anders > >

1 0

Re: Re (2): IN-IPT interworking issue
by Roy, Radhika R, ALARC 27 Oct '99

27 Oct '99

Hi, Everyone: Going forward, I would also request to keep our eyes open how we can integrate this work (H.246 Annex C defines interworking between ISUP and H.323) with that of the H.323 multimedia intelligent network (M-IN) as envisioned in AT&T's contributions: "APC-1664/1665: H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Network." Best regards, Radhika R. Roy AT&T + 1 732 420 1580 > -----Original Message----- > From: Boaz Michaely [SMTP:Boaz_Michaely@VOCALTEC.COM] > Sent: Wednesday, October 27, 1999 7:44 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re (2): IN-IPT interworking issue > > Dear Mr. Hwang, > > >(1) What does the interfaces 1, 2, 3 4 mean ? Those are different with > that of > > Q.5/SG11(WP4). > > The diagram shown is only what was proposed to SG11. I chose to leave it > for its overall value, since I have not made a better one yet .. > However, these are NOT the official interfaces. > For the actual interfaces defined, please refer to SG11 baseline doc. > you may find the version which was sent as a liasion to SG11 on my WEB > site: > http://people.itu.int/~michaely/docs/APC-1602.zip > > > >(2) What does the H.246C and D and the arrow to D mean ? (In my > understanding, > >H.246 only related with SSF or CCF..) > H.246 Annex C defines interworking between ISUP and H.323 call signalling > (H.225.0) > H.246 Annex D is the one that should deal with interworking on the service > control level. > The arrow in the diagram depicts that initially, information is only > expected to come from the SCP to the GK. > You may want to take a look at the Annex D terms of reference: > http://people.itu.int/~michaely/docs/TD-46.doc > > >(3) Which question and recommendatio number for standardising about the > H.323 > >service control ? > This is studied as part of Q13/16 and Q14/16. SG16 has recently defined a > new annex for H.323 service control using HTTP (H.323 Annex K). This is > currently the only effort in this area. You can find the draft which was > presented last week in > ftp://standard.pictel.com/avc-site/9910_Red/APC-1696.zip > > > Regards, > Boaz > > > > > << File: ATT79300.txt >> << File: ATT79301.txt >>

1 0

Numbering error in report of the Red Bank meeting
by Boaz Michaely 27 Oct '99

27 Oct '99

There seems to be some confusion in the APC numbers regarding Annex K (section 5.4.7): 1) H.323 Annex K draft is APC-1696, and not 1695 as noted 2) Erricson codepoints is APC-1697 and not 1696 as noted. In the text it refers to APC-1695 instead of 1696. Regards, Boaz.

1 0

Re (2): IN-IPT interworking issue
by Boaz Michaely 27 Oct '99

27 Oct '99

Dear Mr. Hwang, >(1) What does the interfaces 1, 2, 3 4 mean ? Those are different with that of > Q.5/SG11(WP4). The diagram shown is only what was proposed to SG11. I chose to leave it for its overall value, since I have not made a better one yet .. However, these are NOT the official interfaces. For the actual interfaces defined, please refer to SG11 baseline doc. you may find the version which was sent as a liasion to SG11 on my WEB site: http://people.itu.int/~michaely/docs/APC-1602.zip >(2) What does the H.246C and D and the arrow to D mean ? (In my understanding, >H.246 only related with SSF or CCF..) H.246 Annex C defines interworking between ISUP and H.323 call signalling (H.225.0) H.246 Annex D is the one that should deal with interworking on the service control level. The arrow in the diagram depicts that initially, information is only expected to come from the SCP to the GK. You may want to take a look at the Annex D terms of reference: http://people.itu.int/~michaely/docs/TD-46.doc >(3) Which question and recommendatio number for standardising about the H.323 >service control ? This is studied as part of Q13/16 and Q14/16. SG16 has recently defined a new annex for H.323 service control using HTTP (H.323 Annex K). This is currently the only effort in this area. You can find the draft which was presented last week in ftp://standard.pictel.com/avc-site/9910_Red/APC-1696.zip Regards, Boaz ???°?µ <jkhwang(a)kt.co.kr> on 27/10/99 05:55:06 AM Please respond to jkhwang(a)kt.co.kr To: Boaz Michaely cc: Subject: Re: IN-IPT interworking issue Thank you for your information. It was very useful to me. Do you have any more description or explanation about the figure you attached (IPT-IN.gif) ? I have some questions about the figure itself :(if the description you may have include the answers, please kindly jsut send it to me) (1) What does the interfaces 1, 2, 3 4 mean ? Those are different with that of Q.5/SG11(WP4). (2) What does the H.246C and D and the arrow to D mean ? (In my understanding, H.246 only related with SSF or CCF..) (3) Which question and recommendatio number for standardising about the H.323 service control ? I will be great appreciated if you answer me. Best regards, Jinkyung Hwang Korea Telcom (Korean delegate for SG11 WP4) Boaz Michaely wrote: > Dear Mr. Mi , > Thank you for following up ! I took the liberty of replying to you over the > reflectors, since many people are interested: > > >.What's the conclusion for your contribution? > TD-97 (Proposal to simplify the functional architecture for IN support of > IP Networks) was the basis for discussion in Manchester and was followed by > an editing session of SG11 baseline. > A liasion including the result of the updated baseline doc. was sent to > SG16 in APC-1602 (attached zip file) > (See attached file: APC-1602.zip) > > >.What kind of service does the interface "H.323 service control" between > > MGC and GK refer to? Is it related to MGC originated IPT IN-call > >(i.e.the call is coming from PSTN side)? > > The diagram you refer to is attached for everyone's convenience > (IPT-IN.gif) > (See attached file: IPT-IN.gif) > > - In some ways this interface resembles the TCAP interface between the SSF > to the SCP: it allows for the IPT service controller (the GK) to instruct > the GW on what to do with an incoming call (which may originate in IP or in > PSTN). As the diagram depicts, the basic support already exists in RAS, > however SG16, as well as some other organizations, have contemplated on > expanding it. This proposed interface has not yet materialized. > > >.To my current understanding, IPT IN-call, for example 800 or 300 > >(calling card) calls, is of value only for H.323 terminal originated > >call. There is no scenario for MGC originated IPT IN-call. Is that the > >case? > > The typical scenario for a terminal originated call is a PC user, while a > GW originated call is for a calling card service. There is no difference > between the two for this purpose: The originating endpoint (whether a > terminal or a GW), requests the GK to provide the routing information > (address, security token, etc) for a destination GW that supports the > requested E.164 number. The problem that "IF1" (see diagram) needs to > solve, is to allow the GK to consult the IN database for making such > decisions. At the same time, it may prove beneficial for the SCP to consult > with the GK in a mirrored scenario (assuming the GK based network has a > meaningful service knowledge). The trivial example, is off course, the GK's > knowledge of the registered endpoints (=logged in users). > > Finally, please note that in parallel to SG11 work, which aims to define IP > interworking for CS-4, SG16 is aiming to define IPT interworking with CS-1, > with zero changes to CS-1, and minimal changes to H.323. > Please take a look at my editor's web page, which contains links to the > relevant documents: > http://people.itu.int/~michaely/ > > Contributions are solicited ! > > Sincerely, > Boaz Michaely. > > mizk <mizk(a)em.njupt.edu.cn> on 23/10/99 10:24:29 PM > > To: Michaely Boaz <boaz(a)vocaltec.com> > cc: (bcc: Boaz Michaely) > Subject: IN-IPT interworking issue > > Dear Mr.Boaz: > > I read your contribution TD97 on IN-IPT interworking at SG11/Q4,5&22 > Manchester meeting. It interests me a lot because I have been actively > involved in IN/Internet interworking issue at SG11/Q5 from the very > beginning. My two contributions were the main sources of TD-GEN11/123 > and its addendum. Since I didn't attend to Manchester meeting, I would > like you to give some information on the following points: > > .What's the conclusion for your contribution? > > .What kind of service does the interface "H.323 service control" between > MGC and GK refer to? Is it related to MGC originated IPT IN-call > (i.e.the call is coming from PSTN side)? > > .To my current understanding, IPT IN-call, for example 800 or 300 > (calling card) calls, is of value only for H.323 terminal originated > call. There is no scenario for MGC originated IPT IN-call. Is that the > case? > > Thank you in advance for your information. > > Best regards, > > Zhengkun Mi > delegate to SG11 > MII(formerly MPT), China > > ------------------------------------------------------------------------ > Name: APC-1602.zip > APC-1602.zip Type: Download File (application/zip) > Encoding: base64 > Description: .ZIP File > > Name: IPT-IN.gif > IPT-IN.gif Type: GIF Image (image/gif) > Encoding: base64 > Description: Compuserve GIF begin:vcard n:;Ms. Jinkyung Hwang tel;fax:+82-2-526-6118 tel;work:+82-2-526-6830 x-mozilla-html:TRUE org:Korea Telecom;Intelligent Network Team version:2.1 email;internet:jkhwang@kt.co.kr title:Technical Staff adr;quoted-printable:;;17 Woomyun-dong Seocho-gu=0D=0ASeoul Korea;;;; x-mozilla-cpt:;-23600 fn:Ms. Jinkyung Hwang end:vcard

1 0

Mailing list subscription question
by Anders Svennevik (ERA) 26 Oct '99

26 Oct '99

Due to a computer crash (incompatibility of lap-top and coffee) I have lost the e-mail address for the list server and instructions on how to subscribe/unsubscribe. As I am changing e-mail address I need to unscribe the old one and subscribe the new address. Could someone who has the list server address and instructions please post them to me. Thanks in advance Anders

2 1

FW: I-D ACTION:draft-ietf-megaco-reqs-08.txt
by Nancy-M Greene 26 Oct '99

26 Oct '99

Below is the URL for the latest Megaco/H.248 requirements draft. The changes between it and reqs-07 (APC-1695) were listed in TD-22 from the Red Bank meeting. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Tuesday, October 26, 1999 12:50 PM > To: 'megaco(a)standards.nortelnetworks.com' > Subject: RE: I-D ACTION:draft-ietf-megaco-reqs-08.txt > > Please find the latest requirements draft (-08) at: > > ftp://standards.nortelnetworks.com/megaco/docs/latest/ > > > (be sure to refresh your browser to see it) > > It is also available from the public Internet-drafts directory (see > below). > > The main differences between reqs-08 and reqs-07 are: > - in 11.2.3, requirements added for trunking/access gateway with fax ports > (based on request from ITU-T SG8): > > 11.2.3 Trunking/Access Gateway with fax ports > a. A trunking/access gateway with fax ports has these requirements:the > protocol must be able to indicate detection of fax media > b. the protocol must be able to specify T.38 for the transport of the > fax. > c. the protocol must be able to specify G.711 encoding for transport of > fax tones across a packet network. > > - in 11.2.9, the word Audio Server was removed, and replaced by the more > general term > Audio Enabled Gateway > - in 11.2.9, digit collection was qualified to be DTMF digit collection > - In Section 11.2.9.1, parts d and e on sequences and sets reworked to > eliminate the implementation specific language > - In Section 11.2.9.1 parts f, g, h removed > - reordering of sections, putting Audio Conferencing at the end > - requirements added to sections 11.2.9.5 and 11.2.9.6 > > Section 11.2.9 is identical to the text I sent out in an email last week. > I received no further comments on it. > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > ---------- > From: Internet-Drafts@IETF.ORG[SMTP:Internet-Drafts@IETF.ORG] > Sent: Monday, October 25, 1999 7:01 AM > To: megaco(a)standards.nortelnetworks.com > Subject: I-D ACTION:draft-ietf-megaco-reqs-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of > the IETF. > > Title : Media Gateway Control Protocol Architecture and > Requirements > Author(s) : N. Greene, M. Ramalho, B. Rosen > Filename : draft-ietf-megaco-reqs-08.txt > Pages : 45 > Date : 22-Oct-99 > > TThis document describes protocol requirements for the Media Gateway > control protocol between a Media Gateway Controller and a Media Gateway. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-08.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-megaco-reqs-08.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-megaco-reqs-08.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > >

1 0

Re: Question on Intels new annex-j h.246 proposal..
by Reddy, Paul K 26 Oct '99

26 Oct '99

Dear Edgar, The new annex is H.246 Annex-E not h.246 Annex-J, which is essentially a mapping of MAP (mobile application part) of GSM or ANSI-41 or PDC networks to H.225.0. Please refer to Intel's proposals (APC-1671, APC-1672)at ITU-SG16 reflector (Red Bank Meeting) for more details. Edgar Martinez's Question: Does Intel foresee the same concepts, that is using an adjunct (switched/IP) Gateway used with the legacy Class-5 switches PSTN? to support H.323 terminals on Class 5 switches? Paul Reddy's Answer: Intel's focus is on interworking PLMNs with H.323 networks at MAP level. Other groups already working on the PSTN interworking with H.323 networks, which may provide the support of H.323 terminals on Class 5 Switches. -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporations, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA. Phone# +1 (503)-264-9896 -----Original Message----- From: Edgar Martinez [mailto:martinze@cig.mot.com] Sent: Sunday, October 24, 1999 1:35 PM To: paul.k.reddy(a)intel.com; ITU-SG16(a)mailbag.cps.intel.com Subject: Question on Intels new annex-j h.246 proposal.. Importance: High Dear Paul, An offical new annex-j for h.246 has been opened, proposed by Intel. Which is Interworking H.323 terminals with the legacy GSM and ANSI wireless networks. What this is proposing is a (MSC+VLR) Gateway that provides H.323 access to the Public Land Mobile Network (PLMN). All the voice and supplementary services will still be provided by the Legacy MSCs. And the data services only by H.323. APC 1671 "H.323 with USIM and PLMN Interworking" and APC 1672 "User Mobility and Service Mobility Services for Wireless Subscribers with H.323 terminals accessing MM over IP and PLMN Networks" Question: Does Intel foresee the same concepts, that is using an adjunct (swithed/IP) Gateway used with the legacy Class-5 switches PSTN? to support H.323 terminals on Class 5 switches? Thanks, Edgar Martinez

2 1

new h.246 annex-e proposal..
by Edgar Martinez [1] 26 Oct '99

26 Oct '99

Dear Paul, Thank you for your reply, and your correction on the new h.246 annex-e. I expect to see some interesting contributions coming your way. You also, pointed out a every informative item. >Other groups already working on the PSTN interworking >with H.323 networks, which may provide the support >of H.323 terminals on Class 5 Switches. Maybe the suggestion on expanding our H.323 interworking to provide PSTN services and H.323 terminal support on a Class-5 switch has merit. But replacing a ISDN terminal or PC with a modem connection to Internet, with a H.323 IP/Class-5 gateway is deja vu. If you have more information could you please share that information with us. Which are the groups working on providing H.323 terminals on Class 5 Switches. Regards, Ed "Reddy, Paul K" wrote: > Dear Edgar, > > The new annex is H.246 Annex-E not h.246 Annex-J, which is essentially a > mapping of MAP (mobile application part) of GSM or ANSI-41 or PDC networks > to H.225.0. So far new parameters in H.225.0 RAS messages, we may also need to to add parameters to H.225.0 (q.931) call control. > > . > Please refer to Intel's proposals (APC-1671, APC-1672)at ITU-SG16 reflector > (Red Bank Meeting) for more details. > > > Edgar Martinez's Question: > Does Intel foresee the same concepts, that is using an adjunct (switched/IP) > Gateway used with the legacy Class-5 switches PSTN? to support H.323 > terminals on Class 5 switches? > > Paul Reddy's Answer: > Intel's focus is on interworking PLMNs with H.323 networks at MAP level. > Other groups already working on the PSTN interworking with H.323 networks, > which may provide the support of H.323 terminals on Class 5 Switches. > > -Paul > > Paul K. Reddy > Intel Architecture Labs, > Intel Corporations, > 2111 NE 25th Avenue, > Hillsboro, OR - 97124, USA. > Phone# +1 (503)-264-9896 > > -----Original Message----- > From: Edgar Martinez [mailto:martinze@cig.mot.com] > Sent: Sunday, October 24, 1999 1:35 PM > To: paul.k.reddy(a)intel.com; ITU-SG16(a)mailbag.cps.intel.com > Subject: Question on Intels new annex-j h.246 proposal.. > Importance: High > > Dear Paul, > > An offical new annex-j for h.246 has been > opened, > proposed by Intel. Which is Interworking > H.323 terminals with the legacy GSM and ANSI > wireless > networks. What this is proposing is a > (MSC+VLR) > Gateway that provides H.323 access to the > Public Land > Mobile Network (PLMN). All the voice and > supplementary services will still be provided > by the Legacy > MSCs. And the data services only by H.323. > APC > 1671 "H.323 with USIM and PLMN Interworking" > and > APC 1672 "User Mobility and Service Mobility > Services for > Wireless Subscribers with H.323 terminals > accessing > MM over IP and PLMN Networks" > > Question: > > Does Intel foresee the same concepts, that is > using an adjunct (swithed/IP) Gateway used > with the legacy Class-5 switches PSTN? to > support > H.323 terminals on Class 5 switches? > > Thanks, > Edgar Martinez -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: IN-IPT interworking issue
by Boaz Michaely 25 Oct '99

25 Oct '99

Dear Mr. Mi , Thank you for following up ! I took the liberty of replying to you over the reflectors, since many people are interested: >.What's the conclusion for your contribution? TD-97 (Proposal to simplify the functional architecture for IN support of IP Networks) was the basis for discussion in Manchester and was followed by an editing session of SG11 baseline. A liasion including the result of the updated baseline doc. was sent to SG16 in APC-1602 (attached zip file) (See attached file: APC-1602.zip) >.What kind of service does the interface "H.323 service control" between > MGC and GK refer to? Is it related to MGC originated IPT IN-call >(i.e.the call is coming from PSTN side)? The diagram you refer to is attached for everyone's convenience (IPT-IN.gif) (See attached file: IPT-IN.gif) - In some ways this interface resembles the TCAP interface between the SSF to the SCP: it allows for the IPT service controller (the GK) to instruct the GW on what to do with an incoming call (which may originate in IP or in PSTN). As the diagram depicts, the basic support already exists in RAS, however SG16, as well as some other organizations, have contemplated on expanding it. This proposed interface has not yet materialized. >.To my current understanding, IPT IN-call, for example 800 or 300 >(calling card) calls, is of value only for H.323 terminal originated >call. There is no scenario for MGC originated IPT IN-call. Is that the >case? The typical scenario for a terminal originated call is a PC user, while a GW originated call is for a calling card service. There is no difference between the two for this purpose: The originating endpoint (whether a terminal or a GW), requests the GK to provide the routing information (address, security token, etc) for a destination GW that supports the requested E.164 number. The problem that "IF1" (see diagram) needs to solve, is to allow the GK to consult the IN database for making such decisions. At the same time, it may prove beneficial for the SCP to consult with the GK in a mirrored scenario (assuming the GK based network has a meaningful service knowledge). The trivial example, is off course, the GK's knowledge of the registered endpoints (=logged in users). Finally, please note that in parallel to SG11 work, which aims to define IP interworking for CS-4, SG16 is aiming to define IPT interworking with CS-1, with zero changes to CS-1, and minimal changes to H.323. Please take a look at my editor's web page, which contains links to the relevant documents: http://people.itu.int/~michaely/ Contributions are solicited ! Sincerely, Boaz Michaely. mizk <mizk(a)em.njupt.edu.cn> on 23/10/99 10:24:29 PM To: Michaely Boaz <boaz(a)vocaltec.com> cc: (bcc: Boaz Michaely) Subject: IN-IPT interworking issue Dear Mr.Boaz: I read your contribution TD97 on IN-IPT interworking at SG11/Q4,5&22 Manchester meeting. It interests me a lot because I have been actively involved in IN/Internet interworking issue at SG11/Q5 from the very beginning. My two contributions were the main sources of TD-GEN11/123 and its addendum. Since I didn't attend to Manchester meeting, I would like you to give some information on the following points: .What's the conclusion for your contribution? .What kind of service does the interface "H.323 service control" between MGC and GK refer to? Is it related to MGC originated IPT IN-call (i.e.the call is coming from PSTN side)? .To my current understanding, IPT IN-call, for example 800 or 300 (calling card) calls, is of value only for H.323 terminal originated call. There is no scenario for MGC originated IPT IN-call. Is that the case? Thank you in advance for your information. Best regards, Zhengkun Mi delegate to SG11 MII(formerly MPT), China

2 1

Text Conversation standards report
by Gunnar Hellstrom 25 Oct '99

25 Oct '99

Gunnar Hellström October 23, 1999 This is a report from accessibility related activities in ITU-T Q11-15/16 meeting in Red Bank, New Jersey 1999-10-18—22. in the Multimedia Systems and Services ITU-T Q11-15/16 meeting in Red Bank, NJ, I have participated with a set of accessibility related contributions from LM Ericsson. The contributions can be downloaded from standard.pictel.com/avc-site/9910_red The meeting was successful and the results point towards major achievements in approved accessibility related standards in February 2000. 1 Total Conversation and Text Telephone Services ---------------------------------------------------- A definition of the Total Conversation Service concept is made in a draft multimedia service description F.MCVS, as an extension of the video phone and video conferencing concept, by adding real time text conversation to it. The F.MCVS draft is numbered APC-1690a. It was reviewed briefly. Q1/16 is supposed to bring it to the next SG16 meeting for determination. The Text Telephone Service is also defined here. 2 Text Conversation in IP Multimedia Conversation and IP Text Telephony ---------------------------------------------------------------------------- Telecommunication is moving into the IP networks. Standardised text conversation must be established there as well as it was in the PSTN as text telephony. One main architecture for IP Multimedia and IP Telephony is ITU-T H.323. Text conversation is added by H.323 Annex G, Text Conversation and Text SET. It also defines a simple IP text telephone with text and voice features. A revised version of the document was reviewed in the meeting, and approved. It was submitted as a white contribution to ITU-T in Geneva for decision in the February 2000 SG16 meeting. The submitted document is found as TD-60. The main change from last version was that RTP transport of text is now default and TCP is a preferred option. Also the H.245 message syntax is more precise. For IP transmission of text conversation, an IETF document “RTP-Text” is in the process of being approved. It was reviewed as APC-1689. After checking that it matched the H.323 Annex G progress, it was slightly modified and entered as a contribution for next IETF meeting in Washington DC on November 10. It can be found in Internet-Drafts as ietf-draft-avt-rtp-text-02.txt For the purpose of defining the text conversation presentation protocol T.140 as the contents of RTP-Text, T140 is applied for MIME registration as a media stream of the text type, both with and without the enclosing RTP payload description. When the MIME registration is complete, it is possible to make IP text telephones and IP Total Conversation devices also according to the IETF SIP architecture without any need for further standardisation. 3 Interworking with text conversation in different networks --------------------------------------------------------------- H.248 is an important gateway architecture in creation. It will enable calls to efficiently cross the border between IP networks and other environments, like PSTN and mobile networks. It is important to define how that is to be done for text conversation and text telephony. H.248 is structured in a core document and packages that add specific application information. The creation of H.248 is a joint project between ITU and IETF and the core document will be published also as an IETF document. Text Conversation and Text Telephone packages are proposed in H.248 Annex I. It was entered as APC-1691 to the meeting, and refined into TD-55a. Time did not allow for a thorough review of it. The Core H.248 was approved to go for decision in February. The general format for package definition has been varying and was still varying in the meeting. It was not regarded stable, and therefore only a few very central packages were approved for decision. The other packages, including Annex I, were recommended for determination in February. The text conversation packages will be entered together with other basic packages in one document to the Megaco working group of IETF for the meeting in Washington DC in November. Mike Kallas of Nortel Networks is the editor of the combined document. 4 Text Conversation in ISDN ------------------------------- The approved modification to H.320 multimedia in ISDN to carry text conversation in a H.224 transport channel was again discussed in Q11/16. The required full new text of H.224 and the modification instructions were submitted to ITU for decision via Tom Geary, rapporteur of Q11/16. 5 Text included in the video stream --------------------------------------- The advanced video coding activity H.26L works on a definition of how small amounts of real time text can be transferred in the video stream. They were adviced to use ISO 10646 UTF-8 coding and some kind of usage indicator, that can indicate the application: text description of video, video subtitling, text conversation, copyright info etc. 6 New question definitions ------------------------------ The proposed new question definitions for 2001-2004 were briefly reviewed. Question H is a broadened Accessibility question. The proposed project Mediacom 2004 also includes Accessibility studies. It is important to find out if the ITU members are prepared to put resources into the proposed work items of the Accessibility activities. The definitions are found in APC-1680, TD-11, and TD-12. 7 Conclusion ---------------- If everything goes smoothly, the Total Conversation concept can be complete by February 18, 2000. That will allow any interested organisation to create standardised interworking telecommunication services including text conversation. If properly exploited, it will be a major achievement for anyone, but especially for deaf, hearing impaired, speech impaired and deafblind people. The gateway definition will only be Determined in February and are expected to be Decided later during 2000 together with other H.248 gateway additions. The standards are backwards compatible with earlier telecom services and enable: · Text telephony in PSTN, IP and mobile networks, including concurrent use of voice and text. · Total conversation in PSTN, ISDN, IP, data conferencing and mobile networks allowing simultaneous real time conversation in video, text and voice.______________________________________ Gunnar Hellström LM Ericsson Sweden Mob +46 708 204 288 Tel +46 8 556 002 03 Fax +46 8 556 002 06 Video +468 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom(a)omnitor.se

1 0

Changes made in Red Bank
by Brian Rosen 25 Oct '99

25 Oct '99

Red Bank was quite a tiring experience. I hope the work we did at 7:00 am after starting at 8:30 am the previous morning is reasonable (I'll look it over!). Here are the changes we made to Megaco/H.248: 1. The compilation from ASN.1 to ABNF is gone. Annex A will have an ASN.1 which will be encoded with, at least as of now, BER. Annex B will have the ABNF we have been working with, which encodes to text. 2. The wording of the document was changed so that SDP SHALL be used when text encoding and Tag/Value (Appendix D) SHALL be used when binary encoding. This removes one option. 3. Some updates were made to references. An ASN.1 reference was added, RFC2234 was made normative. 4. Some terms in the Definitions and References sections were deleted, as they were no longer used in the text. 5. Clarifications were made in 6.1 to state that a Termination SHALL exists in only one Context at a time. 6. In 6.1.1, context properties were renamed to Attributes. Two new attributes were defined: a "Priority" that is applied per context and is used by the MG when it has conflicts with resource assignment, queuing, etc, and "Emergency", as in 911, which is used for preferential handling in the MG. 7. Text was added in 6.2.1 to state that an MGC can only affect terminations and the resources associated with them (when, for example, multiple virtual MGs are implemented). 8. Properties are now defined with read only or read/write capability. 9. The Descriptor Table in 6.4.2 received minor editing updates. 10. The text that described the hierarchy of Media/Stream/Local-Remote... was moved to 7.1.5 11. Text in 6.2.5 was edited to allow packages to be defined on root. 12. Text in section 7 was added to allow the MGC to instruct the MG to take terminations in or out of service. 13. Text in 7.1.2 was clarified to specify that unspecified optional parameters take defined default values. 14. H.225.0 was removed from the list of MUX types. 15. Text was added to section 7 to make EventsDescriptors and SignalsDescriptors be stream specific, and appear inside Stream. 15. Text in 7.1.5 was clarified to make Local/Remote/LocalControl/Signals/Events appearing at the command level imply stream=1, whatever stream=1 was. Although stream=1 defaults to "audio", it can be assigned to whatever the MGC wants to set it to. 16. TerminationBuffered was moved to LocalControl (although there is, at this writing, still some issues around events that affect this change). 17. Wording on what "send only" mode means was clarified. A stream set to mode=sendonly does not pass received media into the context. 18. Signals were defined NOT to be affected by mode. 19. Section 7.1.9 was edited to specify that when using SDP, "s=", "t=" and "o=" lines are optional, and 'v=' is only required between session descriptors. 20. in 7.1.11, wording was changed so that Signals are defined as proceeding from the termination towards the exterior of the Context. When the same Signal is applied to multiple Terminations within one Transaction, the MG should consider using the same resource for these Signals. Signals now have two default parameters - they need not be defined. One is "SignalType" (Brief, Timeout, On/Off). The other is "Duration". Default values must be specified for these parameters when defining a signal. This means that you can define a signal as normally (defaulting to) Brief, with a specific length, but override it in an EventsDescriptor. The Duration is the length of the signal if it is Brief, the length of the timer if it is TimeOut. Duration is not used with On/Off signals. 21. The table in 7.1.12 was edited to fix errors. Text was added to state that Audit with an empty list causes no descriptors to be returned, and is useful in Subtract to inhibit automatic sending of Statistics. 22. The "Port" parameter of ServiceChange was renamed "ServiceChangeAddress" to account for non IP usage. 23. Digit map wording was edited. The Start timer is started at the beginning of every digit map use, but can be overridden. 23. Text in 7.1.17 was edited to show that the ObservedEvents Descriptor is what Notify returns. 24. Changes were made to the text in 7.1 about topology: - A oneway connection must implemented in such a way that the other Terminations in the Context are not aware of the change in topology. - The Topology Descriptor occurs before any command in an action. - TerminationA or TerminationB may be specified as Choose which takes the value the MG assigns to the first underspecified TerminationID in a command within the same Action as the Topology Descriptor. 25. The "media type" wording in 7.2.1 was removed. 26. Text in 7.25 was edited to clarify various kinds of audits. - Specifying an empty Audit Descriptor results in only the TerminationID being returned. This may be useful to get a list of TerminationIDs when used with wildcard - The table was changed. All the audits with wildcard produce audits of terminations (not lists) - an audit of All contexts with the TerminationID set to root produces a list of all active contextIDs. 27. Changes in AuditCapabilities clarify that events and signals return a possible values of all parameters. 28. Text in 7.2.8 was updated to change Port to ServiceChangeAddress and to permit MGC to MG in service/out of service commands. 29. Additional reasons were added to ServiceChangeReason: 910 Media Capability Failure 911 Modem Capability Failure 912 Mux Capability Failure 913 Signal Capability Failure 914 Event Capability Failure 915 State Loss 30. A line was added to 7.3, command error codes which states: Implementations are encouraged to append diagnostic information to the end of the string. 31. Additional error messages were added (see the list) 32. Text was clarified in Section 9 to state that when the protocol is transported over IP, MGCs shall implement both TCP and UDP/ALF, an MG shall implement TCP or UDP/ALF or both. 33. Wording in 11.1 (Virtual MGs) was edited for clarity. I don't think we changed any behavior. 34. The Packages section was largely rewritten. The changes are numerous, but are not radically different from what was there. Here are some highlights: - Packages have versions. Backwards compatibility is REQUIRED for a new version. A non-backwards compatible change is a new package definition (different packageId) - Packages can "Extend" an existing package. The version of the package being extended must be specified. Extensions only ADD properties, events, signals, statistics and/or new values for parameters . No overloading of names is permitted. - Properties and parameters have a declared type - Properties must specify whether they are defined in TerminationState or LocalControl - Properties have read only or read/write characteristics - Events are described with two sections on parameters, one used with EventsDescriptor, one used with Notify. Names can overlap in these two sections - Default values for SignalType and Duration must be specified - All identifiers are defined with a string name and a binary identifier. 35. Annex A was supplied, with a complete ASN.1 description of the protocol 36. Changes were made in Annex B to realize the changes documented above 37. Annex C, which used to be the "compiler" that complied ASN.1 to ABNF was eliminated. In it's place will be the base package definition. 38. Annex D received heavy editing, primarily adding specific values for various fields. 39. Annex E used to be UDP/ALF. It will have both TCP and UDP/ALF (what used to be Annex E and F). The ABNF for TransactionAck is in this Annex. 40. Annex F will now be transport on ATM. Three protocols will be defined: AAL5/ALF, AAL5/SSCOP and AAL5/MTP3b. All are optional. 41. Annex G will become Appendix G, as the examples are informative. Examples will be updated. 42. A new Annex, H, will have transport on SCTP. Transport on SCTP is optional at both MG and MGC (and MGCs must still implement both TCP and UDP/ALF, and MGs must support one or both of these). Brian Rosen John Segers Editors

1 0

List of participants of the Red Bank Meeting - correction
by Sakae OKUBO 25 Oct '99

25 Oct '99

/// Apologies, I have indicated wrong file in the previous message. /// Dear Q11, Q12-14, Q15 experts, I have placed a provisional list of participants of the Red Bank meeting at the following place: ftp://standard.pictel.com/avc-site/Incoming/TD-00a.zip or http://standard.pictel.com/ftp/avc-site/Incoming/TD-00a.zip This is based on your indication whether you would attend the working dinner last Wednesday. The mark is your major interest as I guess. Seemingly there are several who had registered but are not marked here, and several who had not registered but attended the meeting. Please advise me (okubo(a)giti.or.jp) whatever additions/corrections/deletions you may have. (To Mr. Geary and Mr. Sullivan: if you have definitive lists of Q11 and Q15 participants, please send me your files.) 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

List of participants of the Red Bank Meeting
by Sakae OKUBO 25 Oct '99

25 Oct '99

Dear Q11, Q12-14, Q15 experts, I have placed a provisional list of participants of the Red Bank meeting 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 based on your indication whether you would attend the working dinner last Wednesday. The mark is your major interest as I guess. Seemingly there are several who had registered but are not marked here, and several who had not registered but attended the meeting. Please advise me (okubo(a)giti.or.jp) whatever additions/corrections/deletions you may have. (To Mr. Geary and Mr. Sullivan: if you have definitive lists of Q11 and Q15 participants, please send me your files.) 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