- sg16-avd - lists.packetizer.com

H.323 Annex O
by Roy, Radhika R, ALARC 26 May '00

26 May '00

Mr. M. F. TOSCO Chairman ITU-T SG16 WP2 Dear Mr. TOSCO: We are very much pleased to see that an H.323 Annex O (Internet Protocols and Technologies Complementary to H.323) has been opened in the joint meeting of Q.13/16 and Q.13/16 held in Osaka, Japan on May 15-19, 2000. It is expected that this annex will cover the following topics: 1. H.323-SIP Interworking 2. Inteworking between H.323 and other IETF Protocols (e.g., TRIP, etc.) With respect to item 1 (H.323-SIP Interworking), it has been noted in the meeting report that the IETF is also working to develop an Informational RFC (a standard track RFC is also a possibility) for the SIP-H.323 interworking. The way this work in the IETF is progressing is as follows (I believe that the editor of H.323 Annex O is also fully aware of this work of the IETF): 1. SIP-H.323 Interworking Requirements RFC (Informational): by July-December, 2000 (tentative) 2. SIP-H.323 Interworking RFC (Informational): December 2000 - March 2001 (tentative) The Internet-Drafts and documents that are being provided to develop the RFC are as follows: 1. Agrawal, Roy, and Palawat, "SIP-H.323 Interworking Requirements," draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June 2000. 2. Singh and Schulzrinne, "Interworking Between SIP/SDP and H.323", draft- singh-sip-h323-00.txt, IETF, January 2000. 3. C. Agbah, "SIP and H.323 Signaling Gateway." It is expected that the SIP-H.323 Interworking RFC will be based primarily on the above documents along with suggestions made via emails and conference calls. People could take many those contributions to the ITU-T SG16 for the SIP-H.323 Interworking in the last SG16 February'00 meeting. However, it was found that many companies and institutions that invented the interworking solution could not afford to provide the membership fees of the ITU-T, and some of them even could not afford to make a foreign trip for the standard meeting. But this has not been the case for the IETF where the email has been good enough to work for developing the standard. Therefore, I am proposing the following to harmonize the work of these two organizations so that the complementary standards are created in the ITU-T SG16 and IETF: 1. Let the IETF produce the SIP-H.323 interworking RFC, while we, the ITU-T SG16, will develop the H.323-TRIP and/or other IETF protocols Interworking standard. 2. Should the IETF do not develop the standard track SIP-H.323 RFC, we, the ITU-T SG16, might consider how IETF's SIP-H.323 Interworking (Informational) RFC can be made a formal standard. I hope this suggestion will be acceptable to all of us. Best regards, Radhika R. Roy AT&T Delegation Manager in the ITU-T SG16 (WP1, WP2, & WP3) 200 Laurel Avenue, Middletown, NJ 07748, USA +1 732 420 1580 Tel +1 732 368 1195 Fax rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Versions of Annex E
by Paul E. Jones 26 May '00

26 May '00

Folks, There is a copy of Annex E here: ftp://standard.pictel.com/avc-site/9905_San/Annex_E_rev7.1_changes.zip that appears to be newer, but in fact has no official standing. Mr. Okubo's HTML document describes that it was a proposal to the Santiago meeting, but I've seen a couple of people download it without reading the HTML file, believing that it was the current version. Mr. Okubo, is there something we can do to help prevent people from mistaking this for the latest version? Can we modify the timestamp of the file or rename it? Thanks, Paul

3 3

Re: [H.323 Mobility:] Status check & practical things
by Roy, Radhika R, ALARC 26 May '00

26 May '00

Hi, Jaakko and All: Thanks for clarifications that you will produce a new H.323 Annex H that will be basis for discussions and bringing contributions. It will also be noted that further clarifications have been provided by me related to the MGA message via email in the SG16 reflector because TD-56 does NOT reflect the correct view. It has been observed rightly by you that we could not make sufficient progress in the last teleconferences. If Mr. Korpi makes frequent travels, our progress may be slow. Going forward we have the following to do: 1. We will start email discussions as far as practicable on continuous basis and update the document at a certain interval as appropriate based on the conclusion made via email. Email discussions are very helpful (also legitimate) because people can take their time to think about the matter and provide responses appropriately. Moreover, the email goes to the every member of the SG16. 2. We will also participate in the teleconferences as we will be deciding very soon (Mr. Korpi will help us). If any member has any questions related to the process, please let us know. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Friday, May 26, 2000 7:10 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] Status check & practical things > > Hi folks, > > In this mail, I will try to summarize the current status of H.323 Annex H > work as well as introduce some practical issues concerning our work before > the Portland meeting. > > The Annex H draft outcome from the Osaka meeting can be seen in document > TD-47. Also TD-28, which contains the explanation of the scopes of the > three > mobility related annexes as well as TD-56, which contains the meeting > minutes of the ad hoc group meetings in Osaka are relevant to the Annex H > work. > > I will produce a new draft of Annex H hopefully in a few days, containing > most of the contents of TD-28 in the Introduction chapter (chapter 2). > After > this has been done, we can consider the document as the outcome of the > Osaka > meeting and as a baseline to be addressed in the MTD contributions. > > Work concerning the new service definitions chapter (chapter 5) was also > started in Osaka by Mr. Korpi and Mr. Reddy. The original idea was to > produce a TD in the Osaka meeting, but as time did not allow that, I > anticipate that Mr. Korpi and Mr. Reddy will produce an MTD in the near > future. > > The next issues I would like to focus on, are the rewriting of chapter 7 > concerning the functional requirements as well as continuing the work on > the > information flows and the associated message contents. My feeling is that > chapter 7 in its current form is actually quite poor and frankly quite > confusing and thus needs to be rewritten properly. > > Then to the practical things concerning our work. As Mr. Paul Guram had to > withdraw from the position of the unofficial chairman of the ad hoc group, > it was decided that Mr. Korpi will take that position in the future > meetings > and teleconferences. I think I can speak on behalf of the whole ad hoc > group > when I thank Mr. Guram for doing such an excellent work as the chairman, > you > have been a great help for us. > > Because Mr. Korpi is travelling quite a lot, he did not feel that he > should > be allocating the MTD numbers, so I volunteered to do that. Thus, if (and > hopefully when) you have a contribution for the interim work, please ask > for > an MTD number from me. > > I also propose that we will try to do more work by using the email > reflector > and have teleconferences only a few times before the Portland meeting. > This > is because my feeling is that we really have not had much success in > progressing the work in the teleconferences. We will also agree the dates > for the teleconferences in the reflector. I will also try to produce a new > draft of the Annex H approximately twice per month (my vacation time > excluded) so that you'll have something concrete to argue against or to > support. Anyway, contributions are always very welcome and if the > discussions in the reflector and teleconferences seem to be in agreement, > the contents of the contributions will be added to the draft as soon as > possible. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility:] Status check & practical things
by Jaakko Sundquist 26 May '00

