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