Once again, hi, Radhika, Ed + all See my comments below... Hi, Jaakko, Ed, and All: I hope that Jaakko will get this mail while he is in his office (Thanks Jaakko - you have reminded us the time difference)! [Jaakko:] You caught me just in time. Please note the following: 1. Zone and domain are well defined in H.323. [Jaakko:] Yes, they are defined. 2. We have to work for mobility solution in a way that fits very well that already exists in H.323. [Jaakko:] Agreed. 3. We can invent many things if we need to solve mobility problems only when we think that those functions are NOT covered in existing H.323 standard. [Jaakko:] Yes. 4. If mobility problems can be solved using the concept of "zones" and "domains," I would assume that it would be a big mile stone so far the continuity of H.323 is concerned. That is, as Ed pointed out, H.323 mobility problem is NOT a rocket science. We have to remember that we are working in the framework of already existing H.323 standard architecture. We have to relate our solution in the context of existing H.323 standard. In other words, we CANNOT change the fundamental concept of existing H.323 standards just because we are addressing mobility. [Jaakko:] Yes, of course. I'm not arguing against that. I guess you are referring to the Location Area discussion here. The LA concept is really merely a scaling issue, you could of course handle paging (I'm assuming that we will need the paging procedure) based on zones, i.e. page every NPoA in a zone when a call arrives, but this might be quite limiting in some cases (the zone may be needlessly big or very small). I do not think that we need to change any fundamental concepts of H.323, if we introduce the LA concept. 5. I do not understand what benefits we are gaining adding more "terminologies" like "AREA {home, foreign, etc}" while the "zone" and "domain" are already well defined in H.323. My personal view is that we should FIRST try to solve H.323 mobility problems within the context of "zone" and "domain" as far as practicable. I would argue that zone and domain are good enough to serve this purpose for now. (Pl. also see AT&T's and Motorola's contributions.) [Jaakko:] As I already said, I did not intent to define the terms: home area and visited area. I was just trying to illustrate the point I was making about not having the Home/visited zone terms defined yet. 6. With respect to your comments that it appears that every GK will have HLF and VLF function, I would say that every GK will have the access to the HLF and VLF function. This capability for each GK has to be provided because of the fact that H.323 architecture is GK-centric. We do not have any choice because we are restricted by the H.323 architecture. [Jaakko:] I did not argue against this. The point is that if we identify a concept called the Home Zone, this already implies that each User has only one zone, in which he/she/it is not a "visiting user". I think this would be really restricting. 6.1 With respect to your question whether HLF/VLF can be distributive or centralized, having said (in item 5) that every GK should have access to HLF and VLF function, it is up to implementation whether HLF and VLF function can be centralized or distributive. Please see AT&T contributions submitted in Red Bank how we can implement these functions in both distributive and centralized environment. [Jaakko:] This is actually quite much the point I was making. By defining the Home Zone we would in my mind actually be pointing to the centralized model. 6.2 In an analogy of this HLF/VLF function, I can bring another function - Directory services. For example, H.323 assumes that all the address (e.g., alias, transport, network) are kept by each GK. H.323 does not answer how the address information is maintained by each GK. People are using LDAP directory server. The question is: whether that directory service is distributive or centralized? I guess that it can be done in both ways depending on implementation. [Jaakko:] My point exactly. I would like that all GKs inside the same Administrative Domain would be able to access the same HLF/VLF functionality. 6.3 In AT&T contribution, it is shown that it better to make VLF distributive (per GK) although HLF function can be made both distributive and centralized. Again, this is a matter of implementation. As mentioned in AT&T contribution, we also need to define a kind of backend protocol for VLF and HLF (something like similar to Siemens, Nokia and Intel's contribution - TD-39: Security Services for Backend Services and Mobility in H.323). [Jaakko:] I would assume that you can distribute the HLF/VLF functionalities inside the Administrative Domain as you like, but distributing them between the Domains would be difficult. Actually I think that the concept of Administrative Domain was introduced in H.323 for this kind of reasons. 7. Again, I, personally, do not rule our to re-examine the benfit of "AREA" (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. May be it is in the second step. [Jaakko:] I am just a bit afraid that if we leave this kind of a major mobility related concept out of the first phase thinking process, we will find it much more difficult to include the concept in the second phase (where I think we will need it). Furthermore, I'm not convinced that the LA concept would not be useful in the pure H.323 approach either. Hope that this email will clarify the things better. [Jaakko:] I think the main thing is that we got the discussion going on again. I'm kind of tired already, and I hope that I didn't mess things up too much in this mail. Best regards, Radhika Same to you, Jaakko