APC-1981 Uploaded

Klaghofer Karl ICN EN HC SE 81 Karl.Klaghofer at ICN.SIEMENS.DE
Tue Oct 31 09:25:05 EST 2000

Hi, Martin:

I am responding to your general question:

I like to pint out that we will create "one common VLF/HLF protocol" that
can be used by all applications (H.323, H.310, H.324, IMT-2000, and others)
that like to support mobility related value-added services.

So, I do not think that we have agreed at all to extend H.225.0 Annex G for
that purpose that will ONLY be specific to H.323 mobility.

If the properties of H.225.0 Annex G protocol are so good that we need to
use all those for solving the mobility related VLF/HLF problems, we can
still use those properties, if needed, for the "VLF/HLF protocol," but we
will definitely NOT term as "H225.0 Annex G protocol." We will name it as a
"new protocol" that can be used by all applications without restricting it
ONLY to H.323.

The conclusion is that the proposal of extending the H.225.0 Annex G for the
VLF/HLF services to make it specific ONLY for H.323 is HIGHLY controversial
and will create many protocols (instead of one) for the same purpose within
ITU. It will be disaster for both service provider and equipment
manufacturer community.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Euchner Martin [mailto:Martin.Euchner at ICN.SIEMENS.DE]
Sent: Monday, October 30, 2000 10:31 AM
Subject: AW: [H.323 Mobility:] MD-110 uploaded (new messages to H.225
Anne x G)

Hi Jaakko,

I'm not certain, whether I really understand the purpose of the
If I look at Annex G v1, H.235 Clear and CryptoTokens are always present in
each Annex G message; they are conveyed within AnnexGCommonInfo and thus are
already part of each annex G message. Thus, I would say, that
EncryptionToken is somewhat redundant and we do not need that this way.

The other question I have concerns AuthenticationRejection: Why do you
reverse tunnel - that is, feed back - the tunneled message in the reject?

Finally a general question:
Once there was a discussion that Annex G not only be used among Border
elements as currently defined in the H.225 Annex Gv1 scope, but to extend
its usage for mobility purposes. If this were true, then Annex G could be
applied also between the GK-VLF/BE and between HLF/BE-AuF. What is the
current status of that discussion?

Kind Regards

Martin Euchner.
| Dipl.-Inf.                     Phone: +49 89 722 55790
| Martin Euchner                 Fax  : +49 89 722 46841
| Siemens AG
| ICN M NT 5                     mailto:Martin.Euchner at icn.siemens.de
<mailto:Martin.Euchner at icn.siemens.de>
|                                mailto:martin.euchner at ties.itu.int
<mailto:martin.euchner at ties.itu.int>
| Hofmannstr. 51                 Intranet:
| D-81359 Muenchen               Internet: http://www.siemens.de
| __________________
| Germany

        -----Ursprüngliche Nachricht-----
        Von:    Jaakko Sundquist [SMTP:jaakko.sundquist at NOKIA.COM]
        Gesendet am:    Montag, 30. Oktober 2000 11:11
        An:     ITU-SG16 at mailbag.cps.intel.com
        Betreff:        [H.323 Mobility:] MD-110 uploaded (new messages to
H.225 Annex G)

        Mr. Fortinsky et al,

        I have uploaded MD-110 containing a contribution on adding new,
        authentication related messages to the H.225 Annex G protocol, to
the URL:

        ssagesToH225AnnexG.zip . I will send the contribution also to the
        meetings in Geneva, but if you send comments really quickly
(tomorrow) to
        me, I may be able to make some changes to the contribution, before
        distributing it.

        Jaakko Sundquist           *
        +358 50 3598281            * Audere est Facere!
        jaakko.sundquist at nokia.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