Contributions to the SG16 meeting (5-15 February 2002)

OKUBO Sakae okubo at GITI.WASEDA.AC.JP
Tue Jan 15 21:50:23 EST 2002


-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy at att.com]
Sent: Friday, January 11, 2002 9:02 AM
To: BOUGANT François FTRD/DAC/ISS; ITU-SG16 at echo.jf.INTEL.COM
Cc: Meyer, Greg W
Subject: RE: Report of Q.5 (mobility) phone conference, December 18th,
200 1


(Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.)

Further to my earlier email, I like to add a summary. The main reason is
that H.22x is almost a duplicate set of H.225.0 Annex G protocol except few
parameters related to mobility (what can be done through extending H.225.0
Annex G).

Please note that we have developed as modular sets that are decoupled as
follows:

H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs)
H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs)
H.225.0 Annex G - among the BEs
H.245 Call/media control (terminals, media-aware GKs, GWs)

The proposed H.22x overlaps completely with H.225.0 Annex G except few
mobility related parameters. Here lies the fundamental confusions.

Best regards,

Radhika R. Roy
rrroy at att.com

-----Original Message-----
From: Roy, Radhika R, ALASO
Sent: Friday, January 11, 2002 11:42 AM
To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16 at echo.jf.INTEL.COM
Cc: 'Meyer, Greg W'
Subject: RE: Report of Q.5 (mobility) phone conference, December 18th,
200 1


(Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.)

Hi, Mr. Francois and All:

The fundamental arguments have been that a protocol is defined with its own
characteristics. For example, H.323 protocol has its own entities like
terminals, GKs, BEs, and GWs. Whatever protocol is used by these entities
among themselves is known as H.323 protocol suit: For example, H.225.0 Annex
G among BEs. So, the argument is that whatever protocol is used among the
BEs is known as H..25.0 Annex G. The question is: How can we define another
protocol like H.22x among the same BEs of H.323? Is it not contradictory to
the fundamentals for development of the protocol? Will it not confuse
everything? (An analogy: How can we say that let us develop another
protocol, say, H.ZZZ to be used among terminals, GKs, and GWs in addition to
H.323?)

The solution that we have been discussed among ourselves is as follows (I am
providing a copy):

----------------------------------------------------------------------------
-------------------------------------------
1. We are developing a new protocol where no protocol exists and the same
can used by all applications to solve the mobility related problems. For
example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. Here where we
are defining a new "generic" protocol. This is not specific to the H.323
protocol. (Whether VLF, HLF, and AuF will be colocated with the BE/AMFE is a
matter of implementation.)

2. We have the H.225.0 Annex G protocol that allows us to communicate among
the H.323 BEs. This is specific to H.323. All we need to do is to extend
this protocol to serve our purposes. (An analogy can be provided. It should
be done in a way what Paul Reddy has done for H.xxx Annex E.)

3. We have the H.225.0 (RAS + Q.931) protocol that is used among the H.323
Terminals, GKs, and GWs. This is specific to H.323. All we need to do is to
extend this protocol to serve our purposes. (An analogy can be provided. It
should be done in a way what Paul Reddy has done for H.xxx Annex E.)

The questions that I have to you all: Why do you want to develop a generic
protocol (if it is not H.323 specific) for items 2 and 3? If you want to do
so, how do you definite the generic functional entities like terminals, GKs,
BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the
concept of functional entities like GKs.)

My assumption has been that the same (items 2 and 3) can also be done for
H.324, H.310, or other protocol while all protocols can use the same
"generic" protocol as developed in item 1.

Please also note that if we develop a "generic" protocol for items 2 and 3
instead of being making protocol-specific extension, we will force each
protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE sets of protocols
(protocol specific + generic) among all its functional entities. Is it nor
wastage of resources?

----------------------------------------------------------------------------
-----------------------------------------

It is not that we cannot develop many fency things like H.22x, but it
contradicts the fundamental goals of the protocol development.

Best regards,

Radhika R. Roy
rrroy at att.com

-----Original Message-----
From: BOUGANT François FTRD/DAC/ISS
[mailto:francois.bougant at RD.FRANCETELECOM.COM]
Sent: Friday, January 11, 2002 10:32 AM
To: ITU-SG16 at echo.jf.INTEL.COM
Subject: Re: Report of Q.5 (mobility) phone conference, December 18th,
200 1


Dear all,

During the last rapporteur's meeting (Dublin - Ireland), it was expressed
that defining H.22x (designed on the basis of H.225 annex G v2 at the
current state - the backward compatibility with H.225 annex G v1 would be
necessary) as a protocol used on BE--BE and BE--{Backend service entities}
interfaces (other interfaces implying GKs could be considered) and stopping
H.225 annex G would be a better way than defining a new protocol used on
BE--{Backend service entities} interfaces and going on H.225 v2.

A significant argument is : in the latter case, the BE would support two
application-layer protocols that may evolve separatly in the future. This
would tend to make BE functionalities harder to implement.
A second one is : if the H.22x "body" includes the H.225 annex G protocol ,
it can be used for information exchange on BE--BE interface even in the
H.323 mobility management context.

To my understanding, H.22X would not contain any functional architecture
description. This would be specifically described in every H.MMS.x draft,
depending on the application context (H.323 specific, etc.). To give an
example, the definition of generic entities would be contained in H.MMS.0.
Specific entities such as GKs would be described in H.MMS.1.
Then, mobility management implies a limited set of information exchanges
that are independants from the application (although the type of exchange
data depends on the application). These are related to the same actions at
least : user registration/deregistration, location update, authentication,
information update (e.g. user service profile transfer, update), location
information request. So I think it is possible to define a "simple" generic
protocol.

Best regards,

François Bougant
France Telecom

-----Message d'origine-----
De : Roy, Radhika R, ALASO [mailto:rrroy at att.com]
Envoyé : mercredi 9 janvier 2002 16:16
À : BOUGANT François FTRD/DAC/ISS; ITU-SG16 at echo.jf.INTEL.COM
Cc : Meyer, Greg W
Objet : RE: Report of Q.5 (mobility) phone conference, December 18th,
2001


Hi, Mr. Francois and All:

In addition, we also had some email correspondences among the conference
participants and few interested folks including Mr. Jones and Mr. Reddy. It
has been opined that H.22x is NOT needed because the extensions of the
existing application-specific protocol (e.g., H.225.0 Annex G) for mobility
will serve the purpose.

Copies of the emails are enclosed below.

Best regards,

Radhika R. Roy
rrroy at att.com

PS: I would highly appreciate if Mr. Greg Meyer would send the email to the
SG16 reflector as you know that I can receive the mail from the reflector,
but cannot send it because of problems in filtering.



More information about the sg16-avd mailing list