26 May '00

Hi folks, In this mail, I will try to summarize the current status of H.323 Annex H work as well as introduce some practical issues concerning our work before the Portland meeting. The Annex H draft outcome from the Osaka meeting can be seen in document TD-47. Also TD-28, which contains the explanation of the scopes of the three mobility related annexes as well as TD-56, which contains the meeting minutes of the ad hoc group meetings in Osaka are relevant to the Annex H work. I will produce a new draft of Annex H hopefully in a few days, containing most of the contents of TD-28 in the Introduction chapter (chapter 2). After this has been done, we can consider the document as the outcome of the Osaka meeting and as a baseline to be addressed in the MTD contributions. Work concerning the new service definitions chapter (chapter 5) was also started in Osaka by Mr. Korpi and Mr. Reddy. The original idea was to produce a TD in the Osaka meeting, but as time did not allow that, I anticipate that Mr. Korpi and Mr. Reddy will produce an MTD in the near future. The next issues I would like to focus on, are the rewriting of chapter 7 concerning the functional requirements as well as continuing the work on the information flows and the associated message contents. My feeling is that chapter 7 in its current form is actually quite poor and frankly quite confusing and thus needs to be rewritten properly. Then to the practical things concerning our work. As Mr. Paul Guram had to withdraw from the position of the unofficial chairman of the ad hoc group, it was decided that Mr. Korpi will take that position in the future meetings and teleconferences. I think I can speak on behalf of the whole ad hoc group when I thank Mr. Guram for doing such an excellent work as the chairman, you have been a great help for us. Because Mr. Korpi is travelling quite a lot, he did not feel that he should be allocating the MTD numbers, so I volunteered to do that. Thus, if (and hopefully when) you have a contribution for the interim work, please ask for an MTD number from me. I also propose that we will try to do more work by using the email reflector and have teleconferences only a few times before the Portland meeting. This is because my feeling is that we really have not had much success in progressing the work in the teleconferences. We will also agree the dates for the teleconferences in the reflector. I will also try to produce a new draft of the Annex H approximately twice per month (my vacation time excluded) so that you'll have something concrete to argue against or to support. Anyway, contributions are always very welcome and if the discussions in the reflector and teleconferences seem to be in agreement, the contents of the contributions will be added to the draft as soon as possible. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility] clarification
by Laurent Thiebaut 26 May '00

26 May '00

I apologize for having sent on the e_mail exploder an mail in French and I send it again with english version The calling party (and his GK) cannot only know whether a called party is fixed or mobile if this called party belongs to the same country (same numbering plan) and this may even be no more true if Number Portablity applies. A French GK has at my knowledge no clue on the Australian or swedish numbering plan Best regards and again apologizes for the french message Laurent . --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- Laurent Thiebaut <Laurent.Thiebaut(a)ALCATEL.FR> on 26/05/2000 09:53:59 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: Re: [H.323 Mobility] clarification Francois-Xavier je ne connais pas le contexte mais a priori: le calling party (et son GK) ne peuvent savoir que l'appelé est un mobile que si cet appelé apprtient au meme pays. Un GK francais n'a a mon avis aucune idee du plan de num Australien ou suedois J'organise lundi une réunion de debriefing du dernier 3GPP R00. Si ca t'interresse. laurent Francois-Xavier Derome <Francois-Xavier.Derome(a)ALCATEL.FR> on 25/05/2000 13:13:17 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: [H.323 Mobility] clarification hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility] clarification
by Laurent Thiebaut 26 May '00

26 May '00

Francois-Xavier je ne connais pas le contexte mais a priori: le calling party (et son GK) ne peuvent savoir que l'appelé est un mobile que si cet appelé apprtient au meme pays. Un GK francais n'a a mon avis aucune idee du plan de num Australien ou suedois J'organise lundi une réunion de debriefing du dernier 3GPP R00. Si ca t'interresse. laurent Francois-Xavier Derome <Francois-Xavier.Derome(a)ALCATEL.FR> on 25/05/2000 13:13:17 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: [H.323 Mobility] clarification hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Retire in 2-4 Years #1E44
by Diane R 26 May '00

26 May '00

Dear Friend, I know your time is valuable so I will get right to the point. I'm looking for a few key individuals who are absolutely serious about achieving financial independence in the next 2-4 years. Before you are quick to judge, I ask you to put your skepticism aside for just one minute as you read on. It will be time well spent. Are you serious about: Finding a home/internet based business built around a professional product of real value? Creating a multiple SIX FIGURE lifestyle and helping others achieve the same? Do you feel you are: Committed enough to your goals to spend 10-20 hours a week building your own enterprise? Open-minded and teachable to new and innovative ways of doing business? If you answered YES to any of the above questions then we can help you. I am part of an organization whose mission is to foster financial freedom in the lives of those who truly seek to do so. In today's information age, knowledge is truly a valuable commodity. What if you had the exclusive rights to cutting-edge information that could teach average people all about money? How to make it...how to save it.. and most importantly, how to make it grow itself? Our program: Is not MLM or a franchise, but provides associates with all the training, tools, and personal support one needs to be successful. Can you: Simply return a phone call and direct our qualified prospects through an automated information system that truly does all the explaining for you? See yourself profiting 80% per sale and earning no less than $1000 on every purchase? Recognize a real opportunity when you see one and then call to learn more! YOU HAVE NOTHING TO LOSE AND SO MUCH TO GAIN!!! For more details, call our toll free information line 24 hrs a day. 1-800-320-9895 ext 8702 (2 min msg) There is absolutely no obligation. Please serious inquiries only. We look forward to hearing from you. ///////////////////////////////////////////////////////// Please remove at: mailto:ttbel@myrealbox.com?subject=remove ///////////////////////////////////////////////////////// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility] clarification
by Reddy, Paul K 25 May '00

25 May '00

Hi Francois-Xavier, If we assume that calling and called party numbers are UPT (universal personal telecommunication) numbers then according to European numbering plan mobile phone numbers are distinguishable, according to American Number plan there is no distinction between mobile and non-mobile phone number. Based on telecommunication industry trends towards adopting number portability, which means end-user carry the number with him when changing location, service provide in the same location etc. I would suggest that there should not be a distinction of calling or called party number as mobile or non-mobile, let the H.323 Mobile network figure out routing to the end-user who could be mobile or non-mobile user. -Paul Paul K. Reddy Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Thursday, May 25, 2000 4:13 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility] clarification hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility] clarification
by Francois-Xavier Derome 25 May '00

25 May '00

hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A new editor's draft H.323 Annex H
by Roy, Radhika R, ALARC 24 May '00

24 May '00

