- sg16-avd - lists.packetizer.com

[H.323 Mobility:] H.323 Annex H status check
by Jaakko Sundquist 08 Sep '00

08 Sep '00

Hi all, I'll try to gather my thoughts of the situation of the H.323 Annex H work after the Portland meeting in this mail. This mail will not handle the issues about the "mandate" of the annex raised by Mr. Roy, but I will take part in that discussion in separate postings. The draft annex produced as the result of the discussions you had in Portland is TD-42 (not TD-42a as I may have stated earlier). I will produce a cleaned up version of that draft early next week (this new version will only have editorial changes compared to TD-42). In the following I list issues that need to be addressed in the future work and discussions. The list is based on the ad hoc group meeting minutes that I received from Mr. Rissanen (I assume that these are made by Mr. Korpi) and on the discussions I have had with Mr. Rissanen. The list is not in any particular order. - Chapter 2, especially concerning Figure 1, should be clarified. I understand that Mr. Aronson will contribute a clarified version of the figure and accompanying text. - Terms, abbreviations and definitions should be re-examined. This work shall be done by the editor with the help of other representatives. Especially the following issues should be kept in mind: - Definition of the H.323 Mobile User should be expanded. - Definition of the Service Provider should be rewritten. - Some representatives were not happy about the current definitions for the Administrative Domains (Home, Visited, etc.). - The terminology of the annex should be aligned with the terminology used in 3G. - Chapter 7 -> Normative text should be produced out of the current text. Editor's note: Currently this chapter is meant to handle the functional REQUIREMENTS for the annex, not normative specifications. Normative text will be produced when these issues are discussed and worked on. Furthermore, I think this chapter could evolve as being the normative text defining e.g. the formats of the identifiers. - New sub-section 7.1.2: "Procedures Required for Provisioning Mobile H.323 Service". If this section is to be added, contributions from the representatives are required (quite fast), otherwise I'm on the opinion that this sub-section should be dropped from the document intended for determination in November. Also, the editor does not have a very clear picture of what issues this sub-section is going to handle, so some clarifications would be nice. - Current draft assumes the GK-routed call model -> Contributions for direct call model are invited. - BEs will be utilized with information flows between different administrative domains. - Some of the information flows in some interfaces should be marked as optional. Also related to this, I think it would be important to decide on which interfaces do we concentrate in the first version of the annex. E.g. reference points K, L and J do not seem to be of the greatest importance, but we could assume that the AuF is always co-located with some other entity and thus leave the interfaces unspecified. I will make a proposal about the this issue in the following week. - The security issues of this annex will be handled in H.235 Annex G. The contents of APC-1930 will be the first "draft" of this annex. The work on H.235 Annex G will, of course, require the help of the mobility group in the form of contributions. I.e., you should still consider the security issues, when making a contribution for the H.323 Annex H, these issues will then be reflected in H.235 Annex G. The editor of H.235 (Mr. Euchner) has kindly offered his help on the security issues. - The cases of a non-mobile User/Terminal calling a mobile User/Terminal (or vice versa) should be addressed in the annex (some of the needed changes are incorporated already in TD-42). - The work on the information flows should continue as fast as possible. Also other protocols than the H.225 Annex G should be examined (e.g. IETF's Mobile IP, etc.). Contributions are invited. As I said this mail tries to capture my understanding of the H.323 Annex H situation after the Portland meeting. If you think I have missed something important or am deadly wrong about something or you have some other comments/questions, please send a response to this mail to the list. Have a nice, relaxing weekend, everyone! ------------------------------------------------ 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

Draft H.245 Rapporteur's TD for H.245V7
by Mike Nilsson 08 Sep '00

08 Sep '00

Please find attached a draft, for review, of the Rapporteur's TD for changes to H.245 relative to the white paper COM-16-120, due for approval in November. <<H245-TD-DraftA.zip>> Best regards Mike Nilsson -------------------- Mike Nilsson Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com

1 0

Re: Support bi-directional channels in annex C fast start
by Roni Even 08 Sep '00

08 Sep '00

