May 1999 - sg16-avd - lists.packetizer.com

cryptoH323Tokens
by Tyrone Floryanzia 18 May '99

18 May '99

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 | | | 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

1 0

RE: Multipoint Cascading Issue!
by gmakkar＠hss.hns.com 18 May '99

18 May '99

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-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"

1 0

Re: caller ID and implementer's guide
by Pete Cordell 18 May '99

18 May '99

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. 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 > >

1 0

Re: Multipoint Cascading Issue!
by Roni Even 18 May '99

18 May '99

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"

1 0

Multipoint Cascading Issue!
by Gaurav Makkar 17 May '99

17 May '99

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

1 0

Re: caller ID and implementer's guide
by Chris Purvis 17 May '99

17 May '99

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 >

1 0

Re: The Case for Multi-media Contexts
by John Segers 17 May '99

17 May '99

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 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

1 0

Re: caller ID and implementer's guide
by Paul Long 14 May '99

14 May '99

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

2 1

Re: caller ID and implementer's guide
by Wuerfel, Randy P 14 May '99

14 May '99

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

1 0

more documents for Chile
by Glen Freundlich 14 May '99

14 May '99

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 Westminster, Colorado 80234 USA

1 0