Hi, Everyone: We appreciate Jaakko for his quick update about the H.323 Annex H draft (TD-47). This draft is providing us a baseline document (yet to be reviewed and agreed by all of us) against which we need to bring contributions suggesting additions and modifications. In the last SG16 Q.11-15/16 Osaka meeting (May 15-19, 2000), we requested the editor to edit document based on the contributions discussed in the meeting. However, we decided that there was not enough time to review the H.323 Annex H (APC-1816) presented by the editor and the editor will produce a draft that would be reviewed later by all of us. Now Jaakko (Editor) has produced the draft (TD-47) for our review and bringing contributions. In the meantime, we will also address our issues via emails to resolve our issues. In fact, we have already started this process. Let us extend our sincere thanks to the editor. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Wednesday, May 24, 2000 2:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > Hi, > > Sorry for the late response, but I wasn't able to read my mails during the > last week. > > The latest version of H.323 Annex H is the TD-47 from the Osaka meeting, > ftp://standard.pictel.com/avc-site/0005_Osa/TD-47.zip . TD-56 includes the > meeting notes from the Ad hoc group meetings in Osaka, but I'm afraid that > no meeting minutes from the last teleconference are available. I can tell > you, though, that in the last teleconference the H323AnnexH_EditorsDraft > was > presented by me and some minor changes were introduced by the group after > which the result of that was produced as the contribution APC-1816 for the > Osaka meeting. > > I hope this helps. > > -Jaakko > > > -----Original Message----- > > From: EXT Tiruthani, Saravanakumar > > [mailto:Saravanakumar.Tiruthani@ICN.SIEMENS.COM] > > Sent: 18. May 2000 1:15 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > > > > Hi, > > > > Do we have the latest version of Annex H after the recent > > tel conference on mobility? Is the editor's draft > > standards.pictel.com/avc-site/Incoming/Mobility-AHG/H323AnnexH > > _EditorsDraft. > > zip > > the latest? Is the minutes available for the teleconference? > > > > Any help will be greatly appreciated. > > Thanks, > > Saravanakumar V. Tiruthani > > Siemens ICN > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > > Sent: Tuesday, May 09, 2000 7:45 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > > > > Hi, Jaakko: > > > > 1. Home/Visited/Target/Visiting Network Address > > > > A quick reply related to your comment about mobile IP. > > > > The mobile IP cannot do the job of H.323 in the application > > layer deals with > > multimedia: audio, video, and/or video. > > > > However, if hooks are already there in the H.323 layer, only > > then mobile IP > > or other methods as appropriate can be used in the lower > > layer (e.g., IP, > > ATM) to do the job. > > > > So, the abstraction of home/visiting/foreign/target network > > address (or > > NPoA) should be there in the H.323 application layer. > > > > I hope that this will clarify the FUNDAMENTAL points of > > mobility management > > that AT&T contributions have explained. > > > > 2. GK Discovery > > > > MGA is another alternative option for the GK discovery. It is > > also very > > efficient when compared to the GRQ mechanisms. MGA is an OPTION, not > > mandatory. > > > > If some people do NOT like this, they may use the GRQ > > messages if they feel > > they are happy with it in the cellular environment. AT&T does > > NOT like to > > use the inefficient GRQ messages. > > > > 3. Centralized/Distributed HLFs > > > > AT&T contributions show message flows for all configurations of HLFs: > > Centralized and Distributed. The contributions show that it > > is the same > > messages that used for all cases. > > > > 4. Location_Req > > > > You are now using NEW messages location_req messages for > > mobility messages. > > AT&T contributions propose the new messages like mobility > > binding updates. > > > > You are requested to look into these contributions instead of > > going too. > > > > 5. Communications between HLFs for inter-domain communications. > > > > AT&T contributions show that this is NOT the scope of H.323. It is a > > protocol between the servers. This is nothing to do with the > > H.323 protocol. > > The same is true for directory server to directory server > > protocol, billing > > server to the billing server protocol, etc. > > > > 6. Other comments > > > > We will discuss in the conf call and Osaka. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > > > > > -----Original Message----- > > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > > > Sent: Tuesday, May 09, 2000 8:10 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [H.323 Mobility:] A new editor's draft > > H.323 Annex H > > > > > > Hi Radhika, > > > > > > Find my comments embedded... > > > > > > > > > > > I hope that you have been enjoying the ice-hockey.... > > > > Section 9.1.1: > > > > > > > > Like home domain, AT&T contribution has provided the detail > > > > description of > > > > home GK/zone from a user point. Accordingly, home network > > > > address (network > > > > point attachment) has been explained. In a given zone, a > > > > mobile may move > > > > from one NpoA to another. Like foreign (or > > > > visited/visiting/target) domain, > > > > AT&T contribution has also explained the foreign (or > > > > visited/visiting/target) network address (or NpoA). The > > > > subsequent emails > > > > have also been sent explaining the things. > > > > > > With regards to the home GK, I am considering that it may be a good > > > concept > > > to introduce for some purposes (mainly because of GK > > discovery issues and > > > the Virtual Home Environment concept), but I have not yet > > introduced in > > > the > > > draft, because I want to have a clearer picture of how the > > concept would > > > be > > > used. I certainly do not like the idea of always having to > > contact the > > > home > > > GK in order to be able to use the H.323 services, nor do I > > like having to > > > contact the HLF through the (home) GK. In other words I am > > willing to add > > > the concept as soon as we have agreed on the semantics of > > it. I still do > > > not > > > see the merit of the home NPoA concept, I do not think it > > adds anything > > > that > > > could not be achieved by using e.g. mobile IP. > > > > > > > > > > > > > > > Hope to discuss the same in tomorrow's conf call. > > > > > > > > I am also curious to know which the team won the ice-hockey..... > > > The Hentunen-Kapanen-Lind attacking line was quite superb... > > > > > > > > > - Jaakko > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A new editor's draft H.323 Annex H
by Jaakko Sundquist 24 May '00

24 May '00

