- sg16-avd - lists.packetizer.com

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

20 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