Paul, I think that the original text was due to APC-1516 from 9902-Mon submitted by Francois Audet. Any how the current text explains that the originating side is responsible to open the bi-directional VC and signal it in the OLC of the fast connect. The procedure is there in annex C and I do not see what extra text is needed. I think that we only need to allow this mode in the fast connect section. Bellow is the text from annex C - C.3.8.2 If the bidirectional usage is indicated, the receiving endpoint shall send an openLogicalChannelAck (or the openLogicalChannel in the case of Fast Connect) and then it must watch for an ATM VC to be opened by the other endpoint. When ATM VC is completed, it may then use the reverse direction for the media type indicated in the openLogicalChannel command. The endpoint that initiates the openLogicalChannel command is the endpoint that shall open the ATM VC. Thanks Roni Even -----Original Message----- From: Roni Even [mailto:Roni_e@ACCORD.CO.IL] Sent: Tuesday, September 05, 2000 10:33 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Support bi-directional channels in annex C fast start Paul, TD14 from 9902-MON clearly states that the change was done to support fast start. This is the implementer guide for version 2. I am including the text as well as attaching the TD. I would think that the problem was not putting the extra text in the fast start procedure. IF it is not clear I can add some text to annex C Thanks Roni H.323 Annex C - Indication of ATM capabilities in TransportCapability Description: Annex C requires that the indication of ATM be indicated in the Terminal Capability Set, but it implies that it is done in the capability exchange procedures. While this is valid when fast start is not used, it is not when fast start procedures are used since they do not use the capability exchange procedures before setting up the channels. The current wording unfortunately prohibits the use of fast start with Annex C. This contribution proposes that the wording be amended to allow for this indication to be provided in fast start as well. More specifically, the current Annex mandates that the Terminal Capability set be used to indicate the ATM capabilities. If fast start is used, the TransportCapability (where the ATM information is included) is not included. It is however included in the OpenLogicalChannel. Annex C shall be amended the text to reflect this. It shall also be clarified that OpenLogicalChannel is used instead of OpenLogicalChannelAck when fast start is used..This change will be reflected in H.323 v3. C.3.6 Transport Capabilities added to TerminalCapabilityTransportCapability Set For operation of H.323 on AAL5, an addition to the TerminalCapabilityTransportCapability set is made in H.245. This includes transport level capabilities such as support for ATM Transfer Capability (DBR, SBR1, SBR2, SBR3, ABT/DT, ABT/IT, ABR) as defined in Recommendation I.371. Terminals that do not send this new capability parameter shall not make use of the new methods described in this Annex. The TransportCapability information can be sent as part of the Terminal Capability set exchange in the capability exchange phase. It is also included in the OpenLogicalChannel. ... C.3.7.1 ATM address The ATM address for an RTP stream shall be given in the mediaChannel subfield of H2250LogicalChannelParameters of the H.245 OpenLogicalChannelAck message (or the OpenLogicalChannel in the case of fast start). The mediaChannel subfield UnicastAddress or MulticastAddress shall be filled with the 20-octet NSAP-style ATM End System Address. ... C.3.8.2 Bidirectional logical channels If the bidirectional usage is indicated, the receiving endpoint shall send an OpenLogicalChannelAck (or the OpenLogicalChannel in the case of fast start) and then it must watch for an ATM VC to be opened by the other endpoint. When ATM VC is completed, it may then use the reverse direction for the media type indicated in the OpenLogicalChannel command. The endpoint that initiates the OpenLogicalChannel command is the endpoint that shall open the ATM VC. ... -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, September 05, 2000 9:13 AM To: Mailing list for parties associated with ITU-T Study Group 16; Roni_e(a)ACCORD.CO.IL Subject: Re: Support bi-directional channels in annex C fast start Ron, Here are the facts that led to this: 1) In H.323v3 (which is what the Implementers Guide is correcting), it is illegal to use a bi-directional channel with Fast Connect. 2) Section C.3.8.2 and it's parent section C.3.8 were written with H.245 signaling in mind-- there was no thought of Fast Connect here. The procedure is not defined. With H.323v4, Fast Connect was extended to include bi-directional TCP channels, but nothing has been contributed for bi-directional ATM VCs. To simply say it is allowed opens a very large hole. I will quote the authors of the e-mail sent to me that prompted my proposed correction. Since it was sent privately, I will withhold their names. It states: [[ begin quote ]] We believe that there is a conflict between Annex C and H.323 version 3 WRT the Faststart and the method used to open logical channels. Annex C talks about using B-directional OLCs and H.323 V3 claims that only uni- directional OLCs are used during Faststart. ... Annex C in H.323v3 (C.3.8.2) still allows for bidirectional channels in FastStart. It doesn't go into any details, but I can think of two possibilities: - It either opens an exception and allows for the reverse channel to be specified, or - It takes advantage of the fact that the *two* unidirectional channels (forward and reverse) are sent in the same message and somehow associates them as being the same SVC (using the SessionID and/or the mediaChannel value). [[ end quote ]] The author of that e-mail definitely pointed out a whole in the specification. Annex C references bi-directional channels used with Fast Connect, but that is explicitly illegal in V3. I am not at all opposed to re-inserting this text into H.323v4, but we definitely need some clarifying text that explains how this shall be used in Annex C. We cannot assume that the readers understand how it works. Would you be willing to draft text for Annex C to be included in the decided document in November? Best Regards, Paul ----- Original Message ----- From: "Roni Even" <Roni_e(a)ACCORD.CO.IL> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Sunday, September 03, 2000 6:03 AM Subject: Support bi-directional channels in annex C fast start > Hi, > During the Portland meeting I had a concern about the change in H.323 V4 and > Implementers guide described in APC 1875a item 17 that was added by the > editor. This change was also added by the editor to the white draft of H.323 > V4. The editor pointed out that there is a contradiction between the text in > Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use of > bi-directional channels. > I looked at the subject and my suggestion is to keep the text in annex C and > add to the end of the first paragraph of 8.1.7.1 "or one bi-directional > channel logical channel as described in annex C" > Thanks > Roni Even > > ******************************** > Roni Even > VP Product Planning > Accord Networks > Phone: +972-3-9251200 > Fax: +972-3-9211571 > email: roni_e(a)accord.co.il > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