Hi, Sorry for the late response, but I wasn't able to read my mails during the last week. The latest version of H.323 Annex H is the TD-47 from the Osaka meeting, ftp://standard.pictel.com/avc-site/0005_Osa/TD-47.zip . TD-56 includes the meeting notes from the Ad hoc group meetings in Osaka, but I'm afraid that no meeting minutes from the last teleconference are available. I can tell you, though, that in the last teleconference the H323AnnexH_EditorsDraft was presented by me and some minor changes were introduced by the group after which the result of that was produced as the contribution APC-1816 for the Osaka meeting. I hope this helps. -Jaakko > -----Original Message----- > From: EXT Tiruthani, Saravanakumar > [mailto:Saravanakumar.Tiruthani@ICN.SIEMENS.COM] > Sent: 18. May 2000 1:15 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > Hi, > > Do we have the latest version of Annex H after the recent > tel conference on mobility? Is the editor's draft > standards.pictel.com/avc-site/Incoming/Mobility-AHG/H323AnnexH > _EditorsDraft. > zip > the latest? Is the minutes available for the teleconference? > > Any help will be greatly appreciated. > Thanks, > Saravanakumar V. Tiruthani > Siemens ICN > > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Tuesday, May 09, 2000 7:45 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > Hi, Jaakko: > > 1. Home/Visited/Target/Visiting Network Address > > A quick reply related to your comment about mobile IP. > > The mobile IP cannot do the job of H.323 in the application > layer deals with > multimedia: audio, video, and/or video. > > However, if hooks are already there in the H.323 layer, only > then mobile IP > or other methods as appropriate can be used in the lower > layer (e.g., IP, > ATM) to do the job. > > So, the abstraction of home/visiting/foreign/target network > address (or > NPoA) should be there in the H.323 application layer. > > I hope that this will clarify the FUNDAMENTAL points of > mobility management > that AT&T contributions have explained. > > 2. GK Discovery > > MGA is another alternative option for the GK discovery. It is > also very > efficient when compared to the GRQ mechanisms. MGA is an OPTION, not > mandatory. > > If some people do NOT like this, they may use the GRQ > messages if they feel > they are happy with it in the cellular environment. AT&T does > NOT like to > use the inefficient GRQ messages. > > 3. Centralized/Distributed HLFs > > AT&T contributions show message flows for all configurations of HLFs: > Centralized and Distributed. The contributions show that it > is the same > messages that used for all cases. > > 4. Location_Req > > You are now using NEW messages location_req messages for > mobility messages. > AT&T contributions propose the new messages like mobility > binding updates. > > You are requested to look into these contributions instead of > going too. > > 5. Communications between HLFs for inter-domain communications. > > AT&T contributions show that this is NOT the scope of H.323. It is a > protocol between the servers. This is nothing to do with the > H.323 protocol. > The same is true for directory server to directory server > protocol, billing > server to the billing server protocol, etc. > > 6. Other comments > > We will discuss in the conf call and Osaka. > > Best regards, > Radhika R. Roy > AT&T > > > > > -----Original Message----- > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > > Sent: Tuesday, May 09, 2000 8:10 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] A new editor's draft > H.323 Annex H > > > > Hi Radhika, > > > > Find my comments embedded... > > > > > > > > I hope that you have been enjoying the ice-hockey.... > > > Section 9.1.1: > > > > > > Like home domain, AT&T contribution has provided the detail > > > description of > > > home GK/zone from a user point. Accordingly, home network > > > address (network > > > point attachment) has been explained. In a given zone, a > > > mobile may move > > > from one NpoA to another. Like foreign (or > > > visited/visiting/target) domain, > > > AT&T contribution has also explained the foreign (or > > > visited/visiting/target) network address (or NpoA). The > > > subsequent emails > > > have also been sent explaining the things. > > > > With regards to the home GK, I am considering that it may be a good > > concept > > to introduce for some purposes (mainly because of GK > discovery issues and > > the Virtual Home Environment concept), but I have not yet > introduced in > > the > > draft, because I want to have a clearer picture of how the > concept would > > be > > used. I certainly do not like the idea of always having to > contact the > > home > > GK in order to be able to use the H.323 services, nor do I > like having to > > contact the HLF through the (home) GK. In other words I am > willing to add > > the concept as soon as we have agreed on the semantics of > it. I still do > > not > > see the merit of the home NPoA concept, I do not think it > adds anything > > that > > could not be achieved by using e.g. mobile IP. > > > > > > > > > > > Hope to discuss the same in tomorrow's conf call. > > > > > > I am also curious to know which the team won the ice-hockey..... > > The Hentunen-Kapanen-Lind attacking line was quite superb... > > > > > > - Jaakko > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Problems with GRQ/GCF messages for the GK discovery
by Roy, Radhika R, ALARC 23 May '00

23 May '00

Hi, Everyone: Just to remind that we have to address the problems of the GK discovery using the GRQ/GCF messages in the H.323 mobile environments. I like point out that an alternative method was suggested to use the MGA Message. Both GRQ and MGA messages have problems to discover the GK in mobile environment. However, the meeting report (TD-56, TD-22c) shows that, as if, MGA mechanism cannot be used in any H.323 mobile communications environment. It is NOT simply true because H.323 mobile communications environments include: Wire-line (copper, cable, fiber), Wireless LAN (multi-megabits to multi-gigabits), and/or Cellular Wireless (picocell, microcell, macrocell) Networking environments. The problem for the MGA comes up when the bandwidth is very scarce if the MGA message is multicast periodically. For example, in the ellular wireless (macrocell) network, the bandwidth is very scarce. However, this kind of problem is being addressed by sending the "advertise" message in a UNICAST fashion. For example, 3GPP has proposed mobile IP's "agent advertisement message" to be sent in a unicast fashion (instead of multicast) for their cellular wireless (macrocell) networking environment. The price they are paying is to make the mobility solution a quasi-dynamic (instead of truly dynamic). For all other communications environments [e.g., Wire-line (copper, cable, fiber), Wireless LAN (multi-megabits to multi-gigabits), and/or Cellular Wireless (picocell, microcell)] where the bandwidth is NOT scarce, like mobile IP, the MGA mechanism can be used as appropriate. However, the use of the MGA message is an OPTION, not mandatory. (This mechanism will help the mobile H.323 to interwork with the mobile IP should anyone to implement mobile IP in the lower network layer.) So, both GRQ/GCF/GRJ and MGA mechanisms can be used in a complementary manner as appropriate depending on pros and cons of different networking environments. We will discuss this further. In the meantime, please let me know if you have any questions. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Srini Beereddy 23 May '00

23 May '00

