Hi, FX: Yes, it is OK for GK/BE <-> HLF/VLF (H.323 backend services protocol). But the questions remain for HLF <-> HLF. Thanks, Radhika R. Roy -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Thursday, August 03, 2000 11:04 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs roy, You're right, there is a new interface between the BE and the HLF, but it is in the "mobile domain", so I don't think it breaks anything. And we can have an HLF-HLF in a second step, but not today since we don't want to mandate anything new in the originationg domain. fx "Roy, Radhika R, ALCOO" <rrroy@ATT.COM> on 02/08/2000 03:46:53 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16@mailbag.cps.intel.com> To: ITU-SG16@mailbag.cps.intel.com cc: (bcc: Francois-Xavier DEROME/FR/ALCATEL) Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs Hi, FX: I like your approach that you have stated here in the email. With respect to the draft APC.xxx that you have proposed, I have few questions: 1. At present in H.323, there are mechanisms in place how the communications need to be made between the GKs or between the BEs or between the GK-BE and BE-GK when the user remain in one GK (or GK-BE) can communicate for resolving the information with another user located within another GK (or BE/GK). That is, the communication is made via the GK (or GK/BE) to locate another GK (or GK/BE) where is use is residing (for resolving information or placing a call). 2. The base H.323 spec and H.225.0 Annex G spec clearly provide those mechanisms as stated in item 1. However, your contribution appears to suggest that a GK (or BE) will use the VLF and HLF to locate another GK (or BE) where the user resides (currently). My assumption is that there can be HLF-to-HLF communications by-passing the GK-to-GK (or GK/BE-BE/GK) communications for resolving the information. It has been mentioned in my earlier emails that HLF-to-HLF communications is not an extension of H.323 protocol. Therefore, it appears to me that your contribution does not follow the model that have been suggested in items 1 and 2 per H.323 and Annex G. Am I missing anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Tuesday, August 01, 2000 5:44 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs I tried to follow your discussion on annex G. Can we split the problem in 2 parts : - the mobility management - the call control Concerning the mobility management, I think we can define the rules we want and there should be no restriction from the current annex G limitation. Concerning the call management, we MUST follow the current annex G and that's what I wanted to make clear in my APC. I think one solution could be for the BE in the mobile domain to put in the routeinfo field a sendAccessRequest to let him resolve the new location with the HLF fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com