- sg16-avd - lists.packetizer.com

H.323 Mobility - Annex I
by Adam Li 06 Apr '00

06 Apr '00

Hi, there, We have a technical proposal for H.323 Mobility - Annex I error resilience. We are anticipanting to present the scheme and simulation result of it at the meeting next month in Japan. See you guys at Osaka. Adam Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 06 Apr '00

06 Apr '00

Hi, Paul and All: I appreciate your clarifications. I also like to re-emphasize that all other emails sent by me in response to other members also complement your explanations. Please also see my other mails how I have interpreted the word "intra-network" mobility management. If there are any questions, please let me know. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > Sent: Thursday, April 06, 2000 8:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Hi mob group > > Interesting debate. Just to say that the following is my understanding of > our next phase of work (please correct me if I am mistaken): > > Considering that, > > 1. All-H.323 scenario does not have any interworking gateways involved to > other non H.323 networks, and we need to start on simple work first (the > word Scenario is used as per Tiphon), > 2. Intra network means pertaining to one single network. A single network > consists of one administrative domain. One administrative domain may have > one or more zones. We also have defined home and visited administrative > domains, HLF,VLF, AuF, and now have an equal understanding of these terms, > 3. Annex H deals with terminal and user and service mobility issues which > we > know inherently implies mobility management, > > we, I think, agreed to progress on from Figure 1 MD011 Intra-network > all-H323 scenario and specify call establishment/release etc. procedures > for > all of the possible roaming combinations (some examples are outlined in > Stephen Terrill's last email). This will naturally include specifying the > mobility management functions/interfaces, perhaps stating possible > locations > of VLF etc., identifying functionality/interfaces not covered or not > required in the existing architecture diagram, and such issues. So this > scenario will be defined by us in its entirety in the coming weeks. > > Paul > > ---------- > From: Jaakko Sundquist[SMTP:jaakko.sundquist@nokia.com] > Reply To: Jaakko Sundquist > Sent: 06 April 2000 09:40 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Mob ad hoc group progress > > Hi all, > > Comments to Radhika's posting below... > > Hi, Everyone: > > We are again not in sink what is going on with respect to progress > of our > work. Let me try again. > > That is just what I was trying to say... > > > We have talked about Nokia's contribution MD-011. We have taught > that this > provides a reference to start with. In that contribution, we have > Figure 1: > Intra-zone all H.323 scenario. We have decided that we will go one > step at a > time. > First of all the scenario is called all-H.323 scenario. The > figures > just try > to explain what kind of call models that scenario involves. What > we > have > decided is to go one scenario at a time (not one "call model" at a > time). > Furthermore, it was evident in the last teleconference that the > cases > illustrated in the figures were not adequate and they need to be > enhanced. > > > Now what does this Figure 1 provides us? We are NOT sure unless we > explain > in detail what this scenario means to us. We cannot go to the next > step > unless we analyze what the scenario of Figure 1 provides us. It > may > or may > not provide new insights from H.323 mobility point of view, but it > is our > starting point. We have to complete it first before we go for the > next step. > In this simple case, a mobile entity will move from its home > network > to a > foreign network. This also requires mobility management: Change in > network > point of attachment and its possible impact in H.323 system. > > This is just what I mean. What do you mean by the above text? > First > of all I > don't know what you mean by home and foreign network. Are you > saying > that > inside one zone there are multiple networks (so that moving from > the > home > network to a visited network is possible while all the time being > located > inside the same zone)? You are right in saying that we need to > analyze this > call model also, but first we need to identify the different cases > for the > user's location, i.e. both users at home domain, user-A at home > domain & > user-B in a visited domain, etc. > Related to the above, we have already defined the terms Home > Administrative > Domain, Visited Administrative Domain and Serving Administrative > Domain in > the draft H.323 Annex H. I think that these definitions are very > good > (thanks to Milo, you see that we do agree on some things once in a > while ;-) > and they clearly bind the subscription of a user (or a subscriber) > to a > Domain. My opinion is that this means that the Administrative > Domains are > the areas that divide the H.323 system into home and visited areas > from the > point of view of the user. In other words, I wouldn't necessarily > even > define terms, such as, Home Zone or Home Gatekeeper, because the > above > definitions already bind the home of a user to the whole domain, > not > a > particular zone. If we want to define the term Home Zone, I think > it > should > mean ANY zone inside the Home Administrative Domain, similarly a > definition > for the Home Gatekeeper could be made. > Based on the above, we can assume that when a user is in his/her > Home > Administrative Domain, the HLF that contains his/her information > is > also > inside that Domain and inter-domain communications are not needed > for the > Mobility Management of that user. Similarly, if the user is in a > Visited > Administrative Domain, inter-domain communications are needed for > the > Serving Administrative Domain to contact the user's HLF. This will > also lead > to different location management cases for e.g. the intra-zone > all-H.323 > call model. > > > Once we complete Figure 1, we will go for the next one: Figure 2 > Inter-Zone > all H.323 scenario. Of course, this is a complicated one to > provide > better > scenario for mobility management: Change in network point > attachment > + > Change in zone (logical) point of attachment as well. > > I think that this is a good way for an individual to work, but > personally I > would like to see contributions that address more of these call > models at a > time. We can, of course, deal with the contributions in the order > that > Radhika is proposing, I have nothing against that. > > A side note: We have defined VLF and HLF. VLF may be assumed to be > co-located within the GK. But let people explain the interactions > including > VLF and HLF the way they prefer in their contributions. The > contributions > themselves will justify how VLF and HLF should perform their > functions. Let > us not mandate anything beforehand unless things are explained in > the > contributions. > > One thing I would like to ask the ad hoc group members, is that > should we > assume at this point that the VLF is co-located with the > gatekeeper > (as a > "composite network element" illustrated in Figure 3 of the draft > H.323 Annex > H). I think this could be a good assumption in the first version > of > Annex H, > because it seems that most of us are thinking that way already. It > would > only mean that we wouldn't have to specify anything for the > reference point > E, but leave it open in the first version of the annex, similarly > as > was > done with reference point B in the H.225.0 Annex G. Other > composite > network > elements could also be identified for the first version of the > annex. I > think that this kind of grouping could conciderably simplify our > work for > the first version by reducing the number of interfaces that we > need > to > specify. We should probably encourage contributions proposing the > composite > network elements and perhaps discuss these contributions in a > teleconference > (maybe not the next, but the one after that). > > - Jaakko

1 0

Re: Third party initiated pause and rerouting, share with voice, etc.
by Francois Audet 06 Apr '00

06 Apr '00

> When we agreed on the Annex F SET device way of third party > initiated pause > and re-routing (FACILITY message with empty FastStart structure), I > mentioned that this should not be limited to Annex F devices > but should of > course also be possible for non-Annex F H.323 devices that support > fastStart. This possibility should be added to 8.4.6 of H.323. The other option is of course to NOT add it to 8.4.6, and modify Glenn Freunlich's "share with voice" procedure so that the reconnection doesn't use fast start... Any preferences?

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 06 Apr '00

06 Apr '00

Hi, Steve: You are right. Figure 1 is by no means is finalized. We have taken this as a starting point for discussion. That does not mean we have to take Figure 1 as it is. In fact, I am bringing contributions in this area. I will have a different figure 1 (modified) in my contribution. I will explain all things in the context of intra-domain mobility management. There will be many more figures to highlight many things that we think need to be there to make the intra-zone mobility management complete. I expect that all people bringing contributions will do the same. Let me clear this again. Figure 1 of Nokia's contribution MD011 is NOT a complete one. It is up to as a team to decide when we analyze all facts based on contributions that are coming for the upcoming conf call. Similar is the case for Figures 2, 3, and others. These figures are providing some kind of guidelines or references to streamline our work so that we can bring contributions along those lines in explaining the things. In the same token, we will explain VLF and HLF for each case. Finally, the contributions will explain pros and cons and we will go from there to decide as a group what makes sense to make standard for H.323 mobility. I appreciate your note. Best regards, Radhika > -----Original Message----- > From: Stephen Terrill [SMTP:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 06, 2000 4:17 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Hi Roy, > > Just a note, I assume that when refering to "figure 1", I understood from > the phone meeting that it was a modified figure 1 as we agreed to as it > wasn´t clear in respect to whether the two subscribers where roaming > and/or home etc. I trust that was what you were refering to in your > thinking. > > Regarding the VLR and GK being co-located, I think that is still a > discussion. > > Best Regards, > > ..//steve > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Everyone: > > > > We are again not in sink what is going on with respect to progress of > our > > work. Let me try again. > > > > We have talked about Nokia's contribution MD-011. We have taught that > this > > provides a reference to start with. In that contribution, we have Figure > 1: > > Intra-zone all H.323 scenario. We have decided that we will go one step > at a > > time. > > > > Now what does this Figure 1 provides us? We are NOT sure unless we > explain > > in detail what this scenario means to us. We cannot go to the next step > > unless we analyze what the scenario of Figure 1 provides us. It may or > may > > not provide new insights from H.323 mobility point of view, but it is > our > > starting point. We have to complete it first before we go for the next > step. > > In this simple case, a mobile entity will move from its home network to > a > > foreign network. This also requires mobility management: Change in > network > > point of attachment and its possible impact in H.323 system. > > > > Once we complete Figure 1, we will go for the next one: Figure 2 > Inter-Zone > > all H.323 scenario. Of course, this is a complicated one to provide > better > > scenario for mobility management: Change in network point attachment + > > Change in zone (logical) point of attachment as well. > > > > Then Figure 3: Inter-Domain all H.323 scenario. > > > > And so on ... > > > > If we do not do this, we might again go into circle. > > > > I guess that this should be very clear to everyone. I would assume that > > people should bring contributions along this line: Figure 1, 2, ....etc. > > > > Let us not by-pass any step for sake of clarity and completeness. > > > > A side note: We have defined VLF and HLF. VLF may be assumed to be > > co-located within the GK. But let people explain the interactions > including > > VLF and HLF the way they prefer in their contributions. The > contributions > > themselves will justify how VLF and HLF should perform their functions. > Let > > us not mandate anything beforehand unless things are explained in the > > contributions. > > > > I like to see all members provide their comments on this. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > > > Sent: Wednesday, April 05, 2000 6:06 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Mob ad hoc group progress > > > > > > Hi all, > > > > > > Once again there seems to be quite a lot of confusion about the terms > we > > > are > > > using. First of all, we did not make it altogether clear in the last > > > teleconference, what is meant by a scenario. My contribution on the > issue > > > tried to group both the "call scenarios" and the "location management > > > scenarios" into one set of scenarios. We did notice during the > > > teleconference that this was not an adequate approach and now some of > the > > > problems occuring in this email discussion reflect that. > > > For example, when Radhika is talking about starting with the > intra-zone > > > scenario, I'm not quite sure what he is meaning. I understand that the > > > "call > > > scenario" he is talking about, is the one in which both terminals are > > > registered to the same gatekeeper. However, this "call scenario" in > itself > > > does not really bring anything new to H.323 unless there is something > that > > > we need to address with the "location management scenarios". Now, > while > > > the > > > "call scenario" does indeed fall into the category of intra-zone > > > communications, the "location management scenario" for finding the > address > > > of the B-subscriber of the call might not, i.e. the VLF and HLF that > need > > > to > > > be contacted may not be located in the same zone or even domain. > > > Furthermore, we haven't even decided that the VLF and HLF should be a > part > > > of any zone. I know that most of us actually think that the VLF is > always > > > located with the gatekeeper, but so far we haven't made that decision > and > > > certainly we haven't coupled the HLF functionality always with the > > > gatekeeper. Thus it is quite unclear what is meant by intra-zone > "location > > > management scenarios" and I would suggest that we do not even try to > > > define > > > this term. Instead intra vs inter domain "location management > scenarios" > > > make much more sence. > > > (Note that I'm using the terms "call scenario" and "location > management > > > scenario" quite freely here. If we want to use such terms, they > definitely > > > must be clearly defined.) > > > > > > Also, I would like to point out that talking about intra-zone, > inter-zone, > > > etc. scenarios, is actually not what was originally meant by a > scenario. > > > The > > > idea to introduce scenarios into the H.323 Mobility work came from > Tiphon, > > > where 5 different scenarios are identified. These scenarios do not > take > > > into > > > account, whether the call (or other connection) takes place inside one > > > zone > > > (intra-zone), between two zones (inter-zone) or between domains > > > (inter-domain). The scenarios in Tiphon simply state which network > types > > > are > > > involved in the connection, e.g. Tiphon scenario 1 is the VoIP-to-SCN > > > scenario, Tiphon scenario 2 is the SCN-to-VoIP scenario, etc. These > were > > > the > > > kind of scenarios I thought we were trying to identify in the last > > > teleconference. Of cource, each of this kind of scenarios may involve > > > calls > > > that are intra-zone, inter-zone or inter-domain calls, but we > shouldn't > > > call > > > (no pun intended) these different call models as scenarios. > > > We have now chosen the all-H.323 scenario as the first one to examine > > > (although we didn't even know what it means). In my mind this means > that: > > > * We only examine call cases, in which no gateways are included. > > > * We examine gatekeeper discovery, registration and location > > > updating > > > cases, in which the user is accessing the H.323 system either in > his/her > > > home network (e.g. domain) or a visited network (e.g. domain). > > > * We examine call establishment and call release cases, in which > the > > > A-subscriber is either in his/her home network (domain) or in a > visited > > > network (domain). > > > * We examine call establishment and call release cases, in which > the > > > B-subscriber is either in his/her home network (domain) or in a > visited > > > network (domain). Note that the call can be intra-zone, inter-zone or > > > inter-domain irrespective of whether the B-subscriber is in home or > > > visited > > > network. > > > * We examine mid-call scenarios (e.g. some supplementary > services), > > > in > > > which the user (either A- or B-subscriber) is either in his/her home > > > network > > > or in a visited network. > > > * In the context of H.323 Annex H we do not address the > inteworking > > > functionalities (IWFs) between the HLF/VLF/AuF and some non-H.323 > network, > > > unless some other document (such as H.246 Annex E) proposes additions > to > > > H.323 Annex H. (Note that, when we start work on some other scenarios > in > > > the > > > future, we probably will have to take the IWFs into account.) > > > > > > Other issues that need to be addressed are at least the definitions > for > > > the > > > home/visited network/domain/zone/gatekeeper, because it seems to me > that > > > some members are already using some of these terms in ways that > already > > > point to certain solutions, on which we have not yet agreed. > > > > > > I will try to work out a suitable contribution for the next > teleconference > > > to clarify these issues properly. If you have some comments to this > mail, > > > please respond. I know that this is a long posting with quite a lot of > > > issues in it and I'm sure that I haven't explained myself too clearly > in > > > all > > > parts of it, so please ask. > > > > > > ------------------------------------------------ > > > Jaakko Sundquist * > > > +358 50 3598281 * Audere est Facere! > > > jaakko.sundquist(a)nokia.com * > > > ------------------------------------------------ > > > > > > -----Original Message----- > > > From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > > > Sent: 04. April 2000 15:31 > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: Mob ad hoc group progress > > > > > > Paul: > > > > > > Thanks for clarifications. > > > > > > In the last conf call, we even cannot complete the simple intra-zone > > > (intra-network, inter-network) scenarios first. You are right that we > > > should > > > concentrate on the scenarios (Registration procedures, Gatekeeper > > > discovery, > > > Location update, Call establishment, Mid-Call scenarios (e.g. > > > supplementary > > > services, user interaction, Call release). > > > > > > Definitely, we can go further: Inter-Zone (intra-domain) scenarios as > well > > > if we can agree on the first one. AT&T contributions already contain > many > > > of > > > those aspects. Hope to bring new contributions explaining further in > both > > > scenarios. > > > > > > Best regards, > > > > > > Radhika R. Roy > > > AT&T > > > > > > > -----Original Message----- > > > > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > > > > Sent: Sunday, April 02, 2000 3:52 PM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: Mob ad hoc group progress > > > > > > > > Radhika, > > > > > > > > Conf call is for Annex H only as before...nothing has > changed...change > > > can > > > > only take place when the group agrees. Please do not read into the > > > email > > > > more than what it says. I was only trying to highlight, in a high > level > > > > report, the plight of Annex I since nothing much has moved in it, > and it > > > > is > > > > an Annex which together with Annex H covers the mobility aspects. > As > > > far > > > > as > > > > Annex E is concerned, the point was that the mapping was the work > of > > > one > > > > individual or one company, thus could have errors or omissions (more > > > than > > > > likely)...again only highlighting to people to check out this > mapping. > > > > > > > > Contributions for next conf call to be for All H.323 intra-network > > > > scenario > > > > for: > > > > Registration procedures, Gatekeeper discovery, > Location > > > > update, Call establishment, Mid-Call scenarios (e.g. > > > > supplementary services, > > > > user interaction), Call release. Also contributions > on > > > > any > > > > impacts on the already specified architecture in the light of the > > > present > > > > work are welcome. > > > > > > > > Paul > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > > > > Sent: 01 April 2000 00:00 > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: Mob ad hoc group progress > > > > > > > > Hi, Paul and Mobility Group: > > > > > > > > I like to see that it should be clarified via emails > > > > whether > > > > H.323 Annex I > > > > and H.246 Annex E will be a part of the conference > call. > > > > My > > > > personal > > > > preference is not to discuss annexes I and E during > the > > > > conference call > > > > although email discussions will be preferred. > > > > > > > > If Annex I and E are included in the conference > call, I > > > > like > > > > to see the > > > > actual time in the agenda when these items will be > > > > discussed > > > > so that people > > > > can best use their time in joining the particular > time > > > > slot > > > > for each Annex. > > > > > > > > The proposal is as follows: > > > > > > > > 1. The upcoming conference call to be dedicated for > > > H.323 > > > > Annex H. > > > > 2. Let both editors of H.323 Annex I and H.246 Annex > E > > > > propose via emails > > > > whether any issues to addressed. > > > > 3. If annex I and E are included in the agenda of > the > > > > upcoming conference > > > > call, I like to the time slots when these annexes > will > > > be > > > > discussed so that > > > > people can join the particular time slots of > interest. > > > > Alternatively, > > > > separate conference calls can be arranged for > annexes I > > > > and > > > > E. > > > > 4. Are editors or any members of the mobility group > sure > > > > what would be the > > > > scope of work (I guess that Annex E is stable for > now - > > > > thanks to the > > > > editor) for those annexes? > > > > > > > > Paul: Would you please clarify what specific area > that > > > we > > > > need to discuss > > > > for the next conference call for H.323 Annex H? My > guess > > > > is > > > > that we may > > > > start with intra-zone communication first. I am > planning > > > > to > > > > bring > > > > contribution(s) describing this for mobility > management: > > > > Discovery, > > > > Registration, Location Updates, and Call > Establishment. > > > > > > > > I would appreciate comments form all members. > > > > > > > > Best regards, > > > > > > > > Radhika R. Roy > > > > AT&T > > > > H.323 Ad Hoc Mobility Group > > > >

1 0

Re: Mob ad hoc group progress (ignore the previous mail)
by Roy, Radhika R, ALARC 06 Apr '00

06 Apr '00

Hi, Everyone: Contributions are there or are underway in explaining the things. I am not sure whether the explanation provided by Jakko is clarifying all logical steps that I have mentioned. Let us see the contributions in explaining the things. H.323 has building blocks: zone and domain (adm). A zone may have one or many networks. A domain may have one or many zones. A domain may be home or foreign (visiting/visited/target) from mobile user point of view. Similarly, a zone can be home of foreign (visiting/visited/target) from mobile user point of view. In the same token, a network can be home of foreign (visiting/visited/target) from mobile user point of view. With respect to VLF, it is an entity already defined. Its function is well defined. Where can it be located? It is primarily an implementation issue (not protocol issue). Let contributions explain this. If someone wants to co-locate it with the GK, it is fine. If not, .... then what? Similar is the case with HLF. We will go from Figures 1, 2, 3, ... and so on of Nokia's contribution MD-011. Again, let us not mandate anything beforehand. let contributions explain pros and cons and we will go from there. Let us not be afraid of explaining the things in contributions. Hope this will further clarify the things. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, April 06, 2000 4:12 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress (ignore the previous mail) > > My comments did not show too clearly in the last mail due to the wonderful > M$ Outlook settings, so I'm resending this... > > > Hi all, > Comments to Radhika's posting below... > > > > Hi, Everyone: > > > > We are again not in sink what is going on with respect to > > progress of our > > work. Let me try again. > > That is just what I was trying to say... > > > > > We have talked about Nokia's contribution MD-011. We have > > taught that this > > provides a reference to start with. In that contribution, we > > have Figure 1: > > Intra-zone all H.323 scenario. We have decided that we will > > go one step at a > > time. > First of all the scenario is called all-H.323 scenario. The > figures just try to explain what kind of call models that scenario > involves. > > What we have decided is to go one scenario at a time (not one "call model" > at a time). > Furthermore, it was evident in the last teleconference that the cases > illustrated in the figures were not adequate and they need to > be enhanced. > > > > > Now what does this Figure 1 provides us? We are NOT sure > > unless we explain > > in detail what this scenario means to us. We cannot go to the > > next step > > unless we analyze what the scenario of Figure 1 provides us. > > It may or may > > not provide new insights from H.323 mobility point of view, > > but it is our > > starting point. We have to complete it first before we go for > > the next step. > > In this simple case, a mobile entity will move from its home > > network to a > > foreign network. This also requires mobility management: > > Change in network > > point of attachment and its possible impact in H.323 system. > > > This is just what I mean. What do you mean by the above text? > First of all I don't know what you mean by home and foreign network. Are > you > > saying that inside one zone there are multiple networks (so that moving > from the home network to a visited network is possible while all the time > being located inside the same zone)? You are right in saying that we need > to > analyze this > call model also, but first we need to identify the different cases for the > user's location, i.e. both users at home domain, user-A at home domain & > user-B in a visited domain, etc. > Related to the above, we have already defined the terms Home > Administrative Domain, Visited Administrative Domain and Serving > Administrative Domain in the draft H.323 Annex H. I think that these > definitions are very good > (thanks to Milo, you see that we do agree on some things once in a while > ;-) > and they clearly bind the subscription of a user (or a subscriber) to a > Domain. My opinion is that this means that the Administrative Domains are > the areas that divide the H.323 system into home and visited areas from > the > point of view of the user. In other words, I wouldn't necessarily even > define terms, such as, Home Zone or Home Gatekeeper, because the above > definitions already bind the home of a user to the whole domain, not a > particular zone. If we want to define the term Home Zone, I think it > should > mean ANY zone inside the Home Administrative Domain, > similarly a definition for the Home Gatekeeper could be made. > Based on the above, we can assume that when a user is in his/her Home > Administrative Domain, the HLF that contains his/her information is also > inside that Domain and inter-domain communications are not needed for the > Mobility Management of that user. Similarly, if the user is in a Visited > Administrative Domain, inter-domain communications are needed for the > Serving Administrative Domain to contact the user's HLF. This will also > lead > to different location management cases for e.g. the intra-zone all-H.323 > call model. > > > > > Once we complete Figure 1, we will go for the next one: > > Figure 2 Inter-Zone > > all H.323 scenario. Of course, this is a complicated one to > > provide better > > scenario for mobility management: Change in network point attachment + > > Change in zone (logical) point of attachment as well. > > > I think that this is a good way for an individual to work, > but personally I would like to see contributions that address more of > these > call models at a time. We can, of course, deal with the contributions in > the > order that > Radhika is proposing, I have nothing against that. > > > A side note: We have defined VLF and HLF. VLF may be assumed to be > > co-located within the GK. But let people explain the > > interactions including > > VLF and HLF the way they prefer in their contributions. The > > contributions > > themselves will justify how VLF and HLF should perform their > > functions. Let > > us not mandate anything beforehand unless things are explained in the > > contributions. > > > One thing I would like to ask the ad hoc group members, is > that should we assume at this point that the VLF is co-located with the > gatekeeper (as a "composite network element" illustrated in Figure 3 of > the > draft H.323 Annex H). I think this could be a good assumption in the first > version of Annex H, because it seems that most of us are thinking that way > already. It would only mean that we wouldn't have to specify anything for > the > reference point E, but leave it open in the first version of the annex, > similarly as was done with reference point B in the H.225.0 Annex G. Other > composite network elements could also be identified for the first version > of > > the annex. I think that this kind of grouping could conciderably simplify > our work for the first version by reducing the number of interfaces that > we > need to > specify. We should probably encourage contributions proposing > the composite network elements and perhaps discuss these contributions in > a > teleconference (maybe not the next, but the one after that). > > - Jaakko

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 06 Apr '00

06 Apr '00

Hi, All: Jakko may be right, but who knows. We may or may not define "intra-network" as additional term in our standard. I just took Paul's suggestion of "intra-network" something like - "a user remains within a given network while roaming can be termed as intra-network roaming." For example, a wireless LAN may have many point of attachments while the mobile user may move from one point of attachment to another of a given LAN, but it is still the same network. In this situation, the mobility of the user can be termed as the "intra-network" roaming. Of course, there will be intra-domain, inter-domain roaming. Similarly, there can be intra-zone and inter-zone roaming. In the same token, there can be intra-network and inter-network roaming. Contributions are there or underway to address all those issues. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, April 06, 2000 9:00 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Hi Paul & all, > > Paul, thanks for the clarification. I just have one point: If intra > network > in fact means intra-domain, then maybe we should call it intra-domain, not > intra-network. This is just to avoid any unnecessary new definitions. > > - Jaakko

1 0

Re: Third party initiated pause and rerouting, share with voice, etc.
by Francois Audet 06 Apr '00

06 Apr '00

> When we agreed on the Annex F SET device way of third party > initiated pause > and re-routing (FACILITY message with empty FastStart structure), I > mentioned that this should not be limited to Annex F devices > but should of > course also be possible for non-Annex F H.323 devices that support > fastStart. This possibility should be added to 8.4.6 of H.323. Especially since we do it already in 9.10 for voice-to-fax switching. I'll bring up a contribution on it in Osaka.

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 06 Apr '00

06 Apr '00

Hi, Everyone: Contributions are there or are underway in explaining the things. I am not sure whether the explanation provided by Jakko is clarifying all logical steps that I have mentioned. Let us see the contributions in explaining the things. H.323 has building blocks: zone and domain (adm). A zone may have one or many networks. A domain may have one or many zones. A domain may be home or foreign (visiting/visited/target) from mobile user point of view. Similarly, a zone can be home of foreign (visiting/visited/target) from mobile user point of view. In the same token, a network can be home of foreign (visiting/visited/target) from mobile user point of view. With respect to VLF, it is an entity already defined. Its function is well defined. Where can it be located? It is primarily an implementation issue (not protocol issue). Let contributions explain this. If someone wants to co-locate it with the GK, it is fine. If not, .... then what? Similar is the case with HLF. We will go from Figures 1, 2, 3, ... and so on of Nokia's contribution MD-011. Again, let us not mandate anything beforehand. let contributions explain pros and cons and we will go from there. Let us not be afraid of explaining the things in contributions. Hope this will further clarify the things. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, April 06, 2000 3:40 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Hi all, > > Comments to Radhika's posting below... > > Hi, Everyone: > > We are again not in sink what is going on with respect to progress of our > work. Let me try again. > > That is just what I was trying to say... > > > We have talked about Nokia's contribution MD-011. We have taught that this > provides a reference to start with. In that contribution, we have Figure > 1: > Intra-zone all H.323 scenario. We have decided that we will go one step at > a > time. > First of all the scenario is called all-H.323 scenario. The figures just > try > to explain what kind of call models that scenario involves. What we have > decided is to go one scenario at a time (not one "call model" at a time). > Furthermore, it was evident in the last teleconference that the cases > illustrated in the figures were not adequate and they need to be enhanced. > > > Now what does this Figure 1 provides us? We are NOT sure unless we explain > in detail what this scenario means to us. We cannot go to the next step > unless we analyze what the scenario of Figure 1 provides us. It may or may > not provide new insights from H.323 mobility point of view, but it is our > starting point. We have to complete it first before we go for the next > step. > In this simple case, a mobile entity will move from its home network to a > foreign network. This also requires mobility management: Change in network > point of attachment and its possible impact in H.323 system. > > This is just what I mean. What do you mean by the above text? First of all > I > don't know what you mean by home and foreign network. Are you saying that > inside one zone there are multiple networks (so that moving from the home > network to a visited network is possible while all the time being located > inside the same zone)? You are right in saying that we need to analyze > this > call model also, but first we need to identify the different cases for the > user's location, i.e. both users at home domain, user-A at home domain & > user-B in a visited domain, etc. > Related to the above, we have already defined the terms Home > Administrative > Domain, Visited Administrative Domain and Serving Administrative Domain in > the draft H.323 Annex H. I think that these definitions are very good > (thanks to Milo, you see that we do agree on some things once in a while > ;-) > and they clearly bind the subscription of a user (or a subscriber) to a > Domain. My opinion is that this means that the Administrative Domains are > the areas that divide the H.323 system into home and visited areas from > the > point of view of the user. In other words, I wouldn't necessarily even > define terms, such as, Home Zone or Home Gatekeeper, because the above > definitions already bind the home of a user to the whole domain, not a > particular zone. If we want to define the term Home Zone, I think it > should > mean ANY zone inside the Home Administrative Domain, similarly a > definition > for the Home Gatekeeper could be made. > Based on the above, we can assume that when a user is in his/her Home > Administrative Domain, the HLF that contains his/her information is also > inside that Domain and inter-domain communications are not needed for the > Mobility Management of that user. Similarly, if the user is in a Visited > Administrative Domain, inter-domain communications are needed for the > Serving Administrative Domain to contact the user's HLF. This will also > lead > to different location management cases for e.g. the intra-zone all-H.323 > call model. > > > Once we complete Figure 1, we will go for the next one: Figure 2 > Inter-Zone > all H.323 scenario. Of course, this is a complicated one to provide better > scenario for mobility management: Change in network point attachment + > Change in zone (logical) point of attachment as well. > > I think that this is a good way for an individual to work, but personally > I > would like to see contributions that address more of these call models at > a > time. We can, of course, deal with the contributions in the order that > Radhika is proposing, I have nothing against that. > > A side note: We have defined VLF and HLF. VLF may be assumed to be > co-located within the GK. But let people explain the interactions > including > VLF and HLF the way they prefer in their contributions. The contributions > themselves will justify how VLF and HLF should perform their functions. > Let > us not mandate anything beforehand unless things are explained in the > contributions. > > One thing I would like to ask the ad hoc group members, is that should we > assume at this point that the VLF is co-located with the gatekeeper (as a > "composite network element" illustrated in Figure 3 of the draft H.323 > Annex > H). I think this could be a good assumption in the first version of Annex > H, > because it seems that most of us are thinking that way already. It would > only mean that we wouldn't have to specify anything for the reference > point > E, but leave it open in the first version of the annex, similarly as was > done with reference point B in the H.225.0 Annex G. Other composite > network > elements could also be identified for the first version of the annex. I > think that this kind of grouping could conciderably simplify our work for > the first version by reducing the number of interfaces that we need to > specify. We should probably encourage contributions proposing the > composite > network elements and perhaps discuss these contributions in a > teleconference > (maybe not the next, but the one after that). > > - Jaakko

1 0

[H.323 mobility]: annoying large attachments
by Stephan Wenger 06 Apr '00

06 Apr '00

Dear mobile folk, I don't question your right to use the reflector the way you do, but would it be possible that you establish a ftp site for your documents and just distribute pointers instead of files? This would yield two advantages: 1) There would be a well-known and easily accessible database for all mobile documents 2) People not so interested in mobile would not be annoyed by waiting minutes for the download of mobility documents in their hotel rooms when on travel. Please consider. Thanks. Stephan

1 0

[Mob] and 3GPP
by Michaely, Boaz 06 Apr '00

06 Apr '00

Hi everyone, I am not yet completely up to speed with our progress, but would it be wrong to state we are not moving at light speed ?... I wonder if there should not be a stronger linkage between SG16 mobility work and the 3GPP plans ? By the time we are done, it is very likely that H323 mobility work will be deployed in the wireless networks before the wireline (if at all). I will be attending a 3G drafting session next week in Helsinki (joint session of SA2 and CN). (Thanks to Ed. Martinez for pointing to this meeting) Is anyone else planning to be there too ? Best regards, Boaz Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44 SMS: 9723625844(a)msg.pelephone.co.il <http://people.itu.int/~michaely> <mailto:boaz_michaely@comverse.com>

2 1

Re: Mob ad hoc group progress
by Jaakko Sundquist 06 Apr '00

06 Apr '00

Hi Paul & all, Paul, thanks for the clarification. I just have one point: If intra network in fact means intra-domain, then maybe we should call it intra-domain, not intra-network. This is just to avoid any unnecessary new definitions. - Jaakko

1 0

Re: Mob ad hoc group progress
by Guram Paul-LPG019 06 Apr '00

06 Apr '00

Hi mob group Interesting debate. Just to say that the following is my understanding of our next phase of work (please correct me if I am mistaken): Considering that, 1. All-H.323 scenario does not have any interworking gateways involved to other non H.323 networks, and we need to start on simple work first (the word Scenario is used as per Tiphon), 2. Intra network means pertaining to one single network. A single network consists of one administrative domain. One administrative domain may have one or more zones. We also have defined home and visited administrative domains, HLF,VLF, AuF, and now have an equal understanding of these terms, 3. Annex H deals with terminal and user and service mobility issues which we know inherently implies mobility management, we, I think, agreed to progress on from Figure 1 MD011 Intra-network all-H323 scenario and specify call establishment/release etc. procedures for all of the possible roaming combinations (some examples are outlined in Stephen Terrill's last email). This will naturally include specifying the mobility management functions/interfaces, perhaps stating possible locations of VLF etc., identifying functionality/interfaces not covered or not required in the existing architecture diagram, and such issues. So this scenario will be defined by us in its entirety in the coming weeks. Paul ---------- From: Jaakko Sundquist[SMTP:jaakko.sundquist@nokia.com] Reply To: Jaakko Sundquist Sent: 06 April 2000 09:40 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi all, Comments to Radhika's posting below... Hi, Everyone: We are again not in sink what is going on with respect to progress of our work. Let me try again. That is just what I was trying to say... We have talked about Nokia's contribution MD-011. We have taught that this provides a reference to start with. In that contribution, we have Figure 1: Intra-zone all H.323 scenario. We have decided that we will go one step at a time. First of all the scenario is called all-H.323 scenario. The figures just try to explain what kind of call models that scenario involves. What we have decided is to go one scenario at a time (not one "call model" at a time). Furthermore, it was evident in the last teleconference that the cases illustrated in the figures were not adequate and they need to be enhanced. Now what does this Figure 1 provides us? We are NOT sure unless we explain in detail what this scenario means to us. We cannot go to the next step unless we analyze what the scenario of Figure 1 provides us. It may or may not provide new insights from H.323 mobility point of view, but it is our starting point. We have to complete it first before we go for the next step. In this simple case, a mobile entity will move from its home network to a foreign network. This also requires mobility management: Change in network point of attachment and its possible impact in H.323 system. This is just what I mean. What do you mean by the above text? First of all I don't know what you mean by home and foreign network. Are you saying that inside one zone there are multiple networks (so that moving from the home network to a visited network is possible while all the time being located inside the same zone)? You are right in saying that we need to analyze this call model also, but first we need to identify the different cases for the user's location, i.e. both users at home domain, user-A at home domain & user-B in a visited domain, etc. Related to the above, we have already defined the terms Home Administrative Domain, Visited Administrative Domain and Serving Administrative Domain in the draft H.323 Annex H. I think that these definitions are very good (thanks to Milo, you see that we do agree on some things once in a while ;-) and they clearly bind the subscription of a user (or a subscriber) to a Domain. My opinion is that this means that the Administrative Domains are the areas that divide the H.323 system into home and visited areas from the point of view of the user. In other words, I wouldn't necessarily even define terms, such as, Home Zone or Home Gatekeeper, because the above definitions already bind the home of a user to the whole domain, not a particular zone. If we want to define the term Home Zone, I think it should mean ANY zone inside the Home Administrative Domain, similarly a definition for the Home Gatekeeper could be made. Based on the above, we can assume that when a user is in his/her Home Administrative Domain, the HLF that contains his/her information is also inside that Domain and inter-domain communications are not needed for the Mobility Management of that user. Similarly, if the user is in a Visited Administrative Domain, inter-domain communications are needed for the Serving Administrative Domain to contact the user's HLF. This will also lead to different location management cases for e.g. the intra-zone all-H.323 call model. Once we complete Figure 1, we will go for the next one: Figure 2 Inter-Zone all H.323 scenario. Of course, this is a complicated one to provide better scenario for mobility management: Change in network point attachment + Change in zone (logical) point of attachment as well. I think that this is a good way for an individual to work, but personally I would like to see contributions that address more of these call models at a time. We can, of course, deal with the contributions in the order that Radhika is proposing, I have nothing against that. A side note: We have defined VLF and HLF. VLF may be assumed to be co-located within the GK. But let people explain the interactions including VLF and HLF the way they prefer in their contributions. The contributions themselves will justify how VLF and HLF should perform their functions. Let us not mandate anything beforehand unless things are explained in the contributions. One thing I would like to ask the ad hoc group members, is that should we assume at this point that the VLF is co-located with the gatekeeper (as a "composite network element" illustrated in Figure 3 of the draft H.323 Annex H). I think this could be a good assumption in the first version of Annex H, because it seems that most of us are thinking that way already. It would only mean that we wouldn't have to specify anything for the reference point E, but leave it open in the first version of the annex, similarly as was done with reference point B in the H.225.0 Annex G. Other composite network elements could also be identified for the first version of the annex. I think that this kind of grouping could conciderably simplify our work for the first version by reducing the number of interfaces that we need to specify. We should probably encourage contributions proposing the composite network elements and perhaps discuss these contributions in a teleconference (maybe not the next, but the one after that). - Jaakko

1 0

AW: Third party initiated pause and rerouting, share with voice, etc.
by <Karl Klaghofer> 06 Apr '00

06 Apr '00

Francois, Your third bullet: When we agreed on the Annex F SET device way of third party initiated pause and re-routing (FACILITY message with empty FastStart structure), I mentioned that this should not be limited to Annex F devices but should of course also be possible for non-Annex F H.323 devices that support fastStart. This possibility should be added to 8.4.6 of H.323. Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] > Gesendet am: Donnerstag, 6. April 2000 02:54 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Third party initiated pause and rerouting, share with voice, > etc. > > Hi all, > > I spotted a number of issues concerning third party initiated pause and > rerouting, H.323 Annex F, the new "share with voice" capability in > H.323v4, and of course, everybody's favorite: fast start. > > * How do we do third party inititated pause and re-routing for a call > initiated with fast start for a non-Annex F endpoint? > * Reading H.323v4 suggest that the way to do this is sending the null > Terminal Capability Set in a tunnelled H.245 message, or alternatively in > a newly-created H.245 channel. This implies the master-slave > determination, the terminal capability set exchange, and the actual > opening of the media channels. > * However, is it allowed to use the Annex F procedures of sending a > nullChannel in a fastStart in any H.225.0 call control message in a > non-Annex F endpoint? Are these procedures of resending fastStart allowed > in H.323v4 without Annex F? > * Interestingly enough, the "share with voice" capability of section > 9.10 use the Annex F method of sending fastStart in a FACILITY message. I > can't see how we could allow this for switching between voice and fax, but > not for generic "third party pause and re-routing". > * Why is section 9.10 where it is? Shouldn't it be integrated in H.323 > Annex D for Fax? If not, there should at least be a reference to 9.10 in > Annex D for fax. A side note is that I am not shure what we gain by having > two methods of doing switchover from voice to fax (one with 2 always > opened channels for voice and fax as per Annex D, and the other involving > the replacing of the channel as per 9.10). > * Lastly, this "share with voice" procedure allows the receiving side > to modify the content of the proposed OpenLogicalChannel in fastStart > (i.e., it allows for reponding shareWithVoice=FALSE in return to an > incoming fastStart with shareWithVoice=TRUE). Technically, this is not > allowed in H.323 which mandates that the receiving side choose as is from > the list of OpenLogicalChannel in the fastStart. This point was mentioned > earlier on the list when discussing problems with payload size negotiation > with fast start. > > ----- > François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> > Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com > <http://www.nortelnetworks.com/> > >

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 06 Apr '00

06 Apr '00

Hi, Everyone: We are again not in sink what is going on with respect to progress of our work. Let me try again. We have talked about Nokia's contribution MD-011. We have taught that this provides a reference to start with. In that contribution, we have Figure 1: Intra-zone all H.323 scenario. We have decided that we will go one step at a time. Now what does this Figure 1 provides us? We are NOT sure unless we explain in detail what this scenario means to us. We cannot go to the next step unless we analyze what the scenario of Figure 1 provides us. It may or may not provide new insights from H.323 mobility point of view, but it is our starting point. We have to complete it first before we go for the next step. In this simple case, a mobile entity will move from its home network to a foreign network. This also requires mobility management: Change in network point of attachment and its possible impact in H.323 system. Once we complete Figure 1, we will go for the next one: Figure 2 Inter-Zone all H.323 scenario. Of course, this is a complicated one to provide better scenario for mobility management: Change in network point attachment + Change in zone (logical) point of attachment as well. Then Figure 3: Inter-Domain all H.323 scenario. And so on ... If we do not do this, we might again go into circle. I guess that this should be very clear to everyone. I would assume that people should bring contributions along this line: Figure 1, 2, ....etc. Let us not by-pass any step for sake of clarity and completeness. A side note: We have defined VLF and HLF. VLF may be assumed to be co-located within the GK. But let people explain the interactions including VLF and HLF the way they prefer in their contributions. The contributions themselves will justify how VLF and HLF should perform their functions. Let us not mandate anything beforehand unless things are explained in the contributions. I like to see all members provide their comments on this. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, April 05, 2000 6:06 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Hi all, > > Once again there seems to be quite a lot of confusion about the terms we > are > using. First of all, we did not make it altogether clear in the last > teleconference, what is meant by a scenario. My contribution on the issue > tried to group both the "call scenarios" and the "location management > scenarios" into one set of scenarios. We did notice during the > teleconference that this was not an adequate approach and now some of the > problems occuring in this email discussion reflect that. > For example, when Radhika is talking about starting with the intra-zone > scenario, I'm not quite sure what he is meaning. I understand that the > "call > scenario" he is talking about, is the one in which both terminals are > registered to the same gatekeeper. However, this "call scenario" in itself > does not really bring anything new to H.323 unless there is something that > we need to address with the "location management scenarios". Now, while > the > "call scenario" does indeed fall into the category of intra-zone > communications, the "location management scenario" for finding the address > of the B-subscriber of the call might not, i.e. the VLF and HLF that need > to > be contacted may not be located in the same zone or even domain. > Furthermore, we haven't even decided that the VLF and HLF should be a part > of any zone. I know that most of us actually think that the VLF is always > located with the gatekeeper, but so far we haven't made that decision and > certainly we haven't coupled the HLF functionality always with the > gatekeeper. Thus it is quite unclear what is meant by intra-zone "location > management scenarios" and I would suggest that we do not even try to > define > this term. Instead intra vs inter domain "location management scenarios" > make much more sence. > (Note that I'm using the terms "call scenario" and "location management > scenario" quite freely here. If we want to use such terms, they definitely > must be clearly defined.) > > Also, I would like to point out that talking about intra-zone, inter-zone, > etc. scenarios, is actually not what was originally meant by a scenario. > The > idea to introduce scenarios into the H.323 Mobility work came from Tiphon, > where 5 different scenarios are identified. These scenarios do not take > into > account, whether the call (or other connection) takes place inside one > zone > (intra-zone), between two zones (inter-zone) or between domains > (inter-domain). The scenarios in Tiphon simply state which network types > are > involved in the connection, e.g. Tiphon scenario 1 is the VoIP-to-SCN > scenario, Tiphon scenario 2 is the SCN-to-VoIP scenario, etc. These were > the > kind of scenarios I thought we were trying to identify in the last > teleconference. Of cource, each of this kind of scenarios may involve > calls > that are intra-zone, inter-zone or inter-domain calls, but we shouldn't > call > (no pun intended) these different call models as scenarios. > We have now chosen the all-H.323 scenario as the first one to examine > (although we didn't even know what it means). In my mind this means that: > * We only examine call cases, in which no gateways are included. > * We examine gatekeeper discovery, registration and location > updating > cases, in which the user is accessing the H.323 system either in his/her > home network (e.g. domain) or a visited network (e.g. domain). > * We examine call establishment and call release cases, in which the > A-subscriber is either in his/her home network (domain) or in a visited > network (domain). > * We examine call establishment and call release cases, in which the > B-subscriber is either in his/her home network (domain) or in a visited > network (domain). Note that the call can be intra-zone, inter-zone or > inter-domain irrespective of whether the B-subscriber is in home or > visited > network. > * We examine mid-call scenarios (e.g. some supplementary services), > in > which the user (either A- or B-subscriber) is either in his/her home > network > or in a visited network. > * In the context of H.323 Annex H we do not address the inteworking > functionalities (IWFs) between the HLF/VLF/AuF and some non-H.323 network, > unless some other document (such as H.246 Annex E) proposes additions to > H.323 Annex H. (Note that, when we start work on some other scenarios in > the > future, we probably will have to take the IWFs into account.) > > Other issues that need to be addressed are at least the definitions for > the > home/visited network/domain/zone/gatekeeper, because it seems to me that > some members are already using some of these terms in ways that already > point to certain solutions, on which we have not yet agreed. > > I will try to work out a suitable contribution for the next teleconference > to clarify these issues properly. If you have some comments to this mail, > please respond. I know that this is a long posting with quite a lot of > issues in it and I'm sure that I haven't explained myself too clearly in > all > parts of it, so please ask. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > -----Original Message----- > From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: 04. April 2000 15:31 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Mob ad hoc group progress > > Paul: > > Thanks for clarifications. > > In the last conf call, we even cannot complete the simple intra-zone > (intra-network, inter-network) scenarios first. You are right that we > should > concentrate on the scenarios (Registration procedures, Gatekeeper > discovery, > Location update, Call establishment, Mid-Call scenarios (e.g. > supplementary > services, user interaction, Call release). > > Definitely, we can go further: Inter-Zone (intra-domain) scenarios as well > if we can agree on the first one. AT&T contributions already contain many > of > those aspects. Hope to bring new contributions explaining further in both > scenarios. > > Best regards, > > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > > Sent: Sunday, April 02, 2000 3:52 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Mob ad hoc group progress > > > > Radhika, > > > > Conf call is for Annex H only as before...nothing has changed...change > can > > only take place when the group agrees. Please do not read into the > email > > more than what it says. I was only trying to highlight, in a high level > > report, the plight of Annex I since nothing much has moved in it, and it > > is > > an Annex which together with Annex H covers the mobility aspects. As > far > > as > > Annex E is concerned, the point was that the mapping was the work of > one > > individual or one company, thus could have errors or omissions (more > than > > likely)...again only highlighting to people to check out this mapping. > > > > Contributions for next conf call to be for All H.323 intra-network > > scenario > > for: > > Registration procedures, Gatekeeper discovery, Location > > update, Call establishment, Mid-Call scenarios (e.g. > > supplementary services, > > user interaction), Call release. Also contributions on > > any > > impacts on the already specified architecture in the light of the > present > > work are welcome. > > > > Paul > > > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > > Sent: 01 April 2000 00:00 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Mob ad hoc group progress > > > > Hi, Paul and Mobility Group: > > > > I like to see that it should be clarified via emails > > whether > > H.323 Annex I > > and H.246 Annex E will be a part of the conference call. > > My > > personal > > preference is not to discuss annexes I and E during the > > conference call > > although email discussions will be preferred. > > > > If Annex I and E are included in the conference call, I > > like > > to see the > > actual time in the agenda when these items will be > > discussed > > so that people > > can best use their time in joining the particular time > > slot > > for each Annex. > > > > The proposal is as follows: > > > > 1. The upcoming conference call to be dedicated for > H.323 > > Annex H. > > 2. Let both editors of H.323 Annex I and H.246 Annex E > > propose via emails > > whether any issues to addressed. > > 3. If annex I and E are included in the agenda of the > > upcoming conference > > call, I like to the time slots when these annexes will > be > > discussed so that > > people can join the particular time slots of interest. > > Alternatively, > > separate conference calls can be arranged for annexes I > > and > > E. > > 4. Are editors or any members of the mobility group sure > > what would be the > > scope of work (I guess that Annex E is stable for now - > > thanks to the > > editor) for those annexes? > > > > Paul: Would you please clarify what specific area that > we > > need to discuss > > for the next conference call for H.323 Annex H? My guess > > is > > that we may > > start with intra-zone communication first. I am planning > > to > > bring > > contribution(s) describing this for mobility management: > > Discovery, > > Registration, Location Updates, and Call Establishment. > > > > I would appreciate comments form all members. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > H.323 Ad Hoc Mobility Group > >

2 1

Re: Mob ad hoc group progress (ignore the previous mail)
by Jaakko Sundquist 06 Apr '00

06 Apr '00

My comments did not show too clearly in the last mail due to the wonderful M$ Outlook settings, so I'm resending this... Hi all, Comments to Radhika's posting below... > > Hi, Everyone: > > We are again not in sink what is going on with respect to > progress of our > work. Let me try again. That is just what I was trying to say... > > We have talked about Nokia's contribution MD-011. We have > taught that this > provides a reference to start with. In that contribution, we > have Figure 1: > Intra-zone all H.323 scenario. We have decided that we will > go one step at a > time. First of all the scenario is called all-H.323 scenario. The figures just try to explain what kind of call models that scenario involves. What we have decided is to go one scenario at a time (not one "call model" at a time). Furthermore, it was evident in the last teleconference that the cases illustrated in the figures were not adequate and they need to be enhanced. > > Now what does this Figure 1 provides us? We are NOT sure > unless we explain > in detail what this scenario means to us. We cannot go to the > next step > unless we analyze what the scenario of Figure 1 provides us. > It may or may > not provide new insights from H.323 mobility point of view, > but it is our > starting point. We have to complete it first before we go for > the next step. > In this simple case, a mobile entity will move from its home > network to a > foreign network. This also requires mobility management: > Change in network > point of attachment and its possible impact in H.323 system. > This is just what I mean. What do you mean by the above text? First of all I don't know what you mean by home and foreign network. Are you saying that inside one zone there are multiple networks (so that moving from the home network to a visited network is possible while all the time being located inside the same zone)? You are right in saying that we need to analyze this call model also, but first we need to identify the different cases for the user's location, i.e. both users at home domain, user-A at home domain & user-B in a visited domain, etc. Related to the above, we have already defined the terms Home Administrative Domain, Visited Administrative Domain and Serving Administrative Domain in the draft H.323 Annex H. I think that these definitions are very good (thanks to Milo, you see that we do agree on some things once in a while ;-) and they clearly bind the subscription of a user (or a subscriber) to a Domain. My opinion is that this means that the Administrative Domains are the areas that divide the H.323 system into home and visited areas from the point of view of the user. In other words, I wouldn't necessarily even define terms, such as, Home Zone or Home Gatekeeper, because the above definitions already bind the home of a user to the whole domain, not a particular zone. If we want to define the term Home Zone, I think it should mean ANY zone inside the Home Administrative Domain, similarly a definition for the Home Gatekeeper could be made. Based on the above, we can assume that when a user is in his/her Home Administrative Domain, the HLF that contains his/her information is also inside that Domain and inter-domain communications are not needed for the Mobility Management of that user. Similarly, if the user is in a Visited Administrative Domain, inter-domain communications are needed for the Serving Administrative Domain to contact the user's HLF. This will also lead to different location management cases for e.g. the intra-zone all-H.323 call model. > > Once we complete Figure 1, we will go for the next one: > Figure 2 Inter-Zone > all H.323 scenario. Of course, this is a complicated one to > provide better > scenario for mobility management: Change in network point attachment + > Change in zone (logical) point of attachment as well. > I think that this is a good way for an individual to work, but personally I would like to see contributions that address more of these call models at a time. We can, of course, deal with the contributions in the order that Radhika is proposing, I have nothing against that. > A side note: We have defined VLF and HLF. VLF may be assumed to be > co-located within the GK. But let people explain the > interactions including > VLF and HLF the way they prefer in their contributions. The > contributions > themselves will justify how VLF and HLF should perform their > functions. Let > us not mandate anything beforehand unless things are explained in the > contributions. > One thing I would like to ask the ad hoc group members, is that should we assume at this point that the VLF is co-located with the gatekeeper (as a "composite network element" illustrated in Figure 3 of the draft H.323 Annex H). I think this could be a good assumption in the first version of Annex H, because it seems that most of us are thinking that way already. It would only mean that we wouldn't have to specify anything for the reference point E, but leave it open in the first version of the annex, similarly as was done with reference point B in the H.225.0 Annex G. Other composite network elements could also be identified for the first version of the annex. I think that this kind of grouping could conciderably simplify our work for the first version by reducing the number of interfaces that we need to specify. We should probably encourage contributions proposing the composite network elements and perhaps discuss these contributions in a teleconference (maybe not the next, but the one after that). - Jaakko

1 0

Re: Mob ad hoc group progress
by Jaakko Sundquist 06 Apr '00

06 Apr '00

Hi all, Comments to Radhika's posting below... Hi, Everyone: We are again not in sink what is going on with respect to progress of our work. Let me try again. That is just what I was trying to say... We have talked about Nokia's contribution MD-011. We have taught that this provides a reference to start with. In that contribution, we have Figure 1: Intra-zone all H.323 scenario. We have decided that we will go one step at a time. First of all the scenario is called all-H.323 scenario. The figures just try to explain what kind of call models that scenario involves. What we have decided is to go one scenario at a time (not one "call model" at a time). Furthermore, it was evident in the last teleconference that the cases illustrated in the figures were not adequate and they need to be enhanced. Now what does this Figure 1 provides us? We are NOT sure unless we explain in detail what this scenario means to us. We cannot go to the next step unless we analyze what the scenario of Figure 1 provides us. It may or may not provide new insights from H.323 mobility point of view, but it is our starting point. We have to complete it first before we go for the next step. In this simple case, a mobile entity will move from its home network to a foreign network. This also requires mobility management: Change in network point of attachment and its possible impact in H.323 system. This is just what I mean. What do you mean by the above text? First of all I don't know what you mean by home and foreign network. Are you saying that inside one zone there are multiple networks (so that moving from the home network to a visited network is possible while all the time being located inside the same zone)? You are right in saying that we need to analyze this call model also, but first we need to identify the different cases for the user's location, i.e. both users at home domain, user-A at home domain & user-B in a visited domain, etc. Related to the above, we have already defined the terms Home Administrative Domain, Visited Administrative Domain and Serving Administrative Domain in the draft H.323 Annex H. I think that these definitions are very good (thanks to Milo, you see that we do agree on some things once in a while ;-) and they clearly bind the subscription of a user (or a subscriber) to a Domain. My opinion is that this means that the Administrative Domains are the areas that divide the H.323 system into home and visited areas from the point of view of the user. In other words, I wouldn't necessarily even define terms, such as, Home Zone or Home Gatekeeper, because the above definitions already bind the home of a user to the whole domain, not a particular zone. If we want to define the term Home Zone, I think it should mean ANY zone inside the Home Administrative Domain, similarly a definition for the Home Gatekeeper could be made. Based on the above, we can assume that when a user is in his/her Home Administrative Domain, the HLF that contains his/her information is also inside that Domain and inter-domain communications are not needed for the Mobility Management of that user. Similarly, if the user is in a Visited Administrative Domain, inter-domain communications are needed for the Serving Administrative Domain to contact the user's HLF. This will also lead to different location management cases for e.g. the intra-zone all-H.323 call model. Once we complete Figure 1, we will go for the next one: Figure 2 Inter-Zone all H.323 scenario. Of course, this is a complicated one to provide better scenario for mobility management: Change in network point attachment + Change in zone (logical) point of attachment as well. I think that this is a good way for an individual to work, but personally I would like to see contributions that address more of these call models at a time. We can, of course, deal with the contributions in the order that Radhika is proposing, I have nothing against that. A side note: We have defined VLF and HLF. VLF may be assumed to be co-located within the GK. But let people explain the interactions including VLF and HLF the way they prefer in their contributions. The contributions themselves will justify how VLF and HLF should perform their functions. Let us not mandate anything beforehand unless things are explained in the contributions. One thing I would like to ask the ad hoc group members, is that should we assume at this point that the VLF is co-located with the gatekeeper (as a "composite network element" illustrated in Figure 3 of the draft H.323 Annex H). I think this could be a good assumption in the first version of Annex H, because it seems that most of us are thinking that way already. It would only mean that we wouldn't have to specify anything for the reference point E, but leave it open in the first version of the annex, similarly as was done with reference point B in the H.225.0 Annex G. Other composite network elements could also be identified for the first version of the annex. I think that this kind of grouping could conciderably simplify our work for the first version by reducing the number of interfaces that we need to specify. We should probably encourage contributions proposing the composite network elements and perhaps discuss these contributions in a teleconference (maybe not the next, but the one after that). - Jaakko

1 0

Third party initiated pause and rerouting, share with voice, etc.
by Francois Audet 05 Apr '00

05 Apr '00

Hi all, I spotted a number of issues concerning third party initiated pause and rerouting, H.323 Annex F, the new "share with voice" capability in H.323v4, and of course, everybody's favorite: fast start. * How do we do third party inititated pause and re-routing for a call initiated with fast start for a non-Annex F endpoint? * Reading H.323v4 suggest that the way to do this is sending the null Terminal Capability Set in a tunnelled H.245 message, or alternatively in a newly-created H.245 channel. This implies the master-slave determination, the terminal capability set exchange, and the actual opening of the media channels. * However, is it allowed to use the Annex F procedures of sending a nullChannel in a fastStart in any H.225.0 call control message in a non-Annex F endpoint? Are these procedures of resending fastStart allowed in H.323v4 without Annex F? * Interestingly enough, the "share with voice" capability of section 9.10 use the Annex F method of sending fastStart in a FACILITY message. I can't see how we could allow this for switching between voice and fax, but not for generic "third party pause and re-routing". * Why is section 9.10 where it is? Shouldn't it be integrated in H.323 Annex D for Fax? If not, there should at least be a reference to 9.10 in Annex D for fax. A side note is that I am not shure what we gain by having two methods of doing switchover from voice to fax (one with 2 always opened channels for voice and fax as per Annex D, and the other involving the replacing of the channel as per 9.10). * Lastly, this "share with voice" procedure allows the receiving side to modify the content of the proposed OpenLogicalChannel in fastStart (i.e., it allows for reponding shareWithVoice=FALSE in return to an incoming fastStart with shareWithVoice=TRUE). Technically, this is not allowed in H.323 which mandates that the receiving side choose as is from the list of OpenLogicalChannel in the fastStart. This point was mentioned earlier on the list when discussing problems with payload size negotiation with fast start. ----- François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 <http://www.nortelnetworks.com/> http://www.NortelNetworks.com

1 0

Re: Your Business Achievements
by bilco90＠VENTURE.CO.JP 05 Apr '00

05 Apr '00

1 0

Re: Mob ad hoc group progress
by Jaakko Sundquist 05 Apr '00

05 Apr '00

Hi all, Once again there seems to be quite a lot of confusion about the terms we are using. First of all, we did not make it altogether clear in the last teleconference, what is meant by a scenario. My contribution on the issue tried to group both the "call scenarios" and the "location management scenarios" into one set of scenarios. We did notice during the teleconference that this was not an adequate approach and now some of the problems occuring in this email discussion reflect that. For example, when Radhika is talking about starting with the intra-zone scenario, I'm not quite sure what he is meaning. I understand that the "call scenario" he is talking about, is the one in which both terminals are registered to the same gatekeeper. However, this "call scenario" in itself does not really bring anything new to H.323 unless there is something that we need to address with the "location management scenarios". Now, while the "call scenario" does indeed fall into the category of intra-zone communications, the "location management scenario" for finding the address of the B-subscriber of the call might not, i.e. the VLF and HLF that need to be contacted may not be located in the same zone or even domain. Furthermore, we haven't even decided that the VLF and HLF should be a part of any zone. I know that most of us actually think that the VLF is always located with the gatekeeper, but so far we haven't made that decision and certainly we haven't coupled the HLF functionality always with the gatekeeper. Thus it is quite unclear what is meant by intra-zone "location management scenarios" and I would suggest that we do not even try to define this term. Instead intra vs inter domain "location management scenarios" make much more sence. (Note that I'm using the terms "call scenario" and "location management scenario" quite freely here. If we want to use such terms, they definitely must be clearly defined.) Also, I would like to point out that talking about intra-zone, inter-zone, etc. scenarios, is actually not what was originally meant by a scenario. The idea to introduce scenarios into the H.323 Mobility work came from Tiphon, where 5 different scenarios are identified. These scenarios do not take into account, whether the call (or other connection) takes place inside one zone (intra-zone), between two zones (inter-zone) or between domains (inter-domain). The scenarios in Tiphon simply state which network types are involved in the connection, e.g. Tiphon scenario 1 is the VoIP-to-SCN scenario, Tiphon scenario 2 is the SCN-to-VoIP scenario, etc. These were the kind of scenarios I thought we were trying to identify in the last teleconference. Of cource, each of this kind of scenarios may involve calls that are intra-zone, inter-zone or inter-domain calls, but we shouldn't call (no pun intended) these different call models as scenarios. We have now chosen the all-H.323 scenario as the first one to examine (although we didn't even know what it means). In my mind this means that: * We only examine call cases, in which no gateways are included. * We examine gatekeeper discovery, registration and location updating cases, in which the user is accessing the H.323 system either in his/her home network (e.g. domain) or a visited network (e.g. domain). * We examine call establishment and call release cases, in which the A-subscriber is either in his/her home network (domain) or in a visited network (domain). * We examine call establishment and call release cases, in which the B-subscriber is either in his/her home network (domain) or in a visited network (domain). Note that the call can be intra-zone, inter-zone or inter-domain irrespective of whether the B-subscriber is in home or visited network. * We examine mid-call scenarios (e.g. some supplementary services), in which the user (either A- or B-subscriber) is either in his/her home network or in a visited network. * In the context of H.323 Annex H we do not address the inteworking functionalities (IWFs) between the HLF/VLF/AuF and some non-H.323 network, unless some other document (such as H.246 Annex E) proposes additions to H.323 Annex H. (Note that, when we start work on some other scenarios in the future, we probably will have to take the IWFs into account.) Other issues that need to be addressed are at least the definitions for the home/visited network/domain/zone/gatekeeper, because it seems to me that some members are already using some of these terms in ways that already point to certain solutions, on which we have not yet agreed. I will try to work out a suitable contribution for the next teleconference to clarify these issues properly. If you have some comments to this mail, please respond. I know that this is a long posting with quite a lot of issues in it and I'm sure that I haven't explained myself too clearly in all parts of it, so please ask. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ -----Original Message----- From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 04. April 2000 15:31 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Paul: Thanks for clarifications. In the last conf call, we even cannot complete the simple intra-zone (intra-network, inter-network) scenarios first. You are right that we should concentrate on the scenarios (Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction, Call release). Definitely, we can go further: Inter-Zone (intra-domain) scenarios as well if we can agree on the first one. AT&T contributions already contain many of those aspects. Hope to bring new contributions explaining further in both scenarios. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > Sent: Sunday, April 02, 2000 3:52 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Radhika, > > Conf call is for Annex H only as before...nothing has changed...change can > only take place when the group agrees. Please do not read into the email > more than what it says. I was only trying to highlight, in a high level > report, the plight of Annex I since nothing much has moved in it, and it > is > an Annex which together with Annex H covers the mobility aspects. As far > as > Annex E is concerned, the point was that the mapping was the work of one > individual or one company, thus could have errors or omissions (more than > likely)...again only highlighting to people to check out this mapping. > > Contributions for next conf call to be for All H.323 intra-network > scenario > for: > Registration procedures, Gatekeeper discovery, Location > update, Call establishment, Mid-Call scenarios (e.g. > supplementary services, > user interaction), Call release. Also contributions on > any > impacts on the already specified architecture in the light of the present > work are welcome. > > Paul > > > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: 01 April 2000 00:00 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Mob ad hoc group progress > > Hi, Paul and Mobility Group: > > I like to see that it should be clarified via emails > whether > H.323 Annex I > and H.246 Annex E will be a part of the conference call. > My > personal > preference is not to discuss annexes I and E during the > conference call > although email discussions will be preferred. > > If Annex I and E are included in the conference call, I > like > to see the > actual time in the agenda when these items will be > discussed > so that people > can best use their time in joining the particular time > slot > for each Annex. > > The proposal is as follows: > > 1. The upcoming conference call to be dedicated for H.323 > Annex H. > 2. Let both editors of H.323 Annex I and H.246 Annex E > propose via emails > whether any issues to addressed. > 3. If annex I and E are included in the agenda of the > upcoming conference > call, I like to the time slots when these annexes will be > discussed so that > people can join the particular time slots of interest. > Alternatively, > separate conference calls can be arranged for annexes I > and > E. > 4. Are editors or any members of the mobility group sure > what would be the > scope of work (I guess that Annex E is stable for now - > thanks to the > editor) for those annexes? > > Paul: Would you please clarify what specific area that we > need to discuss > for the next conference call for H.323 Annex H? My guess > is > that we may > start with intra-zone communication first. I am planning > to > bring > contribution(s) describing this for mobility management: > Discovery, > Registration, Location Updates, and Call Establishment. > > I would appreciate comments form all members. > > Best regards, > > Radhika R. Roy > AT&T > H.323 Ad Hoc Mobility Group >

1 0

Re: Force remote to start H.245 session?
by Paul Long 04 Apr '00

04 Apr '00

Chris, I think you see my point, then. Now that I think about it, an EP _is_ required to at least send its TCS, if it has not already, if it receives an H.245 request message. Specifically, it cannot send the TCSAck until it has sent its own TCS, according to the following: 8.2/H.323v3: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent." And then there's the following. I think it means that if an EP receives TCS without already having sent TCS itself, it shall do so now. Is that your understanding? 8.2/H.323v3: "An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure." So if an EP initiates H.245 procedures, the remote is forced to also perform H.245 procedures. Okay, that's what I was looking for. Maybe it just means that it has to perform the cap exchange. You know, both sides don't really need to initiate the MSD. It's enough that the side that first wanted to use H.245 procedures has performed it, so TCS alone is enough of a prelude to get the H.245 session up and running. Do you think this needs clarification text? Paul Long Smith Micro Software, Inc. -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Monday, April 03, 2000 8:00 AM To: Paul Long Subject: Re: Force remote to start H.245 session? Paul, First of all, sorry for the fact that this seems to be a week-old mail I'm finally responding to... I may have misunderstood, but I don't understand why this is necessary. If both endpoints have expressed willingness to use tunnelled H.245, why can an endpoint not simply start sending H.245 messages (of COURSE starting with TCS, and potentially tunnelled in purpose-built FACILITY messages) when it wishes to start a tunnelled H.245 session? I would have thought that would be a pretty clear indication of intent to start a tunnelled H.245 session! FACILITY/reason=startH245 is required for separate H.245 connections because an endpoint may not know an address at its interlocutor to use to initiate an H.245 connection. This problem doesn't exist in tunnelled H.245, so I see no necessity for the extra interpretation! We may want some extra text specifying behaviour at the start of an H.245 session, to ensure that the destination of the initial tunnelled H.245 message actually does something constructive (sends a TCS) rather than non-constructive (merely Acking the TCS it's been sent and not advancing anything useful). Regards, Chris

2 3

[Robustness] telecon -- final reminder April 6 -- 9AM EST USA
by Maureen Stillman 04 Apr '00

04 Apr '00

The next robustness teleconference will be held on Thursday, April 6 at 9AM EST USA. The number to call is: (613)688-2795 the passcode is 8689# You must enter the pound sign after the passcode. The agenda is: * Terry Anderson of Lucent has provided H.225 and H.245 state machines for us to review. * Randy Stewart and Qiaobing Xie of Motorola will join us to discuss SCTP and DDP and answer questions. * Discuss the SDL for the robustness procedure produced by Sasha Ruditsky of Radvision. This SDL is for the Geneva SG-16 document from the February 2000 meeting, document TD87 from WP2. SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt) DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt Please join us. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 04 Apr '00

04 Apr '00

Paul: Thanks for clarifications. In the last conf call, we even cannot complete the simple intra-zone (intra-network, inter-network) scenarios first. You are right that we should concentrate on the scenarios (Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction, Call release). Definitely, we can go further: Inter-Zone (intra-domain) scenarios as well if we can agree on the first one. AT&T contributions already contain many of those aspects. Hope to bring new contributions explaining further in both scenarios. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > Sent: Sunday, April 02, 2000 3:52 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc group progress > > Radhika, > > Conf call is for Annex H only as before...nothing has changed...change can > only take place when the group agrees. Please do not read into the email > more than what it says. I was only trying to highlight, in a high level > report, the plight of Annex I since nothing much has moved in it, and it > is > an Annex which together with Annex H covers the mobility aspects. As far > as > Annex E is concerned, the point was that the mapping was the work of one > individual or one company, thus could have errors or omissions (more than > likely)...again only highlighting to people to check out this mapping. > > Contributions for next conf call to be for All H.323 intra-network > scenario > for: > Registration procedures, Gatekeeper discovery, Location > update, Call establishment, Mid-Call scenarios (e.g. > supplementary services, > user interaction), Call release. Also contributions on > any > impacts on the already specified architecture in the light of the present > work are welcome. > > Paul > > > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: 01 April 2000 00:00 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Mob ad hoc group progress > > Hi, Paul and Mobility Group: > > I like to see that it should be clarified via emails > whether > H.323 Annex I > and H.246 Annex E will be a part of the conference call. > My > personal > preference is not to discuss annexes I and E during the > conference call > although email discussions will be preferred. > > If Annex I and E are included in the conference call, I > like > to see the > actual time in the agenda when these items will be > discussed > so that people > can best use their time in joining the particular time > slot > for each Annex. > > The proposal is as follows: > > 1. The upcoming conference call to be dedicated for H.323 > Annex H. > 2. Let both editors of H.323 Annex I and H.246 Annex E > propose via emails > whether any issues to addressed. > 3. If annex I and E are included in the agenda of the > upcoming conference > call, I like to the time slots when these annexes will be > discussed so that > people can join the particular time slots of interest. > Alternatively, > separate conference calls can be arranged for annexes I > and > E. > 4. Are editors or any members of the mobility group sure > what would be the > scope of work (I guess that Annex E is stable for now - > thanks to the > editor) for those annexes? > > Paul: Would you please clarify what specific area that we > need to discuss > for the next conference call for H.323 Annex H? My guess > is > that we may > start with intra-zone communication first. I am planning > to > bring > contribution(s) describing this for mobility management: > Discovery, > Registration, Location Updates, and Call Establishment. > > I would appreciate comments form all members. > > Best regards, > > Radhika R. Roy > AT&T > H.323 Ad Hoc Mobility Group >

1 0

Updated notice of the Osaka meeting
by Sakae OKUBO 04 Apr '00

04 Apr '00

/// Corrections to the notice dated Tue, 4 Apr 2000 01:35:36 +0900 /// /// /// /// 1) Dale Skran's new coordinates /// /// Sonus Networks /// /// 4400 Route 9 South /// /// Suite 1000 /// /// Freehold, NJ 07748 /// /// +1 732 409 5107 (voice) /// /// +1 732 409 5172 (fax) /// /// dskran(a)sonusnet.com /// /// /// /// 2) 1. Date /// /// /// /// 15 (Monday) - 19 (Friday) March 2000 ==> 15-19 May 2000 /// /// /// /// 3) 3. 3) - Issue white papers for: /// /// H.450.8 ==> H.450.9 /// /// /// /// 4) Attached application form, deadline for registration /// /// 24 May ==> 24 April /// /// /// /// An updated text and an updated attachment follow. Apologies /// /// for demanding your error resilient reading and thanks for /// /// kind advice from several members. /// To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. M. Wada, KDD De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 3204 8194 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Sonus Networks 4400 Route 9 South Suite 1000 Freehold, NJ 07748 USA Tel: +1 732 409 5107 Fax: +1 732 409 5172 E-mail: dskran(a)sonusnet.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ---------------------------------------------------------- Subject: Notice of Q.12-14/16 Rapporteur Meeting in Osaka Date: 4 April 2000 ---------------------------------------------------------- Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Osaka, Japan at the kind invitation of Group of Interested Organizations in Japan. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 15 (Monday) - 19 (Friday) May 2000 starting at 9:00 on the first day closing at 18:00 on the final day 2. Venue ^^^^^^^^ Osaka International Convention Center 5-3-51 Nakanoshima, Kita-ku Osaka-shi, 530-0005 Tel: +81 6 4803 5555 Fax: +81 6 4803 5620 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Issue white papers for: * H.323 V4 * H.225.0 V4 * H.323 Annex J * H.323 Annex K * H.323 Annex L * H.323 Annex M.1 and M.2 * H.450.9 [may have been issued already] - Progress work for: * H.323 Annex N (QoS) * H.323 Annex H (Mobility) * H.323 Annex I (Error prone channels) * More robust operations * H.225.0 Annex G V2 * T.38-like protocol for modems & related H.323 signaling * H.450.x new recommendations * SS7 interworking 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Issue white papers for: * H.235 V2 * H.245 V7 * H.248 Annex F * H.248 Annex G * H.248 Annex H * H.248 Annex I * H.248 Annex J * H.248 Annex K * H.246 Annex E - Progress work for: * H.246 Annex D * H.248 V2 * other new items that may arise (e.g., new packages for H.248) 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 5 May (Friday) /// /// Distribution of the document: by 8 May (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 5 May (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Osaka, 15-19 May 2000 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (8 October or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0005_Osa directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring their laptop and 10BASE-T cord along. 6) The copying service is very limited and expensive at the meeting site. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0005_San/Info_ITU-T_Osaka_r1.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 24 April: Ms. Noriko Hosokawa Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: nonko(a)giti.waseda.ac.jp Tel & Fax: +81 3 5286 9863 AND advise Rapporteurs of your attendance by e-mail: To: okubo(a)giti.or.jp, dskran(a)sonusnet.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Osaka meeting registration Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting together with the meeting registration. Special room rate is 12,600 Yen (single) or 18,900 Yen (twin room, single use) per night including breakfast, service charge, local tax and consumption taxes. The block reservation is held until 24 April. 8. Meeting Fee ^^^^^^^^^^^^^^ To support the meeting organization, about 20,000 Yen meeting fee is collected by the secretariat (exact amount will be announced later). We are looking forward to meeting with you in Osaka. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0

AW: Correction to the notice of Osaka meeting
by <Karl Klaghofer> 04 Apr '00

04 Apr '00

Dear Mr. Okubo, There is a small typo in section 3) of the Q.13/16 Topics for the meeting ".... - Issue white papers for: ...... * H.450.8 [may have been issued already] ...." This should instead read H.450.9 Call Completion (H.450.8 is the Names Suppl Service and has already been decided in Geneva), Regards, Karl Klaghofer Siemens karl.klaghofer(a)icn.siemens.de

1 0

Correction to the notice of Osaka meeting
by Sakae OKUBO 03 Apr '00

03 Apr '00

/// Correction to the notice posted Tue, 4 Apr 2000 01:35:36 +0900 /// /// /// /// 1. Date /// /// /// /// 15 (Monday) - 19 (Friday) March 2000 ==> 15-19 May 2000 /// To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. M. Wada, KDD De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 3204 8194 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Sonusnet USA Tel: +1 732 972 2653 Fax: +1 732 972 6389 E-mail: dskran(a)sonusnet.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ---------------------------------------------------------- Subject: Notice of Q.12-14/16 Rapporteur Meeting in Osaka Date: 4 April 2000 ---------------------------------------------------------- Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Osaka, Japan at the kind invitation of Group of Interested Organizations in Japan. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 15 (Monday) - 19 (Friday) May 2000 starting at 9:00 on the first day closing at 18:00 on the final day 2. Venue ^^^^^^^^ Osaka International Convention Center 5-3-51 Nakanoshima, Kita-ku Osaka-shi, 530-0005 Tel: +81 6 4803 5555 Fax: +81 6 4803 5620 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Issue white papers for: * H.323 V4 * H.225.0 V4 * H.323 Annex J * H.323 Annex K * H.323 Annex L * H.323 Annex M.1 and M.2 * H.450.8 [may have been issued already] - Progress work for: * H.323 Annex N (QoS) * H.323 Annex H (Mobility) * H.323 Annex I (Error prone channels) * More robust operations * H.225.0 Annex G V2 * T.38-like protocol for modems & related H.323 signaling * H.450.x new recommendations * SS7 interworking 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Issue white papers for: * H.235 V2 * H.245 V7 * H.248 Annex F * H.248 Annex G * H.248 Annex H * H.248 Annex I * H.248 Annex J * H.248 Annex K * H.246 Annex E - Progress work for: * H.246 Annex D * H.248 V2 * other new items that may arise (e.g., new packages for H.248) 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 5 May (Friday) /// /// Distribution of the document: by 8 May (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 5 May (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Osaka, 15-19 May 2000 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (8 October or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0005_Osa directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring their laptop and 10BASE-T cord along. 6) The copying service is very limited and expensive at the meeting site. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0005_San/Information_ITU-T_Osaka.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 24 April: Ms. Noriko Hosokawa Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: nonko(a)giti.waseda.ac.jp Tel & Fax: +81 3 5286 9863 AND advise Rapporteurs of your attendance by e-mail: To: okubo(a)giti.or.jp, dskran(a)sonusnet.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Osaka meeting registration Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting together with the meeting registration. Special room rate is 12,600 Yen (single) or 18,900 Yen (twin room, single use) per night including breakfast, service charge, local tax and consumption taxes. The block reservation is held until 24 April. 8. Meeting Fee ^^^^^^^^^^^^^^ To support the meeting organization, about 20,000 Yen meeting fee is collected by the secretariat (exact amount will be announced later). We are looking forward to meeting with you in Osaka. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0