- sg16-avd - lists.packetizer.com

SupportedProtocol & SupportedPrefix in RAS
by 武井克明 09 Apr '00

09 Apr '00

Hi all, I am currently implementing a gatekeeper that supported only E.164 alias. H.323-ID is not supported in the current version. So I have a question. I don't enough understand the meaning of SupportedProtocol included the GatewayInfo in the EndpointType InformationElement. And the meaning of supportedPrefixes included VoiceCaps, T120OnlyCaps, H323Caps and so on. Please let me know, if anybody understand it. Regards, Katsuaki Takei $$$ Katsuaki Takei OKI Electric Industry … [View More]

2 1

Re: H.323 Mobility Contribution Numbers
by Guram Paul-LPG019 09 Apr '00

09 Apr '00

Radhika Your contributions numbers are MD-017 ND MD-018. Can you please load them onto the ftp site. Senthil Please arrange as before the conference bridge for 17 April, again at 8 a.m. PST. Thanks. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 07 April 2000 15:27 To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 Mobility Contribution Numbers … [View More]

1 0

Re: H.323 Mobility - Annex I
by Roy, Radhika R, ALARC 07 Apr '00

07 Apr '00

Hi, Adam: It is a very good news. I would suggest to get an APC number from Mr. OKUBO. If you could upload it earlier, we would appreciate it. In fact, we have been looking for contribution for Annex I. I also draw the attention of Paul Guram related to this. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Adam Li [SMTP:adamli@ICSL.UCLA.EDU] > Sent: Thursday, April 06, 2000 10:19 PM > To: ITU-… [View More]

2 1

[Robustness] Use of SCTP and DDP
by Terry L Anderson 07 Apr '00

07 Apr '00

Following our discussion yesterday... If we decide to go with SCTP in our solution we might try the following: Robust-capable elements will use SCTP for all signaling (including H.225/RAS, call signaling, H.245 call control signaling, etc.) with other robust-capable elements if they decide to use robust procedures. This transport recovers from certain IP transport failures with no H.323-level procedures. Recovery from element failures requires secondary servers that can assume the lost role. … [View More] Secondary servers can be designated for each element but the secondary server requires call state information. Sharing/synchronizing this information is outside the scope of the current version of the recommendation, but it is anticipated that mechanisms will be specified in future versions of the recommendation. One mechanism under consideration is DDP (which is an internet draft, but not an IETF standard at this time) and implementors of robust procedures might consider implementing DDP until a mechanism is specified. A mechanism like DDP addresses - sychronization of state information - reestablishment of application-layer connection to new server - reliable delivery of messages to one of the pool of servers *** this sort of forward reference to a non-standard permitted in an ITU recommendation? An alternative procedure for reestablishment of the connection is *** include a D-460-like description of reestablishing connections to elements that have shared state *** Sharing state information between the primary server and the secondary servers is outside the scope of the current version of this recommendation. *** the idea is to provide a solution ONLY for state-preserving server groups (ala RadVision's original proposal) rather than solve the more general case (as I previously urged) since DDP (or a solution like it) will make such server groups more practical to implement in the future. If we create our own application layer solution to the non-state perserving server now, we'll have to maintain it even after DDP is available. The above procedures allow for recovery for H.323 elements that require only packet network connections (all except endpoints, including gatekeeper, MCU, media gateway controllers, *** can H.248 be transported on SCTP? *** and border elements). *** is SCTP compatible with other packet networks or only IP. Does its use give us an IP-only solution? If so, is this acceptible in H.323? *** Most endpoints have connections that are not to packet-based networks (e.g, PSTN, terminal keyboard & screen, etc.). These connections cannot be recovered using STCP and DDP. These procedure do not support recovery if these connections are lost, but even with endpoints the procedures allow for recovery of packet-based connections, allowing the maintenance of the call unless the non-packet connection or local call state is lost. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla [View Less]

1 0

H.323 Mobility Contribution Numbers
by Roy, Radhika R, ALARC 07 Apr '00

07 Apr '00

Paul: Please provide me the numbers for the following two contributions to be submitted in the upcoming ad hoc mobility conf call: 1. H.323 Mobile Communications Environments and Intra-Zone Mobility Management 2. H.323 Inter-Zone Mobility Management Best regards, Radhika R. Roy AT&T

1 0

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

07 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:… [View More]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 [View Less]

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 … [View More]

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 … [View More]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 > > > > [View Less]

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 … [View More]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 [View Less]

1 0