- sg16-avd - lists.packetizer.com

[H.323 Mobility:] Trouble getting into the teleconference
by Jaakko Sundquist 09 May '00

09 May '00

Hi folks, I do not seem to be able to connect to the teleconference (the line is busy). I'll keep trying, but if I am not successful, I' afraid we'll need to postpone my introduction of the new draft to Osaka, sorry. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

09 May '00

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

1 0

UPload APC-1853 and APC-1854
by Christian Groves 09 May '00

09 May '00

Hello All, APC- 1853 Editor (Alf Heidermark LM ERicsson) H.248 draft determined Annex H APC- 1854 Editor (Alf Heidermark LM ERicsson) H.248 draft determined Annex I Has been placed in: ftp://standard.pictel.com/avc-site/Incoming/ Regards, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:] A new editor's draft H.323 Annex H
by Roy, Radhika R, ALARC 09 May '00

09 May '00

Hi, Jaakko: Thanks for providing your thoughts known to all of us. I appreciate this because you taken a step to make a progress assuming that this will help us. I have no problems to work in this fashion if everyone agrees with this process. The only thing that I have to do is to bring contributions with reference to the draft that you have provided. I can say clearly where things to be added, modified, and/or deleted. You can also include texts from the contributions showing agreement (and differences with editor's notes) in the Rapporteur contribution. I completely agree with you that we need to make a rapid progress. If everyone agrees with the process that you have taken, I will bring contributions accordingly so that you can clearly see where things (what text, figures, etc.) need to be added, modified, and/or deleted. Best regards, Radhika R. Roy > -----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.... > > Yes, it was most enjoyable. Finland won 7-4. > > > > > I understand that the editor's draft is just a contribution > > for the upcoming > > tomorrow's conf call, not a draft for the Osaka meeting. > > It is not yet the draft for the Osaka meeting. However, since the meeting > is > already in next week, I will not make too many changes to it. > > > > > I do not know which parts of your draft have been taken from the > > contributions that had been discussed and agreed. I have seen > > no reference > > to it. Or, have you made some educative guess from your side? > > If you remember, we had a discussion about the way we will continue the > Annex H work in the last teleconference. Since we have achieved almost > nothing since the Geneva meeting I thought it would be a better idea if I > produced a draft of the annex including my thoughts (of course taking into > consideration the discussions that we have had) of how it should look like > and you as well as anyone else could make your contributions against that. > This idea also seemed to gain some support. > > > > > Let me explain. > > > > You have two roles to play: First as an editor to reflect > > what has been > > agreed upon by the members based on contributions. Second, an > > individual > > from Nokia to agree or disagree. > > > > An editor must provide the draft that will reflect what has > > been agreed by > > the members based on contributions. However, as an individual > > from a company > > an editor may have differences. These differences can be > > reflected in the > > draft in two ways: 1. As an editor's note and 2. Even as an > > individual from > > Nokia (assuming that subsequent contributions will clarify this). > > Quote from the first page of the draft: "NOTE: None of the changes, that > are made to this document after the previous acceptance of changes (i.e. > all > changes that are highlighted when the MS-Word highlight changes option is > on), are accepted by the members of the mobility ad hoc group." > > As I said above, I'm hoping that this kind of working method of me > producing > the draft annex and all of you making your contributions against that will > make our progress faster. Unfortunately I was not able to bring the draft > forward any earlier, which of course makes it harder (if not impossible) > for > you to make your contributions for the Osaka meeting against the draft > directly. However, I do think that we can work in Osaka in a more > systematic > manner and perhaps even have some results. > > > > > Section 4: > > > > I guess that you have one contribution showing these figures > > 2 through 7 > > (there is no reference - I see a similarity- am I correct?). We never > > discussed this contribution in any conference call. How come > > that you have > > included all figures from your contribution that has not been > > discussed and > > agreed? > > These figures are the same as in my contribution MTD-011b, which was not > discussed in the teleconference because of lack of time. MTD-011b was > based > on the earlier contribution MTD-011 and the discussions we had about it in > the first teleconference after the Geneva meeting. I thought that it is > very > important that we clearly explain what is meant by a scenario and what > kind > of scenarios we might consider in the H.323 mobility work. > > > > > In fact, we discussed about your earlier contribution where > > we have agreed > > that we will start from all H.323 scenarios: First, > > intra-zone, inter-zone, > > and inter-domain scenarios. > > This is exactly why the figures are there. They explain what is really > meant > by the all-H.323 scenario (and of course the other scenarios as well). I > have also added a statement to the scope stating that we will initately > focus on the all-H.323 scdenario. Furthermore, the concept of the scenario > was (nor is) supposed to include any reference to Intra-zone, Inter-zone > or > Inter-domain (this is actually the reason, why I thought that the MTD-011 > needed to be re-written, it lead to a confusion about the meaning of > scenario), so I see that it really is necessary to clearly explain the > scenario concept in order to avoid this kind of misunderstandings. > > > > > For inter-working between H.323 and non-mobile scenarios, > > there are many > > possible scenarios and we may not address in this document > > for now for the > > sake of time. So far I re-collect, this has been the > > decision. Section 4 > > does NOT reflect this. > > Again, see the scope. > > > > > Section 7: > > > > I like to see that there should be an editor's note that > > "Figure 8 will be > > revisited based on the extensions that will be made in H.323 > > to support > > mobility. This is just a place holder to provide references > > for the on-going > > discussion." > > > > Of course the architecture figure can and probably will be refined as we > continue the work. (I believe that at least Intel is going to propose some > changes to it in Osaka). I do not think we need to put in any comments > saying that. Furthermore, could you explain what you mean by saying that > the > figure is just a placeholder for the ongoing discussions? I regard this > kind > of an architectural figure as an integral part of this kind of > specification. > > > Section 8: > > > > Which contributions your are referring here that we have > > agreed? I would > > request that people MUST bring contributions to define > > virtual home and > > service execution environment before an editor put any texts in it. > > I do not think that chapter 8 is even nearly complete, but since we have > had > quite a lot of discussion going on around the concept of Virtual Home > Environment (especially with Ericsson), I wanted to add something that > would > explain the difference between these two distinct concepts. I would really > appreciate, if someone would bring in contributions to refine this > chapter. > > > > > Did you submit an outline of your draft to be approved? > > No, for the reasons stated in the beginning of this message. Furthermore, > I > do not think that I have changed very much of the outline that has been > agreed. You can, of course, suggest a different kind of outline. > > > > > Section 9: > > > > Which contributions you are referring to? > > I have tried to gather the issues that I think we have more or less agreed > on in our discussions with regards to this chapter. I have made some new > names for certain concepts and for some parts I have made my own > suggestions > (mainly the information flows). I have not taken any of the contributions > as > a basis for this chapter, because we haven't agreed on very large parts of > any contribution. > > > > > Did you have any outlines for this section that need to be approved? > > > > My understanding has been that we agreed that the mobility > > management will > > include: A. Intra-Zone, B. Inter-Zone, and C. Inter-Domain. > > > > In each case it will have the following: > > > > 1. GK discovery > > 2. Registration > > 3. Location update > > 4. Call establishment > > I think this is exactly what I have done. The problem with the terms > Intra-zone, Inter-zone and Inter-domain is that I do not know what you > exactly mean by them. In the previous H.323 standards the division has > been > easy, because there is always a call involved and the division is made > based > on the relative locations of the participants of the call. In Annex H, > however, it is often needed to contact e.g. different domains even though > the call might actually be an Intra-zone call. I have introduced the ideas > of Location updating procedures and related to that the > Intra/Inter-zone/domain location changes as well as Call related MM > procedures that can be divided into Intra(Inter-zone/domain call cases to > clarify the categorization. > > > > AT&T and Alctel contributions are there and these contributions were > > discussed. The outlines should follow these procedures to > > follow the text > > consistently. > > These contributions were discussed, but I do not remember having an > agreement on almost anything in those contributions. The only thing we > almost agreed on in the AT&T contribution was the figure illustrating the > zone, its relation to the funtional entities and the NPoAs. This figure > has > been used as a "model" for the figures 10 - 13 in the draft annex. > > > 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. > > > > > I would expect, like visiting/visited domain, the concept of > > visiting/visited/target network address should be taken as a > > part of it. > > Without this, the mobility management will almost be > > MEANINGLESS because the > > trivial mobility management keeping some addresses in a database like > > VLFs/HLFs do not help the service providers and the mobility > > management > > through re-registration is already there in H.323, and no new > > standard work > > is needed for extending the so called VLFs and HLFs databases. > > I do not think it is meaningless to define an organized way of keeping > track > of the Users' location in the network. That in my opinion is NOT present > in > H.323. It does not mean that these mobility management features have to be > overly complicated, in fact I would prefer as simple (or trivial) solution > as possible. If and when we get this trivial issue settled we can perhaps > add more features to the Mobility Management. > > > > > Figure 11 shows that the inter-zone mobility management is > > maintained using > > the single HLF. Which contributions you are referring to? Did > > we agree on > > this concept? AT&T contribution shows that it is an > > unacceptable proposition > > if we consider that there is a single HLF (as the protocol is > > "hard-wired" > > for a centralized HLF configuration)? > > As I have stated in some earlier emails to the list, I do think that it is > necessary to regard that only one logical HLF holds the location > information > of a particular User. This database could be distributed in some way > unknown > to the H.323 system and we could even define a method for enabling the HLF > to have multiple network addresses (i.e. multiple "locations" in the > network > where it could be accessed), but I do not think that we should try to > define > a way to distribute the HLF database in the network (and that I think is > what you are suggesting by having multple alternative HLFs for a User). > > > > > Figure 12 shows that a single VLF is communicating with > > multiple HLFs. Which > > contributions do you refer to? > > I have always assumed this as a possibility, but you are right, it has not > been exactly stated in any contribution before, so I guess I am > contributing > it now. It is of course possible to have the VLF only be in contact with > one > HLF, if that is what we want. > > > > > Figure 13 shows that HLFs are communicating between the > > domains? Did you not > > see that we are NOT in sink with this approach because the > > questions have > > been raised that this approach might be "breaking" the H.323 > > standard? AT&T > > has also provided contributions regarding this (I guess that Alcatel's > > contribution also agrees with AT&T's contribution in this regard). > > When the Hinter reference point was added to the architecture figure, I > thought that we made the assumption that Inter-domain communications > between > the VLFs and HLFs are possible. If we want to remove that possibility, I'm > more than happy to agree. In fact I remember even making a contribution > (sometime in the autumn) suggesting that BEs are used in the Inter-domain > communications. > > > > > Are you "pushing" for some something (or am I missing > > something)? If it is > > so, please bring contributions, we will be pleased to discuss. > > As stated earlier, I'm just trying to make some progress. > > > > > Section 9.2: > > > > Use of GRQ messages for the GK discovery is NOT new in H.323. > > It is already > > a standard. A reference to the existing H.323 standard is enough. > > Section 9.2 does include more than just saying that GRQs are used. > > > > > However, the fundamental question has been that GRQ messages are NOT > > efficient for the GK discovery in the cellular environment. AT&T > > contributions have provided an alternative solution using the > > MGA message > > for the GK discovery. > > > > So, the use of GRQ messages are INEFFICIENT for the GK > > discovery. So, it is > > NOT acceptable in the highly mobile environment. > > Actually, personally I quite like your idea of the MGA message (or > something > similar), but it seemed to create quite a lot of opposition, when we > discussed it over the phone (I think there were claims that in fact the > MGA > would NOT be a more efficient method), so I did not add it. This is > something that I think we need to discuss in Osaka. > > > > > Section 9.5: > > > > Again, I like to know which contributions you are referring to? > > > > Figures 15, 16, 17, 18, and 19 show that, as if, the protocol is > > "hard-wired" for the centralized HLF configuration. AT&T > > contributions do > > not assume this. We have NOT accepted this notion. > > I admit that these information flows are based on my own thoughts and I am > not assuming that the whole group agrees to those without any discussion. > So, you should make your contributions against the ones I have added > (which > you have already done, but we haven't yet had enough time to discuss > them). > > > > > So, the basic question: Why do you want to include the > > material where there > > are no contributions and no agreement? > > As said, to fasten our work... > > > > > There are fundamental flows the way you have shown all > > information flows. > > Let me cite few examples: > > > > You have shown that LRQ messages are sent from the GK to the > > VLF and/or HLF. > > Why do you think so? Did you not see that we have NOT even > > agreed with this > > in the last conference call and via emails? AT&T > > contributions have used NEW > > mobility management messages. > > I really did not assume that the "Location_req" imaginary message would be > confused with the LRQ, but apparently I need to make that more clear. In > other words the Location_req is not the same as LRQ. > > > Considering the comments provided above, all texts provided in your > > contribution need a COMPLETE re-writing of the document. > > I'm sure there is a lot to be done, but at least now we have some clearer > ground for our discussions in Osaka. > > > > > I understand the difficulty with the job as an editor. I > > appreciate your > > efforts. However, there are some norms that an editor has to follow: > > Contributions and Agreement made. If editors have their > > opinions, they can > > bring separate company contributions (NOT as Rapporteur > > contributions). > > I think I understand what the job of the editor is. I'm just trying to > direct our work so that in some reasonable amount of time we might > actually > achieve something. If you ask me, we (as the unofficial mobility ad hoc > group) have not agreed on ANYTHING since the Geneva that could be put to > the > annex. I also have received some feedback from other members of the group > suggesting this kind of a work method and I thought it might be a better > way > to go forward than the way we have previously worked. > > > > > 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

1 0

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

09 May '00

Hi Radhika, Find my comments embedded... > > I hope that you have been enjoying the ice-hockey.... Yes, it was most enjoyable. Finland won 7-4. > > I understand that the editor's draft is just a contribution > for the upcoming > tomorrow's conf call, not a draft for the Osaka meeting. It is not yet the draft for the Osaka meeting. However, since the meeting is already in next week, I will not make too many changes to it. > > I do not know which parts of your draft have been taken from the > contributions that had been discussed and agreed. I have seen > no reference > to it. Or, have you made some educative guess from your side? If you remember, we had a discussion about the way we will continue the Annex H work in the last teleconference. Since we have achieved almost nothing since the Geneva meeting I thought it would be a better idea if I produced a draft of the annex including my thoughts (of course taking into consideration the discussions that we have had) of how it should look like and you as well as anyone else could make your contributions against that. This idea also seemed to gain some support. > > Let me explain. > > You have two roles to play: First as an editor to reflect > what has been > agreed upon by the members based on contributions. Second, an > individual > from Nokia to agree or disagree. > > An editor must provide the draft that will reflect what has > been agreed by > the members based on contributions. However, as an individual > from a company > an editor may have differences. These differences can be > reflected in the > draft in two ways: 1. As an editor's note and 2. Even as an > individual from > Nokia (assuming that subsequent contributions will clarify this). Quote from the first page of the draft: "NOTE: None of the changes, that are made to this document after the previous acceptance of changes (i.e. all changes that are highlighted when the MS-Word highlight changes option is on), are accepted by the members of the mobility ad hoc group." As I said above, I'm hoping that this kind of working method of me producing the draft annex and all of you making your contributions against that will make our progress faster. Unfortunately I was not able to bring the draft forward any earlier, which of course makes it harder (if not impossible) for you to make your contributions for the Osaka meeting against the draft directly. However, I do think that we can work in Osaka in a more systematic manner and perhaps even have some results. > > Section 4: > > I guess that you have one contribution showing these figures > 2 through 7 > (there is no reference - I see a similarity- am I correct?). We never > discussed this contribution in any conference call. How come > that you have > included all figures from your contribution that has not been > discussed and > agreed? These figures are the same as in my contribution MTD-011b, which was not discussed in the teleconference because of lack of time. MTD-011b was based on the earlier contribution MTD-011 and the discussions we had about it in the first teleconference after the Geneva meeting. I thought that it is very important that we clearly explain what is meant by a scenario and what kind of scenarios we might consider in the H.323 mobility work. > > In fact, we discussed about your earlier contribution where > we have agreed > that we will start from all H.323 scenarios: First, > intra-zone, inter-zone, > and inter-domain scenarios. This is exactly why the figures are there. They explain what is really meant by the all-H.323 scenario (and of course the other scenarios as well). I have also added a statement to the scope stating that we will initately focus on the all-H.323 scdenario. Furthermore, the concept of the scenario was (nor is) supposed to include any reference to Intra-zone, Inter-zone or Inter-domain (this is actually the reason, why I thought that the MTD-011 needed to be re-written, it lead to a confusion about the meaning of scenario), so I see that it really is necessary to clearly explain the scenario concept in order to avoid this kind of misunderstandings. > > For inter-working between H.323 and non-mobile scenarios, > there are many > possible scenarios and we may not address in this document > for now for the > sake of time. So far I re-collect, this has been the > decision. Section 4 > does NOT reflect this. Again, see the scope. > > Section 7: > > I like to see that there should be an editor's note that > "Figure 8 will be > revisited based on the extensions that will be made in H.323 > to support > mobility. This is just a place holder to provide references > for the on-going > discussion." > Of course the architecture figure can and probably will be refined as we continue the work. (I believe that at least Intel is going to propose some changes to it in Osaka). I do not think we need to put in any comments saying that. Furthermore, could you explain what you mean by saying that the figure is just a placeholder for the ongoing discussions? I regard this kind of an architectural figure as an integral part of this kind of specification. > Section 8: > > Which contributions your are referring here that we have > agreed? I would > request that people MUST bring contributions to define > virtual home and > service execution environment before an editor put any texts in it. I do not think that chapter 8 is even nearly complete, but since we have had quite a lot of discussion going on around the concept of Virtual Home Environment (especially with Ericsson), I wanted to add something that would explain the difference between these two distinct concepts. I would really appreciate, if someone would bring in contributions to refine this chapter. > > Did you submit an outline of your draft to be approved? No, for the reasons stated in the beginning of this message. Furthermore, I do not think that I have changed very much of the outline that has been agreed. You can, of course, suggest a different kind of outline. > > Section 9: > > Which contributions you are referring to? I have tried to gather the issues that I think we have more or less agreed on in our discussions with regards to this chapter. I have made some new names for certain concepts and for some parts I have made my own suggestions (mainly the information flows). I have not taken any of the contributions as a basis for this chapter, because we haven't agreed on very large parts of any contribution. > > Did you have any outlines for this section that need to be approved? > > My understanding has been that we agreed that the mobility > management will > include: A. Intra-Zone, B. Inter-Zone, and C. Inter-Domain. > > In each case it will have the following: > > 1. GK discovery > 2. Registration > 3. Location update > 4. Call establishment I think this is exactly what I have done. The problem with the terms Intra-zone, Inter-zone and Inter-domain is that I do not know what you exactly mean by them. In the previous H.323 standards the division has been easy, because there is always a call involved and the division is made based on the relative locations of the participants of the call. In Annex H, however, it is often needed to contact e.g. different domains even though the call might actually be an Intra-zone call. I have introduced the ideas of Location updating procedures and related to that the Intra/Inter-zone/domain location changes as well as Call related MM procedures that can be divided into Intra(Inter-zone/domain call cases to clarify the categorization. > > AT&T and Alctel contributions are there and these contributions were > discussed. The outlines should follow these procedures to > follow the text > consistently. These contributions were discussed, but I do not remember having an agreement on almost anything in those contributions. The only thing we almost agreed on in the AT&T contribution was the figure illustrating the zone, its relation to the funtional entities and the NPoAs. This figure has been used as a "model" for the figures 10 - 13 in the draft annex. > 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. > > I would expect, like visiting/visited domain, the concept of > visiting/visited/target network address should be taken as a > part of it. > Without this, the mobility management will almost be > MEANINGLESS because the > trivial mobility management keeping some addresses in a database like > VLFs/HLFs do not help the service providers and the mobility > management > through re-registration is already there in H.323, and no new > standard work > is needed for extending the so called VLFs and HLFs databases. I do not think it is meaningless to define an organized way of keeping track of the Users' location in the network. That in my opinion is NOT present in H.323. It does not mean that these mobility management features have to be overly complicated, in fact I would prefer as simple (or trivial) solution as possible. If and when we get this trivial issue settled we can perhaps add more features to the Mobility Management. > > Figure 11 shows that the inter-zone mobility management is > maintained using > the single HLF. Which contributions you are referring to? Did > we agree on > this concept? AT&T contribution shows that it is an > unacceptable proposition > if we consider that there is a single HLF (as the protocol is > "hard-wired" > for a centralized HLF configuration)? As I have stated in some earlier emails to the list, I do think that it is necessary to regard that only one logical HLF holds the location information of a particular User. This database could be distributed in some way unknown to the H.323 system and we could even define a method for enabling the HLF to have multiple network addresses (i.e. multiple "locations" in the network where it could be accessed), but I do not think that we should try to define a way to distribute the HLF database in the network (and that I think is what you are suggesting by having multple alternative HLFs for a User). > > Figure 12 shows that a single VLF is communicating with > multiple HLFs. Which > contributions do you refer to? I have always assumed this as a possibility, but you are right, it has not been exactly stated in any contribution before, so I guess I am contributing it now. It is of course possible to have the VLF only be in contact with one HLF, if that is what we want. > > Figure 13 shows that HLFs are communicating between the > domains? Did you not > see that we are NOT in sink with this approach because the > questions have > been raised that this approach might be "breaking" the H.323 > standard? AT&T > has also provided contributions regarding this (I guess that Alcatel's > contribution also agrees with AT&T's contribution in this regard). When the Hinter reference point was added to the architecture figure, I thought that we made the assumption that Inter-domain communications between the VLFs and HLFs are possible. If we want to remove that possibility, I'm more than happy to agree. In fact I remember even making a contribution (sometime in the autumn) suggesting that BEs are used in the Inter-domain communications. > > Are you "pushing" for some something (or am I missing > something)? If it is > so, please bring contributions, we will be pleased to discuss. As stated earlier, I'm just trying to make some progress. > > Section 9.2: > > Use of GRQ messages for the GK discovery is NOT new in H.323. > It is already > a standard. A reference to the existing H.323 standard is enough. Section 9.2 does include more than just saying that GRQs are used. > > However, the fundamental question has been that GRQ messages are NOT > efficient for the GK discovery in the cellular environment. AT&T > contributions have provided an alternative solution using the > MGA message > for the GK discovery. > > So, the use of GRQ messages are INEFFICIENT for the GK > discovery. So, it is > NOT acceptable in the highly mobile environment. Actually, personally I quite like your idea of the MGA message (or something similar), but it seemed to create quite a lot of opposition, when we discussed it over the phone (I think there were claims that in fact the MGA would NOT be a more efficient method), so I did not add it. This is something that I think we need to discuss in Osaka. > > Section 9.5: > > Again, I like to know which contributions you are referring to? > > Figures 15, 16, 17, 18, and 19 show that, as if, the protocol is > "hard-wired" for the centralized HLF configuration. AT&T > contributions do > not assume this. We have NOT accepted this notion. I admit that these information flows are based on my own thoughts and I am not assuming that the whole group agrees to those without any discussion. So, you should make your contributions against the ones I have added (which you have already done, but we haven't yet had enough time to discuss them). > > So, the basic question: Why do you want to include the > material where there > are no contributions and no agreement? As said, to fasten our work... > > There are fundamental flows the way you have shown all > information flows. > Let me cite few examples: > > You have shown that LRQ messages are sent from the GK to the > VLF and/or HLF. > Why do you think so? Did you not see that we have NOT even > agreed with this > in the last conference call and via emails? AT&T > contributions have used NEW > mobility management messages. I really did not assume that the "Location_req" imaginary message would be confused with the LRQ, but apparently I need to make that more clear. In other words the Location_req is not the same as LRQ. > Considering the comments provided above, all texts provided in your > contribution need a COMPLETE re-writing of the document. I'm sure there is a lot to be done, but at least now we have some clearer ground for our discussions in Osaka. > > I understand the difficulty with the job as an editor. I > appreciate your > efforts. However, there are some norms that an editor has to follow: > Contributions and Agreement made. If editors have their > opinions, they can > bring separate company contributions (NOT as Rapporteur > contributions). I think I understand what the job of the editor is. I'm just trying to direct our work so that in some reasonable amount of time we might actually achieve something. If you ask me, we (as the unofficial mobility ad hoc group) have not agreed on ANYTHING since the Geneva that could be put to the annex. I also have received some feedback from other members of the group suggesting this kind of a work method and I thought it might be a better way to go forward than the way we have previously worked. > > 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

1 0

APC1800-APC1801 finally found!
by /Q11, Q12, Q13 09 May '00

09 May '00

I am sorry for the e-mail i sent. I finally found it after a page reload.. Ameneh Zahir ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: List of registered contributions- Looking for APC1800-APC1801
by /Q11, Q12, Q13 09 May '00

09 May '00

Hello, I am looking for Tom's Taylor new version of H248 which should be APC 1800 and APC1801. I can't find in the pictel site. Could someone tell me where I could find it??? Thank you Ameneh Zahir Alcatel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [Robustness] End to End Acknowledgement Contribution
by Sasha Ruditsky 09 May '00

09 May '00

Tim I just went through the "Message lost" list and I believe that at least some of the messages in the list may be lost without causing any problem. Let start from the *********Communication Mode Command. This command used to ask remote terminal to use new set of outgoing channels. As result the remote terminal will close and/or open new ones. The terminal does this using explicit logical channel signaling. So the MC that sent the communication mode command actually has the acknowledgement for the command. The communication mode command by itself does not cause H.245 state change and may be retransmitted without problem, so the MC that is uncertain whether the message has been delivered or not may always resend it. *********Multipoint Mode Command Multipoint Mode Command is almost the same it actually causes the terminal to comply with the "requestMode"s. The only problem ,I may think about, that may be caused by lost Multipoint Mode Command is request Mode rejection. When this happens MC may safely retransmit Multipoint Mode Command and try request Mode again. *********RELEASE COMPLETE This is correct that this message has no acknowledge and I believe that the reason for this is that it is almost always acknowledge by itself. It is in most cases the last message in the end to end message sequence. In case we have H.245 in the call this sequence may be started by the end session command exchange. For call independent signaling connections procedures in H.450 the RELEASE COMPLETE message always or almost always goes immediately after some other end to end message in opposite direction so may be defined acknowledge to it. Even if such definition is impossible I cannot see the problem that may caused by lost RELEASE COMPLETE message in this case. The real problem with lost RELEASE COMPLETE message may be in the case of fast start signaling. For this specific case we need to find solution. The possible solutions may be: Using RELEASE message (as you proposing) Defining special "End Of Fast Start" message (this does not necessarily requires new syntax let say Facility with empty fast start sequence may be defined to do this). Using STATUS exchange for fast start calls (as we proposing) Preventing usage of fast start on robust system. *********User Input Indication The behavior of the system that receives User Input Indication is not defined in standard. I believe that the recovery from the loss of the message should not be defined in standard too. In addition User Input Indication defined in the way that assumes sending DTMF digits to PSTN where they may be lost even H.323 segment delivers them reliably. In some cases, especially when there is different mechanism to acknowledge User Input Indication delivery, controlling User Input Indication resend on the protocol level may even cause problems. For example there are games where the video/audio streams are broadcasted by TV and the player controls the game over telephone line using DTMF. In case system does not respond properly player tries to correct this sending new DTMFs. If in addition the system tries to resend the lost ones the behavior may be funny. The PSTN systems that currently exist use DTMF to deliver user input. DTMF is by definition is something that may be lost and I believe that there are no mechanisms to acknowledge DTMF that are built into PSTN. So I assume that there are application level methods to solve the problem. What I want to say is that recovery from User Input Indication lost is the application problem and the level and method of recovery shall be defined by the application. *********************************************** Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel Tel: +972-3-645-5220 Fax: +972-3-645-6464 Direct: +972-3-645-5273 sasha(a)radvision.rad.co.il *********************************************** -----Original Message----- From: Tim Chen [mailto:scc@TRILLIUM.COM] Sent: Tuesday, May 09, 2000 5:37 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Robustness] End to End Acknowledgement Contribution Hi, Please find attached our write-up on end to end acknowledgement. As discussed in our last Robustness Group Conference Call, adding these acknowledgements at H.323 level to messages which invoke no responses will prevent call state mismatch should these messages be lost. We hope the group will give some response during Tuesday's conference call. The list of messages that need to be acknowledged shown in the document is preliminary and we would welcome comments and suggestions. Regards, Tim Chen ------------------------------------------------------------ Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim(a)trillium.com http://www.trillium.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1858 uploaded
by Rich Bowen 09 May '00

09 May '00

Colleagues, APC-1858 "Support for Dynamic Parameter Changes in RAS" has been uploaded to the incoming directory. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVC-1798 and AVC-1799 - H.248 Annex F uploaded
by Gunnar Hellstrom 09 May '00

09 May '00

Hello All, The following documents have been placed in ftp://standard.pictel.com/avc-site/Incoming/ and are expected to appear soon in the 0005-Osa directory: APC- 1798 Editor (Gunnar Hellström LM Ericsson) H.248 draft Annex F, Facsimili, Text Conversation and Call Discrimination packages APC- 1799 Editor (Gunnar Hellström LM Ericsson) H.248 Annex F Issues Regards Gunnar ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] End to End Acknowledgement Contribution
by Tim Chen 09 May '00

09 May '00

Hi, Please find attached our write-up on end to end acknowledgement. As discussed in our last Robustness Group Conference Call, adding these acknowledgements at H.323 level to messages which invoke no responses will prevent call state mismatch should these messages be lost. We hope the group will give some response during Tuesday's conference call. The list of messages that need to be acknowledged shown in the document is preliminary and we would welcome comments and suggestions. Regards, Tim Chen ------------------------------------------------------------ Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim(a)trillium.com http://www.trillium.com

2 1

[Robustness] draft document for discussion
by Terry L Anderson 09 May '00

09 May '00

Attached is a draft for APC-1830 describing our alternative robustness architectures, referring to the contributions of Motorola and RadVision and more details of our shared-state solution. Let's discuss this in our call on Tues and I will modify before sending into the ftp site. -- ------------------------------------------------------- Terry L Anderson, DMTS tla(a)lucent.com Lucent Technologies /INS/ Voice over IP Access Networks Rm 2B-121, 600 Mountain Ave, Murray Hill, NJ 07974 Voice:908 582-7013 FAX:908 582-6729 Pager:800.759.8352 pin 1704572 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -------------------------------------------------------

1 0

Osaka meeting information
by Sakae OKUBO 09 May '00

09 May '00

To Osaka meeting participants from the meeting host, Please note the following: 1) The meeting fee is now fixed at exactly 20,000 Yen. Cash or credit card (Visa or MasterCard) is accepted. 2) We will have a working dinner on Wednesday at Rihga Royal Hotel. It will start at 19:00. Some more information will follow later today. 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