Pete, It was specified in section 6.3 of H.450.1 specification - a FACILITY message shall not be sent if a SETUP message previously sent or received has not been answered. Srini, Trillium Digital Systems, Inc. -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Monday, May 22, 2000 12:12 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, Francois, I stand corrected... I thought I read an e-mail a while back that didn't allow you to send facility before a certain stage in the call setup process. After searching I can't find it, and the context might have been different anyway (i.e. Sending SETUP and then SENDING Facility, rather than sending SETUP and then RECEIVING Facility.) I'm happy now! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= ----- Original Message ----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: 21 May 2000 01:21 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Pete, > > This is already covered in H.323, so there is no need to say it again or in > another way. Do you think that the text, below, is deficient in some way? > Seems pretty clear to me. > > 8.2.2/H.323v3: "...intermediate entities shall ensure that H.245 messages > encapsulated in Q.931 messages are forwarded to the other endpoint even if > the Q.931 message in which the H.245 message is encapsulated would be > consumed and not forwarded to the other endpoint. This is accomplished by > transferring the encapsulated H.245 message into a Facility message with the > h323-message-body set to empty." > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > Sent: Saturday, May 20, 2000 12:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I note that TD-26 has been accepted to show how TCS can be conveyed in > parallel with fast start. > > However, the example shows the use of call proceeding for receiving TCS > back > from the remote endpoint. This is not typically an end-to-end message, > and > therefore how the procedure works with the gatekeeper routed model needs > to > be addressed. > > Possible solutions are: > > 1. Refer to the new text that says it is the responsibility of the > gatekeeper to forward any tunnelled message for which none is available > using FACILITY. (There might be some objection from some to using a > facility message this early in the call setup process though.) > > 2. Restrict the tunnelling (and probably the fast start info) to > Alerting, > Connect and Facility, which generally are end-to-end. I believe this is > compatible with the latest procedures for deciding when fast start has > been > ignored. > > Which ever option is chosen, it would also be nice to have a picture for > it > also! > > Pete > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

PictureTel ftp server clogged
by Gary Sullivan 22 May '00

22 May '00

Mr. Luthi and Experts, The PictureTel ftp server appears clogged by too much use. The following three addresses seem to be contributing to much of the traffic. The first one in particular seems to be connecting over and over again. If anyone knows who is responsible for these accesses, please let me and Patrick Luthi (luthip(a)pictel.com) know. 202.106.175.147 ghittino.csp.it 202.98.127.17 The additional addresses listed below are also listed in the server's records as potential contributors. However, these appear less likely to be the source of the problem. dl9181.research.kpn.com magicland gwa3.fe.bosch.de www-cache.fh-giessen.de tide78.microsoft.com (that was me) 202.102.72.29 202.104.121.218 202.109.11.36 210.180.127.2 210.205.14.70 211.35.158.253 211.39.4.158 okigate2.oki.co.jp namesvr.giti.or.jp inet-gw2.toshiba.co.jp proxy.indria.es -Gary S. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

For All #64F6
by Niko Tusta 21 May '00

21 May '00

FREE E-COMMERCE MERCHANT ACCOUNT AND A $200 CASH COUPON!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e-commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:mtpk@writemail.com?subject=INFO-PLEASE to receive our FREE e -mail information package without obligations. ********************************************************* Remove at mailto:yykpm@usa.net?subject=remove ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 21 May '00

21 May '00

We've made it even clearer in v4. Including H.245 and H.225.0 elements. > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Saturday, May 20, 2000 5:21 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Pete, > > This is already covered in H.323, so there is no need to say > it again or in > another way. Do you think that the text, below, is deficient > in some way? > Seems pretty clear to me. > > 8.2.2/H.323v3: "...intermediate entities shall ensure that > H.245 messages > encapsulated in Q.931 messages are forwarded to the other > endpoint even if > the Q.931 message in which the H.245 message is encapsulated would be > consumed and not forwarded to the other endpoint. This is > accomplished by > transferring the encapsulated H.245 message into a Facility > message with the > h323-message-body set to empty." > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > Sent: Saturday, May 20, 2000 12:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I note that TD-26 has been accepted to show how TCS can be conveyed in > parallel with fast start. > > However, the example shows the use of call proceeding for > receiving TCS > back > from the remote endpoint. This is not typically an > end-to-end message, > and > therefore how the procedure works with the gatekeeper routed > model needs > to > be addressed. > > Possible solutions are: > > 1. Refer to the new text that says it is the responsibility of the > gatekeeper to forward any tunnelled message for which none is > available > using FACILITY. (There might be some objection from some to using a > facility message this early in the call setup process though.) > > 2. Restrict the tunnelling (and probably the fast start info) to > Alerting, > Connect and Facility, which generally are end-to-end. I > believe this is > compatible with the latest procedures for deciding when fast start has > been > ignored. > > Which ever option is chosen, it would also be nice to have a > picture for > it > also! > > Pete > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 20 May '00

20 May '00

Another contribution talked about the gatekeeper using FACILITY whenever a CALL PROCEEDING was received but not available because already sent. We also added some missing fields present in CALL PROCEEDING but not in FACILITY to FACILITY. We could add a reference. -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Saturday, May 20, 2000 10:57 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start. However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed. Possible solutions are: 1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.) 2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored. Which ever option is chosen, it would also be nice to have a picture for it also! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Outcome of the Osaka meeting
by Sakae OKUBO 20 May '00

20 May '00

Dear Q12-14/16 experts, The Osaka meeting this week has successfully been finished. All the APC-numbered and temporary documents have been uploaded to the following directory: ftp://standard.pictel.com/avc-site/0005_Osa/ or http://standard.pictel.com/ftp/avc-site/0005_Osa/ Meeting reports are contained in the following TDs: TD-59a General TD-22c Q13 TD-21b Q14 These and other materials will be integrated into APC-1871 as a full report. Please note that 0005_Osa.html gives the index of /0005_Osa directory. I have uploaded only the final version of TD. If it is not the case, please advise me. Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Update of Megaco/H.248 Errata
by Tom-PT Taylor 19 May '00

19 May '00

I have updated the Megaco/H.248 Errata draft (draft-ietf-megaco-errata-02.txt) based on the changes approved over the past week. I believe that IESG approval will be announced when it appears. ITU-T process is complete except for the theoretical possibility of Member (i.e. national delegation) comments up to June 8, and, of course, the final decision on June 15. I will update the protocol document (draft-ietf-megaco-protocol-09.txt) as soon as I receive the final Osaka version from John Segers. I think the "merged" series can now fall by the wayside. Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor(a)nortelnetworks.com

1 0

New Tones Payload Type RFC 2833
by Tom-PT Taylor 19 May '00

19 May '00

For those who haven't heard yet, the tones and signalling payload draft has been published as RFC 2833. I'm sure this will show up as a reference in Megaco/H.248 documentation at some point. Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor(a)nortelnetworks.com

1 0

Re: Draft proposal For ITU Agreement
by Chip Sharp 18 May '00

18 May '00

