caller ID and implementer's guide

[Paul Long]

Randy,

I agree, it has gone on too long, but... :-)

Exactly, you've made my point for me!

1.      One cannot send SETUP to a v1 or v2 EP with the octet-3 extension bit
of calling party number set to 0, because H.225.0 v1 and v2 says that it shall
be set to 1.

2.      An H.323 entity cannot know (through in-band means) the version of the
destination EP before it sends SETUP.

3.      Therefore, an entity can never send SETUP to an EP with the extension
bit set to 0 and octet 3a present.

I don't know how to make it any clearer. Either nobody understands what I'm
saying, or they do but really really REALLY want to use octet 3a "the way God
intended it to be used" :-) regardless of whether it violates some revisions
of H.225.0 and risks breaking compliant implementations. I believe the latter
is the case, but nobody wants to admit it.

Paul Long
Smith Micro Software, Inc.

        -----Original Message-----
        From:   Wuerfel, Randy P [SMTP:Randy.P.Wuerfel at ICN.SIEMENS.COM]
        Sent:   Friday, May 14, 1999 10:18 AM
        To:     ITU-SG16 at MAILBAG.INTEL.COM
        Subject:        Re: caller ID and implementer's guide

        Perhaps this discussion has gone on too long, however I just wanted to
point
        out that when Paul uses the phrase "an EP cannot send a SETUP message
to a
        v1 or v2 EP ...", the phrase has no meaning (at least to me).  We
support
        users (people!) on our H.323 system that register with a GK.  The
users are
        mobile, and can thus register from any EP.  Thus, when I initiate a
call, my
        ARQ indicates a destinationInfo alias address of a user that may at
that
        moment be using any type of an EP.  Since my EP doesn't attempt to
match a
        transport address with an EP type (which would be a triviality
anyway), I
        have no idea of the EP type (v1, v2 or in the future v3) when I send
the
        Setup message.

        Don't I need an H.225.0 message returned from the destination EP
before I
        can determine its type?

        Please consider the proposals that Karl Klaghofer has made to resolve
this
        issue in Santiago.

        ==========================================================
        Randy Wuerfel
        IP/Data Networks Development
        Unisphere Solutions, Inc.               E-mail:
        Randy.P.Wuerfel at icn.siemens.com
        4900 Old Ironsides Drive                Fax: (408) 492-4666
        M/S 200                         Tel: (408) 492-4375
        P.O. Box 58075
        Santa Clara, CA 95052-8075