Randy,
Can one get hold of Karl's proposal without going to Santiago? I haven't
seen it yet, and am keen to see what he has in mind.
Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND
Phone: +44 1753 661 359 email: cpurvis(a)madge.com
> -----Original Message-----
> From: Wuerfel, Randy P [mailto:Randy.P.Wuerfel@ICN.SIEMENS.COM]
> Sent: 14 May 1999 4:18
> To: ITU-SG16(a)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(a)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
>
>
> -----Original Message-----
> From: Paul Long [mailto:Plong@SMITHMICRO.COM]
> Sent: Thursday, May 13, 1999 3:26 PM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: caller ID and implementer's guide
>
> Chip,
>
> Funny you should ask. In my first response to Glen, I said
> that we clear the
> call, but just a few minutes ago I took another look at the
> code and found
> that we completely ignore the calling party number IE in
> SETUP. Skip right
> over the sucker. I must have been looking at how we handle the octet-3
> extension bit for another IE, e.g., bearer capability (even
> Q.931 requires
> it
> to always be 1).
>
> While it turns out that we accept a call regardless of
> whether the extension
> bit under discussion is set, I still stand by my assertion
> that an EP cannot
> send a SETUP message to a v1 or v2 EP with the extension bit
> of octet 3 set
> to
> 0 and octet 3a present. I happen to know what my
> implementation does, and
> the
> impact is minimal, but there are bound to be implementations out there
> that--through no fault of their own--will in effect become
> "broken" if we
> decide that this bit can be set to 0 and this octet can be
> present after
> all.
>
> Paul Long
> Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Thursday, May 13, 1999 3:49 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: caller ID and implementer's guide
>
> What does your implementation do if it receives a "0" in the
> Extension
> field of Octet 3?
>
> Chip
>
