[H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs

Roy, Radhika R, ALCOO rrroy at ATT.COM
Mon Aug 7 09:34:57 EDT 2000


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 at ALCATEL.FR]
Sent: Thursday, August 03, 2000 11:04 AM
To: ITU-SG16 at 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 at 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 at mailbag.cps.intel.com>



 To:      ITU-SG16 at 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 at ALCATEL.FR]
Sent: Tuesday, August 01, 2000 5:44 AM
To: ITU-SG16 at 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 at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list