3 2

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - The teleconfe rence
by Jaakko Sundquist 08 Sep '00

08 Sep '00

Hi Paul, Radhika, Markku & al, Personally I think that having the teleconference already on next Monday is too early. I think we should discuss and especially get other people's opinions on this matter on the list before having the teleconference. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

tML - telecommunication Markup Language
by Sakae OKUBO 08 Sep '00

08 Sep '00

Dear SG16 colleagues, Does anyone know about the subject tML which seems to be studied somewhere in ITU? I have received this question only referring to the word "tML - telecommunication Markup Language." Any advice is appreciated. 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

2 2

standard.pictel.com is unavailable
by Patrick Luthi 07 Sep '00

07 Sep '00

This is just a quick note to let you that we have experienced a power supply failure with the standard.pictel.com server. Therefore, it won't be possible to access any files on the LBC, AVC. or video site until approximatively 12.00pm EST. Sorry for the inconvenience ! Patrick Luthi PictureTel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Reddy, Paul K 07 Sep '00

07 Sep '00

Hi Radhika, We as ITU-T SG16 Q13/Q14 group agreed on the H.323 Annex H Terms of Reference, which includes scope of H.323 Annex H. Now, you are proposing a different scope for H.323 Annex H on this reflector. I propose that we plan to have H.323 Mobility Adhoc group conference call discussion on your proposal instead of exchanging emails on this open reflector and come to some consensus on your proposal and then take a contribution to SG16 Q13/Q14 Rapporteurs meeting in Geneva. We as H.323 Mobility Adhoc group choose Mr. Markku Korpi as Chairman of the Adhoc group, I request Mr. Korpi to setup a conference call to discuss your proposal. I am willing to sponsor the Conference Call Bridge, I propose that we can have conference call on Monday September 11, 2000 from 7:00 AM to 9:00 AM (Pacific Standard Time). Please let me know your availability all other members who wants to participate, so that I can make the Conference call bridge arrangements. regards, 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: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Thursday, September 07, 2000 7:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi, Everyone (including all Rapporteurs and WP2 Chairman): Again, it speaks for itself as it has been mentioned earlier. As if, few folks want to create their own charter, push the boundaries of each question so that they are the ONLY people who can decide what need to be addressed in each question no matter what happens to other questions in a given WP or SG or across the whole ITU-T. They are the people who are afraid of seeing the BIG picture of the ITU-T how one question relates to others to achieve a very narrow goal. Some of these people even participated in the joint meeting of SG16 and SG11 to see how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no duplicate work is done elsewhere. Now they are turning their back. Why? Is the norm of the ITU process? It appears that some people do not need address any technical points, as if, they create their own mandate. It may create a good discussion in the upcoming SG16 meeting in the plenary and general session. Again, the proposal for H.323 Annex H has been repeated as follows: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Let us focus on the charter and mandate of Q.13/16: This is item 1 only. Hope that the WP2 Chairman will have time to review the whole thing with true satisfaction in the light of all questions of all SGs within the ITU. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, September 07, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Roy, Radhika R, ALCOO 07 Sep '00

