Hi,
Several of the RAS messages contain an optional field 'cryptotokens'
which is a sequence of CryptoH323Token. My question is: since this
can be a sequence of tokens and you can have several tokens of the same
type, how do you distinguish between them? For instance if I had
several
cryptoEPPwdHash tokens in a sequence, how would I tell them apart?
Or would the authenticating endpoint have to check each one?
Thanks,
Tyrone
--
Tyrone Floryanzia | | |
…
[View More]tfloryan(a)cisco.com | :|: :|:
7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||:
Research Triangle Park, NC 27709 | .:|||||||:.:|||||||:.
919-472-3841 fax: 919-472-2177 | c i s c o S y s t e m s
[View Less]
Hi Roni,
But what about H.323 MC? I wanted to understand the reason/intention for
the same as it seems to be a very *intentional* decision and does not appear
that something was overlooked!
Thanks for the response!
Regards,
Gaurav Makkar
Senior Technical Leader
Hughes Software Systems
Roni Even <Roni_e(a)ACCORD.CO.IL> on 05/18/99 11:20:23 AM
Please respond to Roni Even <Roni_e(a)ACCORD.CO.IL>
To: Gaurav Makkar/HSS@HSS, h323implementors(a)imtc.org,
ITU-…
[View More]SG16(a)mailbag.cps.intel.com
cc:
Subject: RE: Multipoint Cascading Issue!
Gaurav,
I think that it is a good question. In H.320 that was the initial
cascaded mode supported. In recent a version the MIH BAS code was added
and a process describing multi hierarchy was defined in a tree structure
similar to T.120.
Roni Even
**********************************************
Roni Even
VP Product Marketing
Accord Video Telecommunication
Email: roni_e(a)accord.co.il
Tel: +972-3-9251412
Fax: +972-3-9211571
***************************************************
> -----Original Message-----
> From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com]
> Sent: Monday, May 17, 1999 8:57 PM
> To: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com
> Subject: Multipoint Cascading Issue!
>
>
>
>
> Please refer to H.323 recommendation, clause 8.4.5, "There shall
> only be
> one master MC in a conference. A slave MC shall only be cascaded to a
> master MC.
> Slave MCs shall not be cascaded to other slave MCs. This allows only
> dumb-bell
> or star cascaded configurations.".
>
> My query is: why the above restriction? If one can have a
> multi-level tree
> structure in a T.120 conference, why should the above restriction be
> applied to
> an H.323 conference? Also, using the above, a conference (using a
> single MC) can
> have only 256 participants (terminal label is 8-bits). Cascading would
> be
> required to increase the size of the conference - again limited to
> 65536
> participants (that ofcourse is large-enough for a planned conference,
> if not
> adopt H.332) and that too in a "wierd" star configuration. Point is
> why have the
> Master MCU and its network subnet be overloaded with information from
> all slave
> MCs - why not permit a configuration in which an MC can act as a slave
> to one MC
> and a master to another. That way a tree configuration for the
> conference could
> be built.
>
> Am I missing something?? I would be greatful if someone could
> give some
> direction on this account.
>
> Thanks!
>
> Regards,
>
> Gaurav Makkar
> Senior Technical Leader,
> Hughes Software Systems
>
>
> ----------------------------------------------------------------------
> ---
> for list subscription instructions,
> send email to h323implementors-request(a)imtc.org with text "info"
-------------------------------------------------------------------------
for list subscription instructions,
send email to h323implementors-request(a)imtc.org with text "info"
-------------------------------------------------------------------------
for list subscription instructions,
send email to h323implementors-request(a)imtc.org with text "info"
[View Less]
Dear All,
One solution to the version number paradox might work in the gatekeeper
routed mode. An endpoint can find out during registration and prior to
sending SETUP the version number of the gatekeeper . Based on the version
of the GK, an endpoint can decide whether to send presentation restricted
information to the GK. If the remote endpoint, or the next 'routing entity'
is also registered with the GK, it will know its the version. The GK could
remove the IE based on this information.
…
[View More]On a wider scale, this also requires such information to be included in
Annex G. Is it?
Pete
=============================================
Pete Cordell
pete.cordell(a)btinternet.com
=============================================
-----Original Message-----
From: Paul Long <Plong(a)SMITHMICRO.COM>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 14 May 1999 17:12
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@ICN.SIEMENS.COM]
> Sent: Friday, May 14, 1999 10:18 AM
> 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
>
>
[View Less]
Gaurav,
I think that it is a good question. In H.320 that was the initial
cascaded mode supported. In recent a version the MIH BAS code was added
and a process describing multi hierarchy was defined in a tree structure
similar to T.120.
Roni Even
**********************************************
Roni Even
VP Product Marketing
Accord Video Telecommunication
Email: roni_e(a)accord.co.il
Tel: +972-3-9251412
Fax: +972-3-9211571
***************************************************
> -----Original …
[View More]Message-----
> From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com]
> Sent: Monday, May 17, 1999 8:57 PM
> To: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com
> Subject: Multipoint Cascading Issue!
>
>
>
>
> Please refer to H.323 recommendation, clause 8.4.5, "There shall
> only be
> one master MC in a conference. A slave MC shall only be cascaded to a
> master MC.
> Slave MCs shall not be cascaded to other slave MCs. This allows only
> dumb-bell
> or star cascaded configurations.".
>
> My query is: why the above restriction? If one can have a
> multi-level tree
> structure in a T.120 conference, why should the above restriction be
> applied to
> an H.323 conference? Also, using the above, a conference (using a
> single MC) can
> have only 256 participants (terminal label is 8-bits). Cascading would
> be
> required to increase the size of the conference - again limited to
> 65536
> participants (that ofcourse is large-enough for a planned conference,
> if not
> adopt H.332) and that too in a "wierd" star configuration. Point is
> why have the
> Master MCU and its network subnet be overloaded with information from
> all slave
> MCs - why not permit a configuration in which an MC can act as a slave
> to one MC
> and a master to another. That way a tree configuration for the
> conference could
> be built.
>
> Am I missing something?? I would be greatful if someone could
> give some
> direction on this account.
>
> Thanks!
>
> Regards,
>
> Gaurav Makkar
> Senior Technical Leader,
> Hughes Software Systems
>
>
> ----------------------------------------------------------------------
> ---
> for list subscription instructions,
> send email to h323implementors-request(a)imtc.org with text "info"
[View Less]
Please refer to H.323 recommendation, clause 8.4.5, "There shall only be
one master MC in a conference. A slave MC shall only be cascaded to a master MC.
Slave MCs shall not be cascaded to other slave MCs. This allows only dumb-bell
or star cascaded configurations.".
My query is: why the above restriction? If one can have a multi-level tree
structure in a T.120 conference, why should the above restriction be applied to
an H.323 conference? Also, using the above, a conference (using a …
[View More]single MC) can
have only 256 participants (terminal label is 8-bits). Cascading would be
required to increase the size of the conference - again limited to 65536
participants (that ofcourse is large-enough for a planned conference, if not
adopt H.332) and that too in a "wierd" star configuration. Point is why have the
Master MCU and its network subnet be overloaded with information from all slave
MCs - why not permit a configuration in which an MC can act as a slave to one MC
and a master to another. That way a tree configuration for the conference could
be built.
Am I missing something?? I would be greatful if someone could give some
direction on this account.
Thanks!
Regards,
Gaurav Makkar
Senior Technical Leader,
Hughes Software Systems
[View Less]
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)…
[View More]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
>
[View Less]
Brian,
I read the document you posted on the megaco list and I think I have a
better understanding of your approach now. This does not mean I agree
with it, though. I put my comments in the word document and reformatted
it to html to make sure that everybody can read it. If I didn't screw
up, my comments are typeset in blue.
Regards,
John Segers
Brian Rosen wrote:
>
> I was requested to write a paper in support of single media
> contexts to counter the multi-media context …
[View More]proposals that are
> around. It will be input to the SG16 meeting in Santiago next week. The
> paper is attached for your interest.
>
> Brian
>
> ------------------------------------------------------------------------
> Name: The Case for Mono.doc
> The Case for Mono.doc Type: Microsoft Word Document (application/msword)
> Encoding: base64
--
John Segers email: jsegers(a)lucent.com
Lucent Technologies Room HE 306
Dept. Forward Looking Work phone: +31 35 687 4724
P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954
[View Less]
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 …
[View More]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@ICN.SIEMENS.COM]
Sent: Friday, May 14, 1999 10:18 AM
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
[View Less]
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 …
[View More]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
[View Less]
Dear Q.12-14/16 experts,
I've placed these files in the Incoming directory of the pictel ftp
site:
H341wht8.zip - H.341 with diff-marked changes from white draft
td_341_changes.doc - description of the changes to H.341
hgcptd.zip - draft H.gcp (this replaces HGCP.ZIP/doc also found there)
Regards,
Glen
--
Glen Freundlich ggf(a)lucent.com
Lucent Technologies office: +1 303 538 2899
11900 N. Pecos fax: +1 303 538 3907
…
[View More]Westminster, Colorado 80234 USA
[View Less]