APC number for Portland
Sakae OKUBO
okubo at GITI.WASEDA.AC.JP
Mon Aug 7 10:11:09 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