Hi, Tom and All: You might be right. That is why, we need to bring contributions that provide solutions. AT&T has proposed a solution. I think that other companies will also do the same to make the things clear from the conceptual phase to the solution phase. For example, Nortel can also bring contributions along the line that you are envisioning. In the last meeting, Intel brought an interesting proposal too. I guess that Intel might have a product similar to their proposal. That is why, we are discussing whether a separate annex may be good to address that limited scope. We also welcome that any vendors that have products solving mobility in the context of H.323 should bring contributions. Let us see the proposed solutions. It is very difficult to debate in the conceptual phase. That is, the first priority is to bring solutions on the table instead of debating each other in the conceptual phase. My personal feeling is that H.323 has not developed the backend services protocol yet. Once we understand this, we can separate the problems into two parts: 1. The protocol among the H.323 entities (e.g., Terminals, GKs, MCUs, GWs), and 2. The protocol between the H.323 entities and the backend servers. So, there are two step process in H.323 for protocol development. At present, the existing H.323 standard has defined the first protocol only (i.e., protocol among H.323 entities). I see that TD-39 (Security Support for Backend Services and Mobility in H.323) shows a very clever way to define RADIUS as the backend protocol between the GK and BES for security even for mobile users. Similarly, LDAP can also be used as the backend services protocol between the GK and the directory server. So, there are many alternatives to do that. AT&T proposal also recognizes this problem. As a result, the backend protocol between the GK and the HLF/VLF has not yet been defined. We might use any existing protocols between the GK and the HLF/VLF in a similar way what has been proposed in TD-39. Personally, I do not see a problem. By the way, what is HLF/VLF anyway? Is not the user profiles with some alias addresses and some other user defined parameters? What is special about this that we have break the fundamental architecture and protocol of H.323? Hope this email will clarify some of your concerns. Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Friday, November 05, 1999 11:17 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H323 mobility: Summary of discussion
I think a basic point in this discussion is that mobility is "bigger than" H.323 and already has well-established architectural underpinnings. It's all very well to talk about an H.323 solution which we could then adapt, but we would more likely end up with an H.323-only solution as a result. The concern then would be whether vendors saw sufficient opportunity in building to this market, compared with the general market for mobility products.