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

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