A couple of comments. I'll snip out parts so it doesn't get too long. At 07:17 AM 5/18/00 -0500, Tom-PT Taylor wrote: >Thanks for your quick read. Comments below. I am copying the SG 16 list >so they can comment too. The original document Chip commented on is Osaka >TD-20. ...snip... > >Notification to ITU-T Study Group 16 shall be by ... > >This seems incomplete. :-) > >I would assume that notification to SG16 will be similar to that for >Megaco (i.e., email to the SG16 chair or to the SG16 mail list). > >Please keep in mind that SG16 has two email lists. An official one >from itu.int that noone seems to use and an unofficial one hosted by >intel.com that is used by everybody. [PTT] From a technical/legal >point of view, SG16 has two choices: the responsible Rapporteur(s) or the >Chair. Definitely not the list. Anyway, it's for them to >say. >Notification to the IETF Megaco Working Group may be by E-mail to >its Chair, >but is preferably by E-mail to the Working Group E-mail >list. Copies of all >notifications to Megaco or from Megaco shall be >sent to the ISOC Vice >President of Standards, in accordance with >procedures agreed between ISOC >and the ITU-T. > >What are these procedures? Please describe the procedures or provide >a reference. [PTT] I think they are described fully in Recommendation >A.5. I believe A.5 only discusses how ITU can reference IETF RFCs. It doesn't define communication procedures that I know of. As long as notification to ISOC VP-Standards is in parallel with working group notification it shouldn't be too much of an impediment. > >Modes Of Cooperation > >This agreement foresees three modes of > cooperation: "Joint Development", >"Formal Comment", and "Informal > Comment". These are defined as follows. ...snip... > >In "Formal Comment" mode, development of the standard is the task of > a >single party to this agreement (the "initiating party") up to the > point of >formal progression of the standard. This point is reached in > the ITU-T when >the document has been determined. It is reached in the > IETF when Working >Group Last Call is announced. At that point, the > document shall be >forwarded to the other organization(s) for > comment. The initiating party >agrees to allow the other > organization(s) sufficient time to complete a >formal process of > comment [people may want this spelled out] before the >initiating party > completes its own process of formal review, and agrees to >take > the comments of the other organization(s) into account in > determining >the final contents of the document concerned. ***The > parties to this >agreement agree that subsequent to determination or > commencement of Working >Group Last Call respectively, the only changes > permitted in the document >will be to provide clarifications and > corrections of errors.*** > >To meet the general case, the technical comments from the non-ITU >group MUST be taken into account before determination to apply the >approval process. The above wording is a little vague on this. In the >second sentence, perhaps you should change "has been determined" to "is >ready to be determined." [PTT] I had in mind that WG Last Call is >begun only when design seems to be stable. Hence the proper sequence is >determination followed by WG Last Call. Neither should happen before all >requirements have been understood and accounted for. One reason for >putting Last Call after determination is to meet a concern on the ITU-T >side that the IETF might never converge if they weren't faced with the >sort of finite time limits the ITU process provides. I'm sorry they feel that way. However, "determination" doesn't happen until the Rapporteur (usually with consensus of the group) determines the text is stable enough to have the approval process applied to it. Similarly, WG Last Call doesn't happen until the WG chair determines the text is stable enough to start the IETF approval process. The main difference is that in ITU "determination" happens at a WP (not Rapporteur's) meeting and in IETF it can happen via email. In either case, the Rapporteur and WG chair have to coordinate their activities. As has occured in several cases, an I-D may go through a couple of cycles of WG Last Call before it goes to IETF Last Call. In my view, WG Last Call should occur before determination. It might be feasible that IETF Last Call happen after determination (i.e., when the white contribution is submitted to ITU). there is still the issue of Resolution 1 recommending only editorial changes (no technical changes other than errata) be made after determination. Theoretically, this would preclude IETF last call from introducing any changes to the document. As has been seen, SG16 isn't too worried with that last concern. In any case, the new ITU approval process will probably apply before this agreement really takes effect. But this agreement should be readily transferable. >A point that came up in discussion here: final decision for "Formal >Comment" documents should be that of the initiating party, rather than >mutual consent. Also, is the IESG/IETF going to agree that only >clarifications and corrections of errors will be allowed in IETF Last >Call and IESG review? The interpretation of "clarifications and >corrections of errors." can deviate widely between groups. [PTT] It >has worked in the current cycle. Anyway, I'm sure they'll put their own >imprint on this before it gets put into play, so they can speak for themselves. It depends on what you mean by the "current cycle". I assume you mean after Geneva. If you can come up with a way to get to now without repeating 10/99 - 2/00 it would be good. ...snip... >If there is going to be any comment or agreement between the groups, >the distribution of the documentation and procedure for providing >comments has to be available to all the IETF. Open availability of >documentation should be a non-negotiable term of the agreement. This >should be made clear for each mode. > >For IETF this is easy. For ITU, this is no different than just sending >an email to the IETF mail list saying that they are working on a >draft Recommendation and if you are an ITU Sector Member you can >comment. [PTT] You're right on this last. It may be that it's not >worth mentioning the "Informal Comment" mode. The key point is not to >require the ITU to make any document which refers to H.248 freely >available -- only those which contribute to the evolution of the protocol >itself. I think it is probably important to keep. Perhaps you are thinking of Notification. In this case, the ITU SG would notify the IETF that an overlapping topic is under discussion and those participants in IETF who are also Sector Members could then choose to particpate in ITU (or not). For example, something like this would have been beneficial in SG13's work on I.ipatm. If SG16 wants comment, they need to provide the documentation (which they do). BTW, SG16 is not a real problem here since they have been progressive enough to open up their documentation to the public. They should be a role model for other ITU SGs in this regard. ...snip... ------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Draft proposal For ITU Agreement
by Tom-PT Taylor 18 May '00

18 May '00