07 Sep '00

Hi, Paul: I am glad to hear from you. I do not think that we can decide among ourselves only (e.g., Ad Hoc H.323 Mobility Group). It is a bigger issue than H.323 Annex H, and few very few people understand what is going on. It affects the life of the entire ITU-T for all questions of all SGs. I am writing contributions probably for the SG16 plenary session to discus all issues related to each question especially that WP 2 handles. Let me provide some insights here: WP2 has questions for H.320, H.324, H.321, H.323, and others. Each question has its own architectural functional entities. For example, H.323 has its terminals, GKs/BEs, GWs, MCUs. etc. Similarly, each question has its own entities. Each application also needs to support mobility, QOS, billing, directory, security/authentication, accounting, etc. Now the challenge is that if the support of mobility, QOS, billing, directory, etc. are protocol specific (e.g., H.323, H.320, H.321), then these extensions belong to the respective protocols. For example, the mobility support of the H.323 terminals, GKs, BEs, and GWs that needs the extension of H.323 protocol (i.e., H.323 base spec,H.225.0 [RAS, Q.931, Annex G], H.245) rightly belongs to Q.13/16. Similar is the case with other applications (e.g., H.3230, H.324, H.321, IMT-2000 applications). Please note carefully: we are now adding some value-added functional entities for mobility like VLF, HLF, AuF, etc. But protocols for these need not to be the application (protocol) specific. That is, the communications between the VLF <-> HLF, HLF <-> AuF, etc. can be independent of any application protocols (e.g., H.323, H.320, H.324, H.321, IMT-2000, etc.). These are common protocols that can be developed independent of H.323, H.320, H.324, or H.321 protocol. In other words, all applications can use the same set of common protocols for VLF, HLF, and AuF communications. In this respect, we made an attempt to use IMT-2000's VLF, HLF, and AuF related protocols for the same purpose (I guess that you had been one of the lead persons for that liaison activity). In otherworlds, we wanted to avoid to develop separate VLF, HLF, and AuF protocols for each application, that is, one VLF/HLF/Auf protocol for H.323, another VLF/HLF/AuF protocol for IMT-2000, and so on. This has been the duplication of the same thing and creating a nightmare for interoperability. More importantly, it defeats the very purpose for developing of "common standards" for which the ITU is so much dedicated. The same example is not only true for mobility, this is also true for QOS, billing, directory, security/authentication, accounting. I have the same problem with the QOS for which Q.13/16 is working in H.323 Annex N. My company (AT&T) is working for almost for all SGs, and is participating in almost in all standard bodies. We are using all of those standards for providing services worldwide. So, the biggest problem that I have is to analyze what all those activities mean when services are provided combining all those standards together. I cannot just sit idle and let things go "wild" creating a mess when it comes to provides services including all applications and services. AT&T's networks not only support fixed H.323, H.320, and other services, we also support mobile applications (wireless, wire-line). It is a very serious matter from my company point of view. Had it been a trivial matter, I would not raise the alarm like this. It has very serious consequences for the entire ITU as well. I cannot just let this go like a loose canon. We need to shape the event for the common benefit of all. It is not that only the Ad Hoc mobility group of H.323 Annex H. It is the future of the 21st century standard works and process that are in stake. My earnest desire is to write contributions to explain all those things so that all delegates throughout the world can analyze what is at stake. New ideas are needed to face the challenge of the future standard works. I am glad that I have the opportunity to work in H.323 Annex H to visualize the greater problems. Now it is time to shape it to meet the future challenge although I know that it is not easy, but let me give a try: To show what belongs to where and how the extensions need to be done, not only for Annex H (mobility), but also for Annex N (QOS), accounting, security, and others. In the end, I like to count on the support of the people like yourself! In the meantime, if you have any suggestions, please send via emails so that all of us of SG16 folks throughout the world can participate in exchanging views. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Reddy, Paul K [mailto:paul.k.reddy@intel.com] Sent: Thursday, September 07, 2000 1:21 PM To: Roy, Radhika R, ALCOO; ITU-SG16(a)mailbag.cps.intel.com Subject: RE: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi Radhika, We as ITU-T SG16 Q13/Q14 group agreed on the H.323 Annex H Terms of Reference, which includes scope of H.323 Annex H. Now, you are proposing a different scope for H.323 Annex H on this reflector. I propose that we plan to have H.323 Mobility Adhoc group conference call discussion on your proposal instead of exchanging emails on this open reflector and come to some consensus on your proposal and then take a contribution to SG16 Q13/Q14 Rapporteurs meeting in Geneva. We as H.323 Mobility Adhoc group choose Mr. Markku Korpi as Chairman of the Adhoc group, I request Mr. Korpi to setup a conference call to discuss your proposal. I am willing to sponsor the Conference Call Bridge, I propose that we can have conference call on Monday September 11, 2000 from 7:00 AM to 9:00 AM (Pacific Standard Time). Please let me know your availability all other members who wants to participate, so that I can make the Conference call bridge arrangements. regards, 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: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Thursday, September 07, 2000 7:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi, Everyone (including all Rapporteurs and WP2 Chairman): Again, it speaks for itself as it has been mentioned earlier. As if, few folks want to create their own charter, push the boundaries of each question so that they are the ONLY people who can decide what need to be addressed in each question no matter what happens to other questions in a given WP or SG or across the whole ITU-T. They are the people who are afraid of seeing the BIG picture of the ITU-T how one question relates to others to achieve a very narrow goal. Some of these people even participated in the joint meeting of SG16 and SG11 to see how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no duplicate work is done elsewhere. Now they are turning their back. Why? Is the norm of the ITU process? It appears that some people do not need address any technical points, as if, they create their own mandate. It may create a good discussion in the upcoming SG16 meeting in the plenary and general session. Again, the proposal for H.323 Annex H has been repeated as follows: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Let us focus on the charter and mandate of Q.13/16: This is item 1 only. Hope that the WP2 Chairman will have time to review the whole thing with true satisfaction in the light of all questions of all SGs within the ITU. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, September 07, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Reddy, Paul K 07 Sep '00