APC 1788-1795, 1815, 1837, and 1849 Uploaded
by Paul E. Jones 09 May '00

09 May '00

Colleagues, I have uploaded the following documents for the upcoming meeting into the Incoming directory of the AVC site: APC-1788 - Draft H.323v4 APC-1789 - Draft H.323v3 Implementers Guide APC-1790 - Indicating Frames/Samples per RTP Packet APC-1791 - Call Proceeding / Facility Issues APC-1792 - Empty fastStart versus fastConnectRefused APC-1793 - When to include perCallInfo in an IRR APC-1794 - New Proposed LRJ reason "resourcesNotAvailable" APC-1795 - URQ to contain Alternate Gatekeeper Information APC-1815 - Indicating Support of Annex E for Alternate Endpoints APC-1837 - Usage of Expanded T.35 Country Codes in Recommendations H.225.0, H.245, H.283, and H.341 APC-1849 - Errors in H.225.0 Version 3 ASN.1 Best Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Uploaded contributions
by Rich Bowen 09 May '00

09 May '00

Dear Mr. Okubo, I have uploaded the following contributions to the Incoming directory: APC-1856.zip Editor (R Bowen) Draft H.225.0 v4 APC-1859.doc Cisco Systems Proposal to Support the Redirecting Number IE APC-1860.zip Cisco Systems DNS SRV record query text update APC-1861.zip Cisco Systems Gateway Capacity Reporting Enhancements APC-1862.zip Cisco Systems Issue regarding Calls through NAT Devices Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1851, APC-1855
by Tom-PT Taylor 09 May '00