Thanks for your quick read. Comments below. I am copying the SG 16 list so they can comment too. The original document Chip commented on is Osaka TD-20. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Wednesday, May 17, 2000 3:03 PM [PTT] ... > > >Scope of Agreement > > > >This agreement covers work on the evolution of the Megaco/H.248 base > >protocol and on development of Megaco/H.248 packages. With limitations, > it > >also covers work on the application of Recommendation H.248. The initial > >parties to this agreement are ITU-T Study Group 16 and the ISOC Vice > >President of Standards on behalf of the IETF Megaco Working Group. Other > >Study Groups and other IETF Working Groups may join the agreement by > >notifying the existing parties and the ISOC Vice President of Standards. > > The ISOC VP of Standards is listed as an initial party. Does it need to > be > spelled out here? [PTT] I'll cut the last sentence short after "... notifying the existing parties." > Should the Megaco Working Group be listed as an initial party in its own > right? [PTT] Legal/procedural constraints at the ITU-T end make the present form necessary, I think. > Is there a contact for SG16 or do we notify all of SG16? [PTT] I'm waiting to find this out. You'll notice I left this blank later on. > >Other organizations may be accepted into and subscribe to part or all of > >this agreement through consent of the existing parties to the agreement. > > As parties are added to the agreement, do new parties have to notify all > the existing parties as of the time of notification or just SG16 and ISOC > VP of Standards? And how is consent defined (consensus)? [PTT] I'd propose unanimous consent, which also answers your notification question. If groups want to craft side-agreements they're always free to do so. Note these are parties other than ITU-T SGs and IETF WGs. I'll add text to cover notification in the case of these latter. > >Objective > > > >The objective of this procedure is to ensure continued cooperation in and > >coordination of the work of standardization related to media gateway > >control. > > Is this specific to H.248/Megaco or is something larger envisioned? [PTT] It wouldn't hurt to say that it is specific to H.248/Megaco, since that's what the rest of this document talks about. I do hope that some of the principles in the agreement as finally negotiated are useful in other cases. > >Duty Of Notice > > > >Each party undertakes to notify the other (s) whenever it proposes to > begin > >work on > >? a new version of the Megaco/H.248 base protocol; > >? a new Megaco/H.248 package; > >? a new Megaco/H.248 profile; > >? an application of the Megaco/H.248 protocol within the context of other > >standardization work. > > The last item is a little confusing. Could you clarify? Does this mean > that anytime a standards group wants to use H.248 for something it has to > notify all the parties to this agreement, even if it doesn't mean changing > the protocol? [PTT] Yes, that's what I mean. The reason is so everyone is better aware of emerging requirements. > >Notification to ITU-T Study Group 16 shall be by ... > > This seems incomplete. :-) > > I would assume that notification to SG16 will be similar to that for > Megaco > (i.e., email to the SG16 chair or to the SG16 mail list). > > Please keep in mind that SG16 has two email lists. An official one from > itu.int that noone seems to use and an unofficial one hosted by intel.com > that is used by everybody. [PTT] From a technical/legal point of view, SG16 has two choices: the responsible Rapporteur(s) or the Chair. Definitely not the list. Anyway, it's for them to say. > >Notification to the IETF Megaco Working Group may be by E-mail to its > Chair, > >but is preferably by E-mail to the Working Group E-mail list. Copies of > all > >notifications to Megaco or from Megaco shall be sent to the ISOC Vice > >President of Standards, in accordance with procedures agreed between ISOC > >and the ITU-T. > > What are these procedures? Please describe the procedures or provide a > reference. [PTT] I think they are described fully in Recommendation A.5. > >Modes Of Cooperation > > > >This agreement foresees three modes of cooperation: "Joint Development", > >"Formal Comment", and "Informal Comment". These are defined as follows. > > > >In "Joint Development" mode, the parties undertake to form a single team > of > >experts from the inception of the work concerned. The final output will > be > >published both as an ITU-T Recommendation and one or more standards-track > >RFCs. Prior to ITU-T determination, the work shall be advanced both at > >meetings of the respective organizations and, between meetings, through > >discussion on the applicable IETF Working Group E-mail list. Each party > >shall nominate an Editor. Editors shall cooperate to ensure a common > stream > >of documentation into the formal process of each party. [Proposed: to > ease > >the production of IETF documents, documentation shall use the IETF Word > >template until formally submitted to ITU-T determination.] Subsequent to > >ITU-T determination, the process followed shall be the same as described > >below for the "Formal Comment" mode. > > Does this preclude joint development of Information RFCs, Experimental > RFCs, ITU Supplements, Implementor's Guides, etc.? [PTT] Yes, it seems to, but it probably should not. Good catch. I think the essential points are joint participation from the beginning, mutual consent to the results (a point raised in discussion here), and joint publication allowing for the full operation of applicable process in each organization. I'll make the text less specific to reflect this. I may add suggestions for promoting greater continuity in the process -- I wonder if more extensive use of joint ITU-T/IETF design teams and more careful recording and presentation of the rationale for ITU-T design decisions might have helped. > Is there any guideline that the I-D has gone to "WG Last Call" before SG16 > (or other SG) determines that the text is sufficiently mature to apply the > approval procedures (FYI, verbiage taken from Section 8.3.1 of Resolution > 1)? > It seems this was one of the big problems we ran into the first time > around. > > There has got to be something in here about synching up WG last call and > this determination. [PTT] I cover this in the next paragraph (Formal Comment mode), but maybe I have the synchronization point wrong. You argue the point below, so I'll respond there. > >In "Formal Comment" mode, development of the standard is the task of a > >single party to this agreement (the "initiating party") up to the point > of > >formal progression of the standard. This point is reached in the ITU-T > when > >the document has been determined. It is reached in the IETF when Working > >Group Last Call is announced. At that point, the document shall be > >forwarded to the other organization(s) for comment. The initiating party > >agrees to allow the other organization(s) sufficient time to complete a > >formal process of comment [people may want this spelled out] before the > >initiating party completes its own process of formal review, and agrees > to > >take the comments of the other organization(s) into account in > determining > >the final contents of the document concerned. ***The parties to this > >agreement agree that subsequent to determination or commencement of > Working > >Group Last Call respectively, the only changes permitted in the document > >will be to provide clarifications and corrections of errors.*** > > To meet the general case, the technical comments from the non-ITU group > MUST be taken into account before determination to apply the approval > process. The above wording is a little vague on this. In the second > sentence, perhaps you should change "has been determined" to "is ready to > be determined." [PTT] I had in mind that WG Last Call is begun only when design seems to be stable. Hence the proper sequence is determination followed by WG Last Call. Neither should happen before all requirements have been understood and accounted for. One reason for putting Last Call after determination is to meet a concern on the ITU-T side that the IETF might never converge if they weren't faced with the sort of finite time limits the ITU process provides. A point that came up in discussion here: final decision for "Formal Comment" documents should be that of the initiating party, rather than mutual consent. > Also, is the IESG/IETF going to agree that only clarifications and > corrections of errors will be allowed in IETF Last Call and IESG > review? The interpretation of "clarifications and corrections of errors." > can deviate widely between groups. [PTT] It has worked in the current cycle. Anyway, I'm sure they'll put their own imprint on this before it gets put into play, so they can speak for themselves. > >In "Informal Comment" mode, members of other organizations are invited to > >provide comments to the initiating party during the process of > development > >of the document concerned. At the option of the initiating party, the > draft > >document may be freely disclosed to other parties at any given stage, or > >access to the document may be restricted to the membership of the > initiating > >party. > > If there is going to be any comment or agreement between the groups, the > distribution of the documentation and procedure for providing comments has > to be available to all the IETF. > Open availability of documentation should be a non-negotiable term of the > agreement. This should be made clear for each mode. > > For IETF this is easy. For ITU, this is no different than just sending an > email to the IETF mail list saying that they are working on a draft > Recommendation and if you are an ITU Sector Member you can comment. [PTT] You're right on this last. It may be that it's not worth mentioning the "Informal Comment" mode. The key point is not to require the ITU to make any document which refers to H.248 freely available -- only those which contribute to the evolution of the protocol itself. > >Applicability Of Development Modes > >All work on the evolution of the Megaco/H.248 base protocol shall follow > the > >Joint Development mode, with the IETF Megaco Working Group as one of the > >cooperating parties. > > > >Work on Megaco/H.248 packages shall normally follow the Formal Comment > mode. > >Any party has the right to invoke Joint Development mode for specific > >packages. > > Does this mean that if SG16 decides to develop a package, an IETF WG can > invoke Joint Development and force SG16 into Joint Development? [PTT] That's what it means, and vice versa. There was some question about this in discussion here -- Christian Groves wasn't comfortable with the implications for work SG 11 is doing on Q.BICC. Of course, they may find it preferable to negotiate a different agreement with us, but we'll see. Christian's concern was that IETFers might not have the necessary background to understand packages SG 11 was developing, and providing that background in the form of additional documents would cost the ITU revenue. Another point that came up here was that any party should have the right to decline to comment on a specific package (e.g. where they feel it lies beyond their realm of expertise). > Other parties or organizations may want to develop packages that are not > parties to this agreement. I believe the IANA Considerations section > allows this. I assume the above only applies to the parties to the > agreement. [PTT] Absolutely. > >All other Megaco/H.248-related work shall normally follow the Informal > >Comment mode. At the option of the initiating party another mode may be > >followed. > > > >Rights Of Publication > > > >All parties have the right to publish documents produced either through > >Joint Development or Formal Comment mode. > > > >Termination And Modification Of Agreement > > > >Any party may withdraw from this agreement on one year's notice. > >Modifications may be made to this agreement at any time by mutual consent > of > >the agreeing parties. > > Just curious. Why one year? [PTT] Just to clear the pipeline of work in progress. Could spell that out instead of assigning a specific time period, I suppose. > ...snip... > > BTW, it is likely that ITU procedures for approving recommendations is > going to change dramatically by the end of the year. Therefore, a new > agreement will need to be written that applies the ITU's new approval > process. The drafts of the process I've seen includes a Last Call-type > procedure. This may make it a lot easier to synch up the last call > procedures. Hopefully, it will also get rid of the rush to decide a > document in a specific meeting because the next chance won't be for 9 > months. In addition, there is the chance SG16 may not be called SG16 next > year. The ITU is restructuring the study groups and they may be split > apart, recombined and/or renumbered. Old ones may go away and new ones > may > form (e.g., an IMT-2000 specific study group). This should be resolved by > October after the WTSA meeting in September. [PTT] All good points. We'll have to reconsider all this when the dust settles, but in the meantime it gets some ideas on the table. > ------------------------------------------------------------------- > Chip Sharp CTO Consulting Engineering > Cisco Systems > Reality - Love it or Leave it. > http://www.netaid.org > -------------------------------------------------------------------