07 Sep '00

Hi Jaakko, Yes, I mean that I agree with all four points you made in this email. regards, Paul -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, September 07, 2000 4:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 So I managed to send this to the list anyways, although I only meant it for Mr. Reddy. Sorry for the quite pointless mails... -Jaakko > -----Original Message----- > From: EXT Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: 07. September 2000 12:11 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > I guess you mean that you agree with all 4 points, not just the fourth > point, right (i.e. I guess there's a typo)? > > -Jaakko > > p.s. I didn't want to send this to the list... > > > -----Original Message----- > > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > > Sent: 07. September 2000 1:41 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Hi Everyone, > > > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > > who made 4 point in this email. > > > > regards, > > Paul Reddy > > Editor of H.246 Annex E.1, Annex E.2 > > > > Paul K. Reddy > > Roaming Services Capability Manager > > Mobile Data Services Area of Opportunity > > Applications and Services Lab > > Intel's Architecture Labs > > Intel Corporation > > Office Phone# +1 (503)-264-9896 > > Mobile Phone# +1 (503)-807-9564 > > Email: paul.k.reddy(a)intel.com > > > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > > Sent: Wednesday, September 06, 2000 9:33 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > > > Again, it is interesting to see how a very narrow view can > > create serious > > problems not only for a simple Annex, but also for the whole > > question, for > > the whole study group, and for all other study groups of the ITU-T. > > > > Time and again, it has been said that let us work within the > > mandate of > > Q.13/16 first and contributions had been made to clarify > those points. > > Everything has been ignored just because few folks want to do > > something > > almost working like a close group without seeing the BIG > > picture of all > > questions of all SGs of the ITU-T. In fact, some joint > > meetings were also > > initiated between SG16 and SG11 to see how the HLFs, VLFs, > > and AuFs related > > protocols are being addressed elsewhere. > > > > Still, they are pushing the same thing just because few folks > > brought some > > contributions. Objections were put via contributions, emails, > > and verbal > > discussions. Even there is not a single editorial note in > the document > > related to those things. > > > > A simple example will reveal the fact. We have discussed that > > there are > > serious problems to use GRQ messages to discover the GKs in mobile > > environment. Many contributions, emails, and verbal > > explanations have been > > provided. If you look into the present H.323 Annex H > > write-up, you will see > > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > > environment. Not a single word has been used even as an > editorial note > > whether some members have raised the questions that there are > > problems need > > to be addressed for GRQs. The way the GRQ section has been > > written, it is a > > generic one and is nothing do with mobility. Rather, it suits > > to be added in > > the base H.323 spec. Many more examples can be given for each > > technical > > issue. > > > > This Annex has NOT done its first important task how to > > extend the H.323 > > signaling messages (RAS, Q.931, Annex G) to solve the > > mobility problems for > > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > > the mandate of > > Q.13/16. Contributions are there, but everything has been ignored. > > > > Rather, Annex H has focused in some areas for which it has > NOT got the > > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > > HLF <-> AuFs, > > etc. These work items are not the charter of Q.13./16 alone. > > These are the > > areas for the joint work with all other questions of all SGs > > that deal with > > mobility. (In another example, even if H.320, H.321, or H.324 > > wants to be > > used by mobile users, they can also use HLFs, VLFs, AuFs, > > etc. Similarly, > > all other mobile applications of all other SGs can also use > > these HLFs, > > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > > the fixed > > user. There is nothing fency about this.) > > > > (More importantly, these additional entities have raised > > serious concerns: > > How does a GK/BE play a role in the overall process while > > "wild" suggestions > > have been made to use the Annex G protocol as well? It has created a > > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > > In fact, some > > members have boasted that they even do not see any need to go > > via GKs or BEs > > anymore so far mobility is concerned. As if, a "bomb " is > > about to be placed > > to break the very foundation of H.323 in the name of > > extending of H.323 for > > mobility.) > > > > More can be written for each technical issue, if needed. If > > one likes to see > > some of those points, please see the contributions that were > > submitted in > > the last Q.13/16 Portland meeting. > > > > Again, I am repeating the proposal for H.323 Annex H: > > > > 1. First, finish the extension of the existing H.323 base > > specs, and H.225.0 > > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > > Terminals, GKs, BEs, and GWs. (see the contributions that are > > being made so > > far). > > > > 2. Second, develop a clear mandate whether the backend > > protocols like VLF > > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > > Q.13/16 only, or > > these protocols need to be worked with other SGs. (see the > > contributions > > that are being made so far). > > > > 3. Third, any protocols that re being used between VLF <-> > > HLF, VLF <-> AuF, > > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > > its extension > > because these are separate protocols and serve completely > > different purposes > > although may useful properties (e.g., hopcount, etc.) of the Annex G > > protocol can be used for these protocols. > > > > It is very important to note that only item 1 is within the > charter of > > Q.13/16 (H.323). All other items need to be addressed in the > > light of all > > mobility works of all questions of all SGs of the ITU by the > > working party > > chair and others. > > > > (My personal view is this: Let H.323 Annex H be scoped for > > item 1 only for > > now as a first step. It will also take a good amount of time > > to finish it. > > People are waiting to see that this happens first. > > > > To include other items, it may take a long time to have > > stable texts working > > with all SGs. This will then constitue the second step.) > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Wednesday, September 06, 2000 8:08 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Mr. Roy & other parties interested in H.323 Annex H, > > > > I found your posting addressing such general level issues > > that I think it is > > better to write a whole new mail as a response instead of > > responding to your > > claims and comments point by point... > > > > First of all you question the mandate of Annex H and its > > relation to the > > H.323 protocols. I find it very odd that you, without any > > real arguments to > > support for it, restrict the H.323 recommendations and thus > > also Annex H to > > handle ONLY the H.323 entities that have been defined prior > > to Annex H. The > > first real work that we got done for Annex H was to identify the > > functionalities that were (are) needed for Mobility > > Management and that were > > missing from H.323. This is how we (in an ad hoc meeting in > > Red Bank, in > > which you yourself was also present) came up with the four new H.323 > > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > > defined NEW H.323 > > entities that were NOT present prior to Annex H. If it is > > illegal for us to > > define new H.323 entities (as you seem to claim), I can't see > > how the Border > > Element ever got defined, since it was not defined prior to > > the H.225 Annex > > G. > > > > Second, you seem to have defined the HLF, VLF and AuF as > > back-end services. > > This is NOT how I see them. I see back-end services as > > services that are NOT > > defined in the H.323 series recommendations, but that may be used by > > gatekeepers. In other words, back-end services or the > > functionalities they > > provide do NOT have any real definition in H.323, nor is it > illegal to > > define new entities to H.323 that provide same kind of > > functionalities that > > could be achieved by using some back-end service. The > > back-end services that > > are used in some implementations of the H.323 system can > > undoubtedly be used > > for similar purposes as the new functional entities of Annex > > H are, but this > > does not make the new entities back-end services. > > Furthermore, the whole > > point (or mandate) of Annex H is to make recommendations that > > allow for > > different manufacturer's equipment to be used in different > > parts of the > > (mobility enhanced) H.323 system and still allow the > > users/terminals to move > > around in the network. Thus, in my opinion, it is one of the > > most important > > issues of Annex H to define, how the HLF, VLF and AuF > > communicate with each > > other. By just stating that they are back-end services we > > would in essence > > NOT define this, since back-end services are NOT defined in H.323. > > > > Third, the protocol(s) that are used between the HLF, VLF and > > AuF are still > > and open issue. The reason, why the H.225 Annex G protocol is > > used in the > > present draft is that it is the only protocol that has been > seriously > > mentioned for this purpose. (Not only by the editor, but in various > > contributions as well, although the editor takes full > > responsibility of the > > current text in the draft.) It has been identified that the > > H.225 Annex H > > protocol already has the functionality for locating a User > > with a certain > > aliasAddress. Really roughly said, this functionality is > "half" of the > > functionality that is needed for Mobility Management, the > > other half being > > the location updating procedures (which are not really > > addressed by the > > protocol yet). This is why the protocol is being considered > > for the Annex H > > usage. However, I would really like to see contributions > > suggesting other > > (preferably existing) protocols as well. Intel's contribution > > APC-1902, was > > the first one of this kind. These contributions should, > however, state > > clearly how the suggested protocols should be used, if there is any > > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > > (I'm not trying > > to refer to the APC-1902 with this comment), but information > > flows for the > > needed Mobility Management procedures should be presented > > (these include at > > least the location updating procedures, call establishment > > procedures, call > > termination procedures and unregistration procedures). > > > > Fourth, the needed enhancements of the RAS, Q.931, etc. > > protocols will be > > provided by finishing the information flows on chapter 10. I > > admit that not > > much of this has yet been done, but on the other hand, at > > least so far I > > have found that there is not too much that has to be done > > with respect to > > these protocols. (There will probably be certain message > > fields that will be > > mandatory for Mobile Terminals that are optional in H.323 > > normally, etc., > > but I don't see a need for too many new message fields or messages.) > > > > Last, but not least, we a really in a hurry, if we want to > > get the Annex H > > determined in November. This is why I suggest that the > > interested parties > > provide the contributions describing the usage of other > > protocols as the > > Mobility Management protocols of Annex H as soon as possible. > > Also it would > > be very nice, if these contributions were made modeling the > > chapter 10 of > > the current draft, so that incorporating them to the annex > > would be as fast > > as possible. > > > > I'm still a bit in the middle of the process of digesting the > > information I > > have gotten about the Annex H work in Portland, but I'll try > > to send a mail > > summarizing (what I think is) our current situation later this week > > (probably on Friday). I will also make a "cleaner" version of > > the TD-42a as > > the "starting point" for our interim work before Geneva (this > > new draft will > > not contain any other than editorial changes compared to TD-42a). > > > > ------------------------------------------------ > > 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 > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Roy, Radhika R, ALCOO 07 Sep '00

07 Sep '00

Hi, Everyone (including all Rapporteurs and WP2 Chairman): Again, it speaks for itself as it has been mentioned earlier. As if, few folks want to create their own charter, push the boundaries of each question so that they are the ONLY people who can decide what need to be addressed in each question no matter what happens to other questions in a given WP or SG or across the whole ITU-T. They are the people who are afraid of seeing the BIG picture of the ITU-T how one question relates to others to achieve a very narrow goal. Some of these people even participated in the joint meeting of SG16 and SG11 to see how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no duplicate work is done elsewhere. Now they are turning their back. Why? Is the norm of the ITU process? It appears that some people do not need address any technical points, as if, they create their own mandate. It may create a good discussion in the upcoming SG16 meeting in the plenary and general session. Again, the proposal for H.323 Annex H has been repeated as follows: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Let us focus on the charter and mandate of Q.13/16: This is item 1 only. Hope that the WP2 Chairman will have time to review the whole thing with true satisfaction in the light of all questions of all SGs within the ITU. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, September 07, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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