09 May '00

I have uploaded APC-1855-AAS.zip, "Proposed H.248 Advanced Audio server package". I will not be submitting APC-1851 -- since the proposed package is not yet an official work item, I could simply fold my comments into the main document. Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor(a)nortelnetworks.com

1 0

APC-1864 uploaded
by Barry Andrews 09 May '00

09 May '00

Hi APC-1864 has been uploaded to ftp://standard.pictel.com/avc-site/Incoming/ Regards, Barry Andrews ----------------------------------------------------- Barry Andrews Netergy Networks, Inc. email: barry.andrews(a)netergynet.com tel: 1-408-654-0905 fax: 1-408-980-0432 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1840 uploaded
by Barry Aronson 09 May '00

09 May '00

APC-1840, "Proposal for Mobile IP in H.323 Annex I," has been uploaded as APC-1840.zip. Barry Aronson Barry Aronson Consulting, Inc. 33 Lake Shore Ave. Beverly, MA 01915-1907 USA E-mail: baronson(a)ieee.org Voice: +1 978-232-3994 Fax: +1 978-232-9220 Video: H.320, H.323, and H.324 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC-1826 and APC-1827 zip files are Uploaded
by Reddy, Paul K 09 May '00

09 May '00

Hi Colleagues, I have upload the following document into Incoming directory of the AVC site at http://standard.pictel.com/ftp/avc-site/Incoming APC-1826: Addition of Service Control and Service Data Functions into H.323 Mobility network Architecture APC-1827: Mobility State Models for H.323 Annex H work thanks, 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: Paul E. Jones [mailto:paul.jones@TIES.ITU.CH] Sent: Monday, May 08, 2000 12:36 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: APC 1788-1795, 1815, 1837, and 1849 Uploaded Colleagues, I have uploaded the following documents for the upcoming meeting into the Incoming directory of the AVC site: APC-1788 - Draft H.323v4 APC-1789 - Draft H.323v3 Implementers Guide APC-1790 - Indicating Frames/Samples per RTP Packet APC-1791 - Call Proceeding / Facility Issues APC-1792 - Empty fastStart versus fastConnectRefused APC-1793 - When to include perCallInfo in an IRR APC-1794 - New Proposed LRJ reason "resourcesNotAvailable" APC-1795 - URQ to contain Alternate Gatekeeper Information APC-1815 - Indicating Support of Annex E for Alternate Endpoints APC-1837 - Usage of Expanded T.35 Country Codes in Recommendations H.225.0, H.245, H.283, and H.341 APC-1849 - Errors in H.225.0 Version 3 ASN.1 Best Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.248 Annex C Codepoint Information
by Tom-PT Taylor 09 May '00