1 0

Re: [H.323 Mobility:] A new editor's draft H.323 Annex H
by Tiruthani, Saravanakumar 17 May '00

17 May '00

Hi, Do we have the latest version of Annex H after the recent tel conference on mobility? Is the editor's draft standards.pictel.com/avc-site/Incoming/Mobility-AHG/H323AnnexH_EditorsDraft. zip the latest? Is the minutes available for the teleconference? Any help will be greatly appreciated. Thanks, Saravanakumar V. Tiruthani Siemens ICN -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Tuesday, May 09, 2000 7:45 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H Hi, Jaakko: 1. Home/Visited/Target/Visiting Network Address A quick reply related to your comment about mobile IP. The mobile IP cannot do the job of H.323 in the application layer deals with multimedia: audio, video, and/or video. However, if hooks are already there in the H.323 layer, only then mobile IP or other methods as appropriate can be used in the lower layer (e.g., IP, ATM) to do the job. So, the abstraction of home/visiting/foreign/target network address (or NPoA) should be there in the H.323 application layer. I hope that this will clarify the FUNDAMENTAL points of mobility management that AT&T contributions have explained. 2. GK Discovery MGA is another alternative option for the GK discovery. It is also very efficient when compared to the GRQ mechanisms. MGA is an OPTION, not mandatory. If some people do NOT like this, they may use the GRQ messages if they feel they are happy with it in the cellular environment. AT&T does NOT like to use the inefficient GRQ messages. 3. Centralized/Distributed HLFs AT&T contributions show message flows for all configurations of HLFs: Centralized and Distributed. The contributions show that it is the same messages that used for all cases. 4. Location_Req You are now using NEW messages location_req messages for mobility messages. AT&T contributions propose the new messages like mobility binding updates. You are requested to look into these contributions instead of going too. 5. Communications between HLFs for inter-domain communications. AT&T contributions show that this is NOT the scope of H.323. It is a protocol between the servers. This is nothing to do with the H.323 protocol. The same is true for directory server to directory server protocol, billing server to the billing server protocol, etc. 6. Other comments We will discuss in the conf call and Osaka. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Tuesday, May 09, 2000 8:10 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > Hi Radhika, > > Find my comments embedded... > > > > > I hope that you have been enjoying the ice-hockey.... > > Section 9.1.1: > > > > Like home domain, AT&T contribution has provided the detail > > description of > > home GK/zone from a user point. Accordingly, home network > > address (network > > point attachment) has been explained. In a given zone, a > > mobile may move > > from one NpoA to another. Like foreign (or > > visited/visiting/target) domain, > > AT&T contribution has also explained the foreign (or > > visited/visiting/target) network address (or NpoA). The > > subsequent emails > > have also been sent explaining the things. > > With regards to the home GK, I am considering that it may be a good > concept > to introduce for some purposes (mainly because of GK discovery issues and > the Virtual Home Environment concept), but I have not yet introduced in > the > draft, because I want to have a clearer picture of how the concept would > be > used. I certainly do not like the idea of always having to contact the > home > GK in order to be able to use the H.323 services, nor do I like having to > contact the HLF through the (home) GK. In other words I am willing to add > the concept as soon as we have agreed on the semantics of it. I still do > not > see the merit of the home NPoA concept, I do not think it adds anything > that > could not be achieved by using e.g. mobile IP. > > > > > > > Hope to discuss the same in tomorrow's conf call. > > > > I am also curious to know which the team won the ice-hockey..... > The Hentunen-Kapanen-Lind attacking line was quite superb... > > > - Jaakko > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Your Choice #43EB
by Jo Gregory 16 May '00

16 May '00

WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS ! INTERNET (Auction Vendors & Online Mall Stores Too!) STOREFRONT OR MAIL ORDER MERCHANTS WE SPECIALIZE IN APPROVING YOU! APPLY TODAY AND START FOR JUST $9.95! FREE APPLICATION!! FREE PROGRAMMING!! DON'T LOSE ANOTHER SALE! APPLY TO ACCEPT CREDIT CARDS AND CALL (888) 264-9272 DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!! ************************************************************ If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:gmn2@popmail.com?subject=remove ************************************************************ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Internet Marketing Secret! -bdebpnenjnm
by keeper44＠020.CO.UK 16 May '00

16 May '00

1 0