The Case for Multi-media Contexts
John Segers
jsegers at LUCENT.COM
Sun May 16 22:11:19 EDT 1999
Paul,
I believe your latter assumption is correct-- we need the functionality of
octet 3a and would prefer to use it as prescribed in Q.931 rather than
invent some new "hack" to achieve the same functionality.
I don't believe that the question is unreasonable to ask-- we must find out
somehow. Certainly, a decision like this cannot be made lightly and must be
made with all interested parties knowing about it. If there are absolutely
no objections from any company providing H.323 products, I certainly see no
reason why we cannot allow it.
Regards,
Paul
----- Original Message -----
From: Paul Long <Plong at SMITHMICRO.COM>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: Friday, May 14, 1999 11:58 AM
Subject: Re: caller ID and implementer's guide
> 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
>
More information about the sg16-avd
mailing list