09 May '00

What I really wanted to do when I started this thread was question whether all those codepoints from other standards should be reproduced in Annex C. It's just excess baggage if we don't guarantee that they're up to date, and a pain if we do. > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Monday, May 08, 2000 8:42 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.248 Annex C Codepoint Information > > G'Day John, > > In the binary Annex C already has a packageID '0'. If people want a > package name then I'm not adverse to that. > > My second point was that new packages could redefine the parameters in > an appropriately grouped package. This way we get over the problems > associated with a Q.931v7 problem Tom was alluding to. Annex C was a > toolkit of parameters that could be used in the early stages of the > protocol. > > To achieve true interoperability for applications and symmetry between > text and binary I believe that Profiles containing packages and options > is the only way to go. > > Cheers, Christian > > John Segers wrote: > > > > Hi, > > > > I was going to say the same thing as Christian (but strange telephone > > sockets in the UK kept me from doing so): if a reference is provided, > > the values listed in the value column serve as examples only; normative > > text is in the references as indicated at the start of the annex. > > > > The second point Christian mentioned is an interesting one. Is the idea > > that if one defines a package for which there is already an annex C > > codepoint, the package would just refer to that instead of defining a > > new codepoint? If that is the intention, we'd better give annex C a > > package name... > > > > Cheers, > > > > John > > > > Christian Groves wrote: > > > > > > Hello Tom, > > > > > > References are included in Annex C and the text at the start says that > > > the reference is the normative text. I personally would envision that > > > most changes to codepoints would be contained in packages. ie. if we > use > > > packages for defining properties then we align the text and binary > > > encodings of H248. That way we don't need to continuously update SDP > and > > > Annex C to match. > > > > > > Regards, Christian > > > > > > Tom-PT Taylor wrote: > > > > > > > > H.248 Annex C is by concept derivative in nature -- it provides the > means to > > > > reuse codepoints from a variety of other standards. As it currently > stands, > > > > it reproduces these codepoints in the "Value" column. I am > concerned that > > > > this could present a maintenance nightmare. It would make more > sense to > > > > point the user to the specific reference in the other standard and > leave it > > > > at that. > > > > > > > > Tom Taylor > > > > Phone and FAX: +1 613 736 0961 > > > > E-mail: taylor(a)nortelnetworks.com > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > -- > > John Segers email: jsegers(a)lucent.com > > Lucent Technologies Room HE 306 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com

1 0

H.248 Annex C Codepoint Information
by Tom-PT Taylor 09 May '00

09 May '00

H.248 Annex C is by concept derivative in nature -- it provides the means to reuse codepoints from a variety of other standards. As it currently stands, it reproduces these codepoints in the "Value" column. I am concerned that this could present a maintenance nightmare. It would make more sense to point the user to the specific reference in the other standard and leave it at that. Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor(a)nortelnetworks.com

3 3

APC-1819, 1820, 1821, 1822 Uploaded
by Mike Buckley 09 May '00

09 May '00

The following documents have been uploaded: 1819 Lucent Technologies Update on ETSI TIPHON architecture work including latest TIPHON Architecture Draft 1820 Lucent Technologies Update on ETSI TIPHON QoS work including latest TIPHON End to End QoS Framework Draft 1821 Editor (M Buckley) Latest draft of Annex N of H.323 1822 Lucent Technologies Generic Bearer Descriptor for End to End QoS Mike Buckley ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:] On home concepts, etc.
by Roy, Radhika R, ALARC 08 May '00

08 May '00

Hi, Steve: I am really curious to se the detail of Ericsson's contribution. What I am worried about that the basic problems still remain the same whether we go via GKs (or HLFs). Now GKs and BEs have mechanisms in place if any information is not available to a GK (or BE) how to communicate with another one to resolve it. In view of many HLFs, I am afraid that we may to do the same with the HLFs all over again. Then the basic question comes: Why do we want to re-invent the wheel (assuming that a GK or BE will be able to do the job if we go via them because HLFs are sitting behind them). We will discuss when we see your contributions. Best regards, Radhika R. Roy > -----Original Message----- > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com] > Sent: Monday, May 08, 2000 3:10 PM > To: Roy, Radhika R, ALARC > Cc: tsg16q13(a)itu.int > Subject: Re: [H.323 Mobility:] On home concepts, etc. > > Hello Roy, > > Thanks for resending, our mail system is strained here due to the recent > virus which is going around. > > I am in the process of submitting a contribution to the next meeting > (again slowed by the email system). > > I haven´t read the indicated contributions, however I can guess the > contents based your description below. What I am trying to say is that > with the ericsson contribution, Annex G applies between "home" operators, > and the visited network is not considered to be another service domain, > but a means for IP connectivity and maybe some resource support (such > things are really for further study) (there maybe a gatekeeper proxy in > the visited network to proxy the messages to the home gatekeeper in our > view). As such, I don´t view that this breaks the H.323 model in any > means. > > Regards, > > ..//steve > > "Roy, Radhika R, ALARC" wrote: > > > Steve: > > > > I do not know whether you received this or not because I have not seen a > > copy of it from the reflector. So, I am enclosing it again. > > > > Thanks, > > Radhika R. Roy > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALARC > > > Sent: Friday, May 05, 2000 9:02 AM > > > To: 'Stephen Terrill' > > > Cc: tsg16q13(a)itu.int > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > Hi, Steve: > > > > > > I do not know what your reference is up to. > > > > > > Please see the contributions from Alcatel that also shows in one > example > > > as inter-domain communications. > > > > > > You can also see Ericsson's contribution where inter-domain > communications > > > are shown. > > > > > > If you compare the two, you can see a difference. Alcatel's > contribution > > > is following the framework of H.323 (H.225.0 Annex G) although there > are > > > other items that are required to be there (AT&T's upcoming > contributions > > > will explain this as well). > > > > > > I guess that Ericsson's contribution is NOT along the framework of > H.323 > > > (H.225.0 Annex G) for inter-domain communications. It is not an > assumption > > > per se. AT&T's upcoming contribution will explain why it is NOT within > the > > > framework of H.225.0 Annex G. > > > > > > In this context, AT&T is also bringing contributions and we can have a > > > detail discussion in Osaka or in the cof call on May 9. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > > > > -----Original Message----- > > > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com] > > > Sent: Thursday, May 04, 2000 9:13 AM > > > To: Roy, Radhika R, ALARC > > > Cc: tsg16q13(a)itu.int > > > Subject: Re: [H.323 Mobility:] On home concepts, etc. > > > > > > Hi Roy, > > > > > > I am not clear on what suggestions are "breaking" h.323. I > sence > > > that there are assumptions being made which are not necessarily valid. > > > > > > Regards, > > > > > > ..//steve > > > > > > "Roy, Radhika R, ALARC" wrote: > > > > > > > Hi, Gösta: > > > > > > > > Let us discuss this what it means. Let me provide an example. > > > H.323 uses > > > > Q.931/932-like protocol that has been the part the > > > circuit-switching > > > > network. However, H.225.0's Q.931/932 has become a part of the > > > > packet-switched H.323 protocol. Now, H.225.0 (RAS, Q.931/932, > > > Annex G > > > > protocol), H.245, and H.235 have become the part of H.323. > > > > > > > > These protocols have created a new framework of H.323 (H.225.0 > and > > > H.245 are > > > > no longer valid from the circuit-switched PSTN/ISDN network > point > > > of view). > > > > We have got a new set of rules based on the existing H.323 > > > standard. > > > > > > > > In the same token, we can look into any protocols that we > might > > > think of, > > > > but we have to use it within the framework of the existing > H.323 > > > standard > > > > without "breaking" it. > > > > > > > > Our main goal is to extend H.323 protocol to support mobility. > > > > > > > > Hope it will clarify points further. > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > > > > > > -----Original Message----- > > > > > From: Gösta Linder (LME) [SMTP:Gosta.Linder@lme.ericsson.se] > > > > > Sent: Wednesday, May 03, 2000 6:17 PM > > > > > To: Roy, Radhika R, ALARC > > > > > Cc: 'jaakko.sundquist(a)nokia.com'; tsg16q13(a)itu.int > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > > > > > Hi Roy, > > > > > according to ToR for H323 AnnexH, the following outputs are > > > expexted by > > > > > our work: > > > > > "A complete H.323 Annex H specification document will be > > > produced. The > > > > > framework, architecture, any changes to existing H.323 > messages > > > or > > > > > protocols as well as any requirements on the non-H.323 > protocols > > > to be > > > > > utilized as part of the solution will be included in the > > > specification." > > > > > > > > > > This means that we are not restricted to look at HLF/VLF as > BEs > > > under the > > > > > GK. Thus the input by Steve prior to the last teleconf is > not > > > assuming > > > > > HLF/VLF as Bach End functions to GK. > > > > > > > > > > So let us be open in our definitions of a mobility solution > > > supporting > > > > > H323 systems and find a suitable solution. > > > > > Best Regards/Gösta Linder > > > > > > > > > > -----Original Message----- > > > > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > > > > Sent: den 3 maj 2000 16:26 > > > > > To: Gösta Linder (LME); Gösta Linder (LME); > > > > > 'jaakko.sundquist(a)nokia.com'; tsg16q13(a)itu.int > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > > > > > > > > > > Hi, Gösta: > > > > > > > > > > The basic point is that we are extending H.323 to support > > > mobility. So, > > > > > there are some fundamental basis how H.323 protocol works. > So, > > > we are > > > > > committed to be consistent with the H.323 standard that > already > > > exists. > > > > > > > > > > In H.323, the logical entities are terminals, GWs, GKs, BEs, > > > MCUs, MCs, > > > > > and > > > > > others. > > > > > > > > > > HLFs, VLFs, and AuFs are the servers that provide the > backend > > > services > > > > > (BES). > > > > > > > > > > The BES servers are connected behind the GKs and BEs. > > > > > > > > > > Similarly, the directory servers, billing servers, route > > > servers, and > > > > > other > > > > > servers are also considered as the BES servers in H.323. In > the > > > same > > > > > token, > > > > > they also reside behind the GKs and BEs. > > > > > > > > > > So, H.323 protocol is very clear about the relationship > between > > > the > > > > > GKs/BEs > > > > > and the BES servers. The protocol itself says what the > logical > > > relation is > > > > > or should be. More specifically, H.225.0 Annex G shows how > the > > > > > inter-domain > > > > > communications are performed. > > > > > > > > > > In this respect, AT&T is also bring two more contributions > in > > > the upcoming > > > > > SG16 Q.13 Osaka meeting in addition to the contributions > that > > > have been > > > > > submitted to the Ad Hoc Mobility group. > > > > > > > > > > I would appreciate to explain your points more clearly with > > > reference to > > > > > AT&T MD-018 and MD-017. In this way, I could reply you > questions > > > more > > > > > clearly. > > > > > > > > > > Finally, I am confident that we can satisfy all requirements > > > including the > > > > > items that you are up to consistent with the existing H.323 > > > standard. > > > > > > > > > > Thank you very much for continued discussion that helps all > of > > > us to > > > > > understand better. > > > > > > > > > > Best regards, > > > > > Radhika R. Roy > > > > > AT&T > > > > > > > > > > > -----Original Message----- > > > > > > From: Gösta Linder (LME) > > > [SMTP:Gosta.Linder@lme.ericsson.se] > > > > > > Sent: Tuesday, May 02, 2000 5:17 PM > > > > > > To: Roy, Radhika R, ALARC; Gösta Linder (LME); > > > > > > 'jaakko.sundquist(a)nokia.com'; tsg16q13(a)itu.int > > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > > > > > > > Roy, regards your statement; "To be consistent with the > H.323 > > > system > > > > > > architecture in view of multiple HLFs...." seems to be > > > premature. A > > > > > H.323 > > > > > > system architectecture is not as yet defined regards > mobility, > > > that is > > > > > > what we are trying to do. When we identified the HLF, VLF > in > > > Red Banks, > > > > > we > > > > > > did not state them relates role of the GK and if > registration > > > should go > > > > > > via GK or directly to the HLF function. In fact, I do not > see > > > any > > > > > purpose > > > > > > of going via the GK to register or make a location > request. > > > Really, > > > > > > according to the subscription data might give the info > needed > > > to do the > > > > > > right GK selection. I.e. we then better do the GK > selection > > > based upon a > > > > > > HLF selection rather than other way around. > > > > > > Best Regards /Gösta Linder > > > > > > > > > > > > -----Original Message----- > > > > > > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > > > > > > Sent: den 28 april 2000 17:37 > > > > > > To: Gösta Linder (LME); 'jaakko.sundquist(a)nokia.com'; > > > tsg16q13(a)itu.int > > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > > > > > > > > > > > > > Hi, Gösta: > > > > > > > > > > > > If the concept of the home domain needs to be added as > well as > > > home > > > > > > GK/zone > > > > > > (+ home network address) etc., I also see that there is a > need > > > for > > > > > further > > > > > > inclusion in Annex H. > > > > > > > > > > > > However, one side comment in response to Jaakko's > comments, > > > "..If we are > > > > > > talking just about contacting the User's HLF from a > Visited > > > > > > Administrative Domain, my opinion is that no GK in the > Home > > > > > Administrative > > > > > > Domain needs to be involved in this. ..." > > > > > > > > > > > > We do not think that this would "always" be true because > let > > > us NOT > > > > > assume > > > > > > that the there is only ONE HLF (or one logically clustered > > > HLF) with > > > > > > centralized architecture in a domain. To be consistent > with > > > the H.323 > > > > > > system > > > > > > architecture in view of multiple HLFs (centralized or > > > distributed), > > > > > > associations through signaling messages of the backend > > > services (e.g., > > > > > > HLFs/VLFs, security servers [AuFs], billing servers, > directory > > > servers, > > > > > > etc) > > > > > > are made via the GKs and BEs. > > > > > > > > > > > > Best regards, > > > > > > Radhika R. Roy > > > > > > AT&T > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gösta Linder (LME) > > > [SMTP:Gosta.Linder@LME.ERICSSON.SE] > > > > > > > Sent: Friday, April 28, 2000 11:15 AM > > > > > > > To: 'jaakko.sundquist(a)nokia.com'; tsg16q13(a)itu.int > > > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > > > > > > > > > Jakko, > > > > > > > sorry for not beeing able to answere until now; > > > > > > > The comments you made clarifies what you were aiming > for. > > > With that I > > > > > > have > > > > > > > no concerns with your statements proposed for further > > > inclusion in > > > > > Annex > > > > > > > H. > > > > > > > Regards / Gösta > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: jaakko.sundquist(a)nokia.com > > > [mailto:jaakko.sundquist@nokia.com] > > > > > > > Sent: den 20 april 2000 13:59 > > > > > > > To: Gosta.Linder(a)lme.ericsson.se; tsg16q13(a)itu.int > > > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc. > > > > > > > > > > > > > > > > > > > > > Hi Gösta, > > > > > > > > > > > > > > Comments embedded... > > > > > > > > > > > > > > > Jakko, > > > > > > > > regards Home GK; > > > > > > > > > > > > > > > > I am not sure I understand what subject you are > addressing > > > > > > > > with "a home GK, and more precicely in such a way that > > > > > > > > there is only one home GK for a User" > > > > > > > > > > > > > > > > As we agreed in the mailing prior to the Tel Conf; > there > > > > > > > > might be more than one GK in Home admin domain, even > > > though > > > > > > > > just one is seen from Visited Admin Domains. > > > > > > > > > > > > > > I do not remember agreeing to anything like this. What > > > exactly do you > > > > > > mean > > > > > > > with "just one is seen from Visited Admin Domains"? Of > > > course there > > > > > can > > > > > > be > > > > > > > multiple GKs per domain and my opinion is that the > Visited > > > > > > Administrative > > > > > > > Domain should not even be aware of the amount or > topology of > > > GKs in > > > > > the > > > > > > > Home > > > > > > > Administrative Domain. > > > > > > > > > > > > > > If we are talking just about contacting the User's HLF > from > > > a Visited > > > > > > > Administrative Domain, my opinion is that no GK in the > Home > > > > > > Administrative > > > > > > > Domain needs to be involved in this. > > > > > > > > > > > > > > > > > > > > > > > Or are you are addressing the the issue of which is > the GK > > > > > > > > that serves a user that is attached to a Visited Admin > > > > > > > > Domain? Perhaps you remember from WP2 plenary in > Geneva, > > > we > > > > > > > > agreed on having two alternatives; either a GK of Home > > > Admin > > > > > > > > Domain OR the GK of Visited Admin Domain service > control. > > > The > > > > > > > > overall objective for the Home Admin GK control is the > one > > > > > > > > pointed out by Radhika in a just recent mail pointing > at > > > > > > > > having a mobility concept that allows for freedom in > > > service > > > > > > > > provisioning; i.e, the freedom of the service provider > to > > > > > > > > offer the service he wants without waiting for the > > > > > > > > Administrator of the Visited Domain to introduce the > > > service > > > > > > > > needed by the Home Administrator customer(=user). This > > > would > > > > > > > > then in turn spoil the concept of providing a > homogeneous > > > > > > > > service for the user roaming between admin domain > until > > > each > > > > > > > > new service is standardised and implemented > accordingly > > > > > > > > between the Administartors of all domains within a > > > > > > > > "homogeneous service alliance group". > > > > > > > > > > > > > > > > > > > > > > I do remember the discussions in Geneva. This is > actually a > > > big part > > > > > of > > > > > > > what > > > > > > > we have been discussing with Steve and I think we should > try > > > to > > > > > describe > > > > > > > these two alternative service provisioning schemes in > the > > > Annex H (we > > > > > > > already have reserved headings for the explanations for > them > > > in the > > > > > > > annex). > > > > > > > I tried to say in many of my mails about the Home GK > idea > > > that I do > > > > > > > understand that it is probably needed in the Home > executed > > > services > > > > > > > scheme, > > > > > > > but in my opinion not in the Visited Domain executed > > > services scheme. > > > > > > > > > > > > > > - Jaakko > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:] A new editor's draft H.323 Annex H
by Roy, Radhika R, ALARC 08 May '00

08 May '00

Hi, Jaakko: I hope that you have been enjoying the ice-hockey.... I understand that the editor's draft is just a contribution for the upcoming tomorrow's conf call, not a draft for the Osaka meeting. I do not know which parts of your draft have been taken from the contributions that had been discussed and agreed. I have seen no reference to it. Or, have you made some educative guess from your side? Let me explain. You have two roles to play: First as an editor to reflect what has been agreed upon by the members based on contributions. Second, an individual from Nokia to agree or disagree. An editor must provide the draft that will reflect what has been agreed by the members based on contributions. However, as an individual from a company an editor may have differences. These differences can be reflected in the draft in two ways: 1. As an editor's note and 2. Even as an individual from Nokia (assuming that subsequent contributions will clarify this). I do not have enough time to provide all comments in writing. In brief, I have the following comments: Section 4: I guess that you have one contribution showing these figures 2 through 7 (there is no reference - I see a similarity- am I correct?). We never discussed this contribution in any conference call. How come that you have included all figures from your contribution that has not been discussed and agreed? In fact, we discussed about your earlier contribution where we have agreed that we will start from all H.323 scenarios: First, intra-zone, inter-zone, and inter-domain scenarios. For inter-working between H.323 and non-mobile scenarios, there are many possible scenarios and we may not address in this document for now for the sake of time. So far I re-collect, this has been the decision. Section 4 does NOT reflect this. Section 7: I like to see that there should be an editor's note that "Figure 8 will be revisited based on the extensions that will be made in H.323 to support mobility. This is just a place holder to provide references for the on-going discussion." Section 8: Which contributions your are referring here that we have agreed? I would request that people MUST bring contributions to define virtual home and service execution environment before an editor put any texts in it. Did you submit an outline of your draft to be approved? Section 9: Which contributions you are referring to? Did you have any outlines for this section that need to be approved? My understanding has been that we agreed that the mobility management will include: A. Intra-Zone, B. Inter-Zone, and C. Inter-Domain. In each case it will have the following: 1. GK discovery 2. Registration 3. Location update 4. Call establishment AT&T and Alctel contributions are there and these contributions were discussed. The outlines should follow these procedures to follow the text consistently. Now I am providing comments per sections that you have arranged although I do not agree with the outlines. 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. I would expect, like visiting/visited domain, the concept of visiting/visited/target network address should be taken as a part of it. Without this, the mobility management will almost be MEANINGLESS because the trivial mobility management keeping some addresses in a database like VLFs/HLFs do not help the service providers and the mobility management through re-registration is already there in H.323, and no new standard work is needed for extending the so called VLFs and HLFs databases. Figure 11 shows that the inter-zone mobility management is maintained using the single HLF. Which contributions you are referring to? Did we agree on this concept? AT&T contribution shows that it is an unacceptable proposition if we consider that there is a single HLF (as the protocol is "hard-wired" for a centralized HLF configuration)? Figure 12 shows that a single VLF is communicating with multiple HLFs. Which contributions do you refer to? Figure 13 shows that HLFs are communicating between the domains? Did you not see that we are NOT in sink with this approach because the questions have been raised that this approach might be "breaking" the H.323 standard? AT&T has also provided contributions regarding this (I guess that Alcatel's contribution also agrees with AT&T's contribution in this regard). Are you "pushing" for some something (or am I missing something)? If it is so, please bring contributions, we will be pleased to discuss. Section 9.2: Use of GRQ messages for the GK discovery is NOT new in H.323. It is already a standard. A reference to the existing H.323 standard is enough. However, the fundamental question has been that GRQ messages are NOT efficient for the GK discovery in the cellular environment. AT&T contributions have provided an alternative solution using the MGA message for the GK discovery. So, the use of GRQ messages are INEFFICIENT for the GK discovery. So, it is NOT acceptable in the highly mobile environment. Section 9.5: Again, I like to know which contributions you are referring to? Figures 15, 16, 17, 18, and 19 show that, as if, the protocol is "hard-wired" for the centralized HLF configuration. AT&T contributions do not assume this. We have NOT accepted this notion. So, the basic question: Why do you want to include the material where there are no contributions and no agreement? There are fundamental flows the way you have shown all information flows. Let me cite few examples: You have shown that LRQ messages are sent from the GK to the VLF and/or HLF. Why do you think so? Did you not see that we have NOT even agreed with this in the last conference call and via emails? AT&T contributions have used NEW mobility management messages. We have serious problems if we use LRQ messages like this. That is why, AT&T has provided a contribution APC-1769. Considering the comments provided above, all texts provided in your contribution need a COMPLETE re-writing of the document. I understand the difficulty with the job as an editor. I appreciate your efforts. However, there are some norms that an editor has to follow: Contributions and Agreement made. If editors have their opinions, they can bring separate company contributions (NOT as Rapporteur contributions). Hope to discuss the same in tomorrow's conf call. I am also curious to know which the team won the ice-hockey..... Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Monday, May 08, 2000 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] A new editor's draft H.323 Annex H > > Hi all, > > I have uploaded the new editor's draft H.323 Annex H to the URL: > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/ > > I suggest that we go through the changes I have made in tomorrow's > teleconference. > > I'm sorry that I haven't responded to any messages recently, but working > with the draft took a bit more of my time than I expected, so I simply > haven't had the time. I will try to read all the messages through tomorrow > and hopefully answer to some. > > And now I'm off to watch Finland demolish the poor Norwegians in the > ice-hockey world championships... > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Ad hoc mob conf call 9 May
by Senthil Sengodan 08 May '00

08 May '00

Folks, Here is the IMTC sponsored Conference Call Information for the H.323 Ad-Hoc mobility group: Date: May 9, 2000 Time: 8:00 am PT - 10:30 am PT Lines: 20 Reservation # 15193695 Dial In # 1.888.303.1137 Passcode # 2511365 - Senthil -----Original Message----- From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] Sent: Monday, May 08, 2000 12:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Ad hoc mob conf call 9 May Hi Paul, I have been in touch with Senthil regarding the Conference call bridge arrangements, I understand that Senthil from Nokia will send out an email with the Conference Call Bridge information sponsored by IMTC ASAP. If IMTC cannot get the conference call bridge for tomorrow, Intel is willing to sponsor the conference call bridge for tomorrow conference call. But, I have to know ASAP, so that I have this afternoon to make arrangement. Senthil, Please respond to this email. 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: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Monday, May 08, 2000 2:04 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Ad hoc mob conf call 9 May Ad Hoc Mobility group members, Please note there will be a conference call on Tuesday, 9 May, at 8 a.m. pacific standard time, 4 p.m. UK time, to discuss the latest version of Annex H which should be available shortly from Jaakko. Can either Paul Reddy or Vineet Kumar please contact Senthil Sengodan to set up the conference bridge...(I've been unsuccessful to get this arranged so far with Senthil). Agenda: 1. Introductions 2. Summary of current position and agreements on roaming discussions (Paul G) 3. Walk-through of Annex H (APC1816) (Jaakko S) 4. Any other business Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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