I guess that it is a good observation by Bob. It can be thought a "kind" of
third party activities. However, a BE becomes a "party" in this process
because people have now have a place to go to have the information. And that
place is the BEs themselves.
So the basic question remains: What is the basic definition of the "third"
party registration in H.323?
Thanks Bob for his important observation.
Best regards,
Radhika
-----Original Message-----
From: Callaghan, Robert [mailto:Robert.…
[View More]Callaghan@ICN.SIEMENS.COM]
Sent: Tuesday, December 12, 2000 3:41 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
I might interject that H.225.0 Annex G can be thought of as a form of Third
Party registration. This protocol allows a Border Element (or Gatekeeper)
to registers its endpoints with other Border Elements (or Gatekeepers).
I do not know is this adds to the discussion, or not.
Bob
--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd, Boca Raton, Fl 33487
Tel: +1 561 923-1756 Fax: +1 561 923-1403
Email: Robert.Callaghan(a)ICN.Siemens.com
-----------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
I might interject that H.225.0 Annex G can be thought of as a form of Third
Party registration. This protocol allows a Border Element (or Gatekeeper)
to registers its endpoints with other Border Elements (or Gatekeepers).
I do not know is this adds to the discussion, or not.
Bob
--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd, Boca Raton, Fl 33487
Tel: +1 561 923-1756 Fax: +1 561 923-1403
…
[View More]Email: Robert.Callaghan(a)ICN.Siemens.com
-----------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi Paul, all;
What is the maximum frame per second for H.261 and H.263? Is this indicated
in the TCS? if yes, where in the OLC messages do I indicate the actual
frame rate.
Regards,
charles
-----Original Message-----
From: Paul Long [mailto:plong@PACKETIZER.COM]
Sent: Tuesday, December 12, 2000 5:34 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: audio clock rate
Charles,
H.323 doesn't care what the audio clock rate is. That's specific to the
audio encoding:
A.5.1/H.225.0v4: "The …
[View More]clock frequency is dependent on the format of data
carried as payload and is specified statically in the profile or payload
format specification that defines the format, or may be specified
dynamically for payload formats defined through non-RTP means."
A.12/H.225.0v4: "For each payload type defined, the profile must specify the
RTP timestamp clock rate to be used..."
Paul Long
ipDialog, Inc.
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM]
Sent: Tuesday, December 12, 2000 8:21 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: audio clock rate
Hi,
How can H.323 support audio clock rates higher than 8khz.
Regards,
charles
------------8-)-----------
Charles Agboh
GTS
RFC822: charles.agboh(a)gts.com
Tel: +32 (0) 2 658 4243
mobile: +32 495 58 52 67
Fax: +32(0) 2 658 5118
http://www.gtsgroup.com
Quan Yin Method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi,
How can H.323 support audio clock rates higher than 8khz.
Regards,
charles
------------8-)-----------
Charles Agboh
GTS
RFC822: charles.agboh(a)gts.com
Tel: +32 (0) 2 658 4243
mobile: +32 495 58 52 67
Fax: +32(0) 2 658 5118
http://www.gtsgroup.com
Quan Yin Method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
Mikael,
Call Forwarding is defined within Rec. H.450.3 (H.450.2 is about Call
Transfer).
OSS ASN.1 compiler as an example supports all ASN.1 used in the H.450 series
(incl. ROS object classes).
There are several manufacturers implementing H.450.x.
Remark: Such types of questions should actually be discussed at the
h323implementers list (h323implementors(a)imtc.org)
Regards,
Karl Klaghofer
Siemens AG
E-Mail: karl.klaghofer(a)icn.siemens.de
-----Ursprüngliche Nachricht-----
Von: Mikael Grehn […
[View More]mailto:mikael@ENVILOGG.SE]
Gesendet am: Dienstag, 12. Dezember 2000 13:54
An: ITU-SG16(a)mailbag.cps.intel.com
Betreff: Implementation of H450.1 and H450-2
Hi!
[I first would like to appologize if this is the wrong forum to direct
our ITU-standard question in, please inform me if it is inproper]
The question concern implementation of Call Forwarding, i.e. ITU-std
H450.1 and H450-2.
We are planning to implement Call Forwarding support into a
telephonysystem using IP-telephony based support(i.e. H323 and similar).
The standard for Call Forwarding is described/defined in H450.1 and
H450-2 (and others).
The problem is that we need to parse the ASN syntax into true
implementation files (.h/.c/.cpp) but we have failed in finding a ASN
parser that supports the specific syntax in H450.1 and H450-2.
Is there a ASN parser that can "compile" the H450.1 and H450-2 (and
preferable higher H450:s) standard protocols?
Are there any "true" alternatives (beside using H450.2 and H450-2) when
implementing Call Forwarding?
Are there any other developers that has implemented Call Forwarding that
would like to share their experiences with us?
Thanks in advance!
Sincerely
Mikael Grehn
System Developer
Envilogg Datateknik AB
Sweden
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi!
[I first would like to appologize if this is the wrong forum to direct
our ITU-standard question in, please inform me if it is inproper]
The question concern implementation of Call Forwarding, i.e. ITU-std
H450.1 and H450-2.
We are planning to implement Call Forwarding support into a
telephonysystem using IP-telephony based support(i.e. H323 and similar).
The standard for Call Forwarding is described/defined in H450.1 and
H450-2 (and others).
The problem is that we need to parse the ASN …
[View More]syntax into true
implementation files (.h/.c/.cpp) but we have failed in finding a ASN
parser that supports the specific syntax in H450.1 and H450-2.
Is there a ASN parser that can "compile" the H450.1 and H450-2 (and
preferable higher H450:s) standard protocols?
Are there any "true" alternatives (beside using H450.2 and H450-2) when
implementing Call Forwarding?
Are there any other developers that has implemented Call Forwarding that
would like to share their experiences with us?
Thanks in advance!
Sincerely
Mikael Grehn
System Developer
Envilogg Datateknik AB
Sweden
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi
It looks like there is yet another bug in the fast start procedure.
It is related to bi-directional channels establishment.
Standard says that in each bi-directional channel proposal there should be
unique forwardLogicalChannelNumber.
Standard says nothing about the value of this field in the accepted
bi-directional OLC.
It is known that bi-directional channels need 2 logical channel numbers
(forward and reverse).
I see 2 options for the value of forwardLogicalChannelNumber field in the
…
[View More]accepted bi-directional OLC:
1. It may be the same value as the forwardLogicalChannelNumber in the
corresponding proposal.
In this case we do not have the logical channel number for the reverse
direction.
This works OK till we are in fast start, but after H.245 connection
establishment
it will be impossible to perform H.245 actions on the reverse direction of
the channel.
2. It may be the unique logical channel number that is provided by calling
party and
identifies the channel -- the reverseLogicalChannelNumber.
The problem with this is that caller does not know to which proposal this
channel belongs.
BTW The same problem exists with the unidirectional channels from callee to
caller and the solution
is just to find the corresponding proposal, using different channel
characteristics.
I personally prefer the second option because it is more correct from the
H.245 point of view.
But, In any case it should be decided which is the standard one .
Sasha
***********************************************
Alexander(Sasha) Ruditsky
RADVision Ltd.
24 Raul Wallenberg St.
Tel Aviv 69719 Israel
Tel: +972-3-645-5220
Fax: +972-3-644-2903
Direct: +972-3-645-5273
sasha(a)radvision.rad.co.il
***********************************************
[View Less]
Charles,
> 1. EP S powers up (disabled RAS/not H.323 EP/....)
>
> 2. Registering Entity R is notified that EP is up (proprietary/standard)
>
> 3. Registering Entity R Registers EP S at GK G
>
> *4. Based on the defined third-party registration procedure, GK G is AWARE
> that EP S was registered by Registering entity R. GK G can exploit this
> feature
>
> 5. EP H sends an ARQ to GK G to call EP S
>
> 6. GK G (in DRC mode) confirms with an ACF.
>
> 7.…
[View More] EP H sends a setup message to EP S. In the case of theIWF, the setup
> message is sent to Registering entity R but, step for is still applicable at
> GK G.
Two cases.
If EP H sends setup to registering entity R, this is handled perfectly
adequately by the standard. No alteration to the standard is required.
If EP H sends setup to EP S, this IS what I would understand by third-party
registration. If EP S and registering entity R can not arrange to appear to
the gatekeeper to be a single entity ("as if", in the sense described by Paul
Long), more additions need to be made to the standard. However I am dubious of
this. I would suggest that interactions between R and S are in some sense
internal to an endpoint, and not suitable for standardisation (in the way that
a decomposed gateway has been considered suitable for standardisation). Others
may disagree. Given that you do so, I would suggest that your best way forward
is to make a formal proposal to an ITU experts' meeting as to how this could
work, why it is valuable etc.
Regards,
Chris
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Friday, December 08, 2000 11:03 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> Charles,
>
> I have no further comment on the subject unless and until you clarify the
> following question, which I have asked repeatedly:
> Endpoint S, registers using third party registering entity R at gatekeeper G
> which uses the direct call model. To which entity does H, an H.323 entity
> wishing to call the user at S, send its setup message (the options as I
> understand them being R and S)?
>
> Incidentally I regard both applications given in your most recent email
> simply
> as gatekeeper configuration.
>
> Regards,
> Chris
>
> "Agboh, Charles" wrote:
> >
> > Chris
> > Some applicaitons of third-party registration
> >
> > -secretary mode, where the secretary registers the current location
> > (e.g., tel:) for his boss;
> >
> > - voicemail, where the voicemail system registers itself as a branch
> > location
> >
> > regards,
> >
> > charles
> > -----Original Message-----
> > From: Agboh, Charles
> > Sent: Thursday, December 07, 2000 3:57 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Chris,
> >
> > Some ideas about why I think this could be a useful feature.....
> >
> > It is the concept of third-party registration that I believe is not
> clearly
> > (if at all) specified in H.323. "In third-party registration, the entity
> > issuing the request is different from the entity being registered." This
> is
> > not equivalent to hunting down the list of alternateEnpoints for an
> Endpoint
> > I am trying to reach. The key to this is who is requesting the binding
> > between an alias address and a transport address.
> >
> > The entity making the request is using resources of the GK. The GK may
> view
> > the entity that is being registered as a client of the entiry that made
> the
> > request and may send CDRs correlating the three parties entities. The
> > 3rd-party (as paul called it: the entity making the request) may be
> charged
> > for using the GKs resources.
> >
> > Even though my friend bob has an H.323 complaint EP that is capable of
> > registering itself, I (3rd-party: as paul called it) can register bobs
> alias
> > at my GK and my GK will send CDRs to me at the end of *our* conference.
> > Bob may inheret some of my priveleges as a result of my action.
> >
> > I don't have all the possible applications of this feature on my radar.
> >
> > Best regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Monday, December 04, 2000 2:26 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > > I said that the "....H.323 EP must support RAS...". We are down to the
> > case
> > > where the H.323 EP user has disabled RAS.
> > I would argue that this means that the endpoint is not supporting RAS, and
> > has
> > become uncompliant...
> >
> > > Is it useful to have this feature (third-party registration) for this
> > > specific case? Its not defined in the standard and I think it should be
> > > (i.e. From Pauls view, it could be useful for administrative reasons );
> > > although there are ways to provide this feature in H.323v2 and H.323v4.
> > Please expand on why you think it's a useful feature, and what you think
> is
> > required for it. I don't understand what you feel you need beyond what's
> > already there. If you are acting as a gateway/IWF then you are handling
> all
> > call signalling, and the registration is not third-party. If you are
> doing
> > Paul's "as if" case then it isn't "as if" if it requires any modifications
> > to
> > the standard. If you wish to do anything else, you need to tell us WHAT
> as
> > I
> > for one don't understand what you're trying to achieve (and calling
> > "third-party registration") that doesn't come under the above headings.
> >
> > Regards,
> > Chris
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
> > > Sent: Monday, December 04, 2000 11:01 AM
> > > To: Agboh, Charles
> > > Cc: ITU-SG16(a)mailbag.cps.intel.com
> > > Subject: Re: Third party registration/group registration
> > >
> > > Charles,
> > >
> > > > By H.323 EP, I mean an H.323 EP that must support RAS (by your
> > > > interpretation of the standard), but the RAS function can be disabled
> by
> > > the
> > > > user (Pauls views ). The GK is an optional H.323 entity.
> > > I repeat that "The GK is an optional H.323 entity" does NOT imply "RAS
> is
> > > optional in an endpoint".
> > >
> > > >>Q4. Is Charles's actual application, where one entity is registering
> and
> > > >> hence
> > > >> presumably (although he's consistently failed to clarify) handling
> RAS
> > on
> > > >> behalf of another compliant H.323 endpoint a possibility?
> > > >> A4a (My position, with which I THINK you agree) No, on the grounds
> that
> > > if
> > > >> the
> > > >> gateway/IWF can find a gatekeeper and use it, so can the endpoint.
> > > >> A4b (Charles) Yes.
> > > > A4b Yes, the H.323 EP user may have disabled RAS or the H.323 EP is
> > turned
> > > > off (i.e. SIP EP).
> > > These are two complete separate cases. We were discussing only the
> > > (disputed)
> > > case that the H.323 EP user has disabled RAS. If the H.323 endpoint is
> > > turned
> > > off and a SIP endpoint is being used, the gateway is handling ALL H.323
> > call
> > > signalling on behalf of the SIP endpoint. In other words the gateway is
> > > terminating H.323 call signalling and, as far as H.323 is concerned, IS
> > the
> > > endpoint. Or, to put it yet another way, the same device is handling
> RAS
> > as
> > > is
> > > handling all other call signalling.
> > >
> > > Regards,
> > > Chris
> > >
> > > > -----Original Message-----
> > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > > Sent: Friday, December 01, 2000 3:36 PM
> > > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > > Subject: Re: Third party registration/group registration
> > > >
> > > > Charles,
> > > >
> > > > > I am not a native English speaker (1/3), sorry for the mistake. I
> > > > > understand things better now.
> > > > I think we're getting closer now. Don't worry about not being a
> native
> > > > English
> > > > speaker - please persevere. I apologise if I've sometimes sounded
> harsh
> > > in
> > > > my
> > > > responses - it's normally because I'm trying to make points quickly!
> I
> > > know
> > > > communicating in a foreign language is hard - which is precisely why
> > it's
> > > > important to make sure that nomenclature is clear and unambiguous!
> > > >
> > > > > Consider the following scenario;
> > > > >
> > > > > A4:
> > > > >
> > > > > An enpoint A (first-party) is switch off or does not "speak" H.323
> (it
> > > > > supports RAS). I (third-party. i.e. IWF ) may want to be able to
> > > > > register this endpoint which we will call EP A. I register this
> > > > endpoint
> > > > > with its "well-known" alias address which is binded to a transport
> > > > addresses
> > > > > (not the one this EP usually uses when it is turned on. i.e.
> > transport
> > > > > address of an H.323 complaint device like an answering machine
> called
> > > AM).
> > > > > The GK will now be able to route the call for EP A to the AM. For
> the
> > > EP
> > > > > that does not "speak" H.323 the signaling will go to some entity
> that
> > > > > will be able to "speak" H.323 and bind the RAS context created by
> the
> > > IWF
> > > > > (this may be the IWF itself).
> > > >
> > > > Ah! This is a COMPLETELY different scenario from that I was
> describing!
> > > > This
> > > > is simple. All you are doing here is registering an alias somewhere
> > > > different
> > > > from what you may consider its "usual home". The key to thinking
> about
> > > this
> > > > is
> > > > that aliases are just that - they may only bind to particular devices
> > for
> > > > defined periods of time (the same user may use different endpoints on
> > > > different
> > > > days, but retain the same phone number). The practicalities between
> IWF
> > > and
> > > > the "transport address this endpoint uses when it is turned on" may
> get
> > > > somewhat hairy and certainly outside the remit of H.323, when it comes
> > to
> > > > ensuring that you don't have multiple devices trying to use the same
> > alias
> > > > in
> > > > the same zone simultaneously (sadly not permitted).
> > > >
> > > > > A5: If I have a GK in my network, I may not allow "dubious" EPs to
> > have
> > > > > direct access to my GK. <misprint corrected>
> > > > True, but not addressing the question. The question is whether it is
> > > > permitted
> > > > to separate EP and GK with a proxy. I don't know the answer to this
> > one!
> > > >
> > > > Regards,
> > > > Chris
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
> > > > > Sent: Friday, December 01, 2000 10:31 AM
> > > > > To: Agboh, Charles
> > > > > Cc: ITU-SG16(a)mailbag.cps.intel.com
> > > > > Subject: Re: Third party registration/group registration
> > > > >
> > > > > Charles,
> > > > >
> > > > > I'll take these two mails together, as the point is the same.
> > > > >
> > > > > H.225.0 section 7.7 states which RAS messages are mandatory,
> optional
> > > etc.
> > > > > for
> > > > > different H.323 devices. By mandating the support of these
> messages,
> > it
> > > > > mandates the support of RAS, since there is no proviso there for
> > "when
> > > > the
> > > > > EP/entity is supporting RAS".
> > > > >
> > > > > An aside, from a famous UK 80s sitcom on the subject of
> > "clarification":
> > > > > "You don't issue clarifications to MAKE things clear: you issue them
> > to
> > > > put
> > > > > you
> > > > > IN the clear."
> > > > >
> > > > > Regards,
> > > > > Chris
> > > > >
> > > > > -----Original Message-----
> > > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > > > Sent: Friday, December 01, 2000 10:46 AM
> > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > > > Subject: Re: Third party registration/group registration
> > > > >
> > > > > Paul,
> > > > >
> > > > > I think we're starting to converge. Let's separate this out now,
> into
> > > > > separate
> > > > > questions:
> > > > >
> > > > > Q1. Are endpoint devices (in which term I include gateways etc
> > > throughout
> > > > > this
> > > > > mail) required to implement RAS?
> > > > > A1. Yes (agreed between you and me, disagreed by Charles).
> > > > >
> > > > > Q2. How does an endpoint device know whether or not a gatekeeper is
> > > > present
> > > > > in
> > > > > the system, and hence whether or not to use RAS?
> > > > > A2a (Your position as I understand it.) Configuration, discovery on
> > > > > startup,
> > > > > give up if you don't find anything then.
> > > > > A2b (My suggestion) Configuration, discovery on startup, retry at
> some
> > > > > reasonable frequency (hourly?), take the three seconds to attempt
> > > > gatekeeper
> > > > > discovery when someone makes a call to or from the endpoint in
> > question.
> > > > > A2c (What we'll probably end up agreeing!) Implementation decision.
> > > > >
> > > > > Q3. What should an endpoint do if it attempts to register with all
> > > > > discovered
> > > > > gatekeepers, where there is at least one gatekeeper in the system,
> and
> > > > fails
> > > > > (RRJ)?
> > > > > A3a (My position) Shut itself down.
> > > > > A3b (Anybody elses) ???
> > > > >
> > > > > Q4. Is Charles's actual application, where one entity is registering
> > and
> > > > > hence
> > > > > presumably (although he's consistently failed to clarify) handling
> RAS
> > > on
> > > > > behalf of another compliant H.323 endpoint a possibility?
> > > > > A4a (My position, with which I THINK you agree) No, on the grounds
> > that
> > > if
> > > > > the
> > > > > gateway/IWF can find a gatekeeper and use it, so can the endpoint.
> > > > > A4b (Charles) Yes.
> > > > >
> > > > > This actually gives rise to a further question, which is (I believe)
> > > open,
> > > > > and
> > > > > probably shouldn't be:
> > > > > Q5. Can an endpoint be separated from its gatekeeper by a proxy?
> > > > >
> > > > > Regards,
> > > > > Chris
> > > > >
> > > > > Paul Long wrote:
> > > > > >
> > > > > > Chris,
> > > > > >
> > > > > > (You and I inadvertently replied to each other privately. I
> thought
> > > I'd
> > > > > > clean my email up a bit :-) and post it to the reflector.)
> > > > > >
> > > > > > As you point out, gatekeepers are optional, but an endpoint may
> not
> > be
> > > > > > registered with a gatekeeper (hence, an "unregistered endpoint").
> I
> > > also
> > > > > > agree with you that an endpoint must implement and be able to use
> > RAS.
> > > > The
> > > > > > tricky part, though, is under what circumstances _shall_ an
> endpoint
> > > use
> > > > > > RAS, i.e., at least attempt to register with a gatekeeper. It may
> > come
> > > > > down
> > > > > > to a rather philosophical question. If an endpoint is required to
> > use
> > > > RAS
> > > > > in
> > > > > > any way and ultimately discover and register with a gatekeeper
> only
> > if
> > > > > there
> > > > > > is a gatekeeper in the "system," how does it know whether there is
> a
> > > > > > gatekeeper within the system without using RAS? Look like a
> > Catch-22,
> > > > but
> > > > > my
> > > > > > take on it is that whether a gatekeeper is in the system must be
> > known
> > > > out
> > > > > > of band. That's the only way I know of to resolve these otherwise
> > > > > > contradictory issues.
> > > > > >
> > > > > > Smith Micro builds endpoints that can be used in systems with and
> > > > without
> > > > > > gatekeepers. Because this vendor does not know whether the system
> > > within
> > > > > > which the user will be deploying the endpoint contains a
> gatekeeper,
> > > the
> > > > > > user presumably knows and has the discretion as whether to use RAS
> > via
> > > a
> > > > > > Preferences dialog in the user interface. I think that's
> reasonable
> > > and
> > > > > > compliant. Some vendors may build endpoints that are designed to
> > > always
> > > > be
> > > > > > used within systems that contain gatekeepers, and that's fine,
> too,
> > > and
> > > > > > compliant. However, IMO, besides probably being a bad marketing
> > > decision
> > > > > > :-), an endpoint that does not support RAS at all is not
> compliant.
> > > > > >
> > > > > > Paul Long
> > > > > > ipDialog, Inc.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > > > > Sent: Thursday, November 30, 2000 7:56 AM
> > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > > > > Subject: Re: Third party registration/group registration
> > > > > >
> > > > > > Charles,
> > > > > >
> > > > > > This comes up on this list every now and again, and the answer
> > doesn't
> > > > > > change.
> > > > > > The gatekeeper is an optional entity: TRUE.
> > > > > > RAS is optional: FALSE.
> > > > > > Endpoints (including gateways, IWFs, whatever you want to call
> them)
> > > > have
> > > > > a
> > > > > > responsibility of trying to find one, registering with one if it
> can
> > > and
> > > > > > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers
> > but
> > > > > fails
> > > > > > to
> > > > > > register. Only if all reasonable attempts to find a gatekeeper
> fail
> > > > > should
> > > > > > an
> > > > > > H.323 endpoint operate without an active registration.
> > > > > >
> > > > > > Let me give you the first couple of quotations from H.323 (I'm
> > looking
> > > > at
> > > > > v4
> > > > > > determined, but I don't believe this has ever changed) I find on
> the
> > > > > > subject.
> > > > > > They're in section 7.2.2:
> > > > > > "As part of their configuration process, all endpoints shall
> > > > register..."
> > > > > > "Registration shall occur before any calls are attempted and may
> > occur
> > > > > > periodically as necessary (for example, at endpoint power-up)."
> > > > > >
> > > > > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of
> > RAS
> > > > > > messages" as well.
> > > > > >
> > > > > > How else could things work? Consider the case where an endpoint
> (A)
> > > is
> > > > > > trying
> > > > > > to make a call to another endpoint (B). A issues an ARQ to its
> > > > > gatekeeper,
> > > > > > asking permission to try a call; the gatekeeper rejects the call
> > (ARJ)
> > > > on
> > > > > > some
> > > > > > reasonable grounds (possibly a conceptual "do not disturb" notice
> B
> > > has
> > > > > set
> > > > > > up
> > > > > > with its gatekeeper). A thinks "stuff this", unregisters from its
> > > > > > gatekeeper
> > > > > > ("we don't want to worry about all that boring RAS stuff if it's
> > going
> > > > to
> > > > > be
> > > > > > inconvenient to us") and sends the Setup message to B anyway -
> > > resulting
> > > > > (at
> > > > > > best) in an disgruntled B.
> > > > > > In other words, as soon as you allow endpoints to operate in the
> > > > presence
> > > > > of
> > > > > > a
> > > > > > gatekeeper without registering with it and abiding by its
> decisions,
> > > you
> > > > > > might
> > > > > > as well write all xRJ messages out of the protocol entirely!
> > > > > >
> > > > > > If an endpoint is going to ignore RAS (and hence the standard)
> then
> > > why
> > > > > > should
> > > > > > it bother having anyone else register on its behalf? I refer you
> to
> > > > > > "Besides,..." in my last mail (which point you still haven't
> > > addressed).
> > > > > >
> > > > > > Regards,
> > > > > > Chris
> > > > > >
> > > > > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > > > listserv(a)mailbag.intel.com
> > > > >
> > > > > --
> > > > > Dr Chris Purvis -- Development Manager
> > > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND
> > > > > Phone: +44 1344 899 007
> > > > > Fax: +44 1344 899 001
> > > > >
> > > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > > listserv(a)mailbag.intel.com
> > > > >
> > > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > > listserv(a)mailbag.intel.com
> > > >
> > > > --
> > > > Dr Chris Purvis -- Development Manager
> > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND
> > > > Phone: +44 1344 899 007
> > > > Fax: +44 1344 899 001
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv(a)mailbag.intel.com
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv(a)mailbag.intel.com
> > >
> > > --
> > > Dr Chris Purvis -- Development Manager
> > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > > Winkfield Row, Berkshire. RG42 6LY ENGLAND
> > > Phone: +44 1344 899 007
> > > Fax: +44 1344 899 001
> >
> > --
> > Dr Chris Purvis -- Development Manager
> > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > Winkfield Row, Berkshire. RG42 6LY ENGLAND
> > Phone: +44 1344 899 007
> > Fax: +44 1344 899 001
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
> --
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire. RG42 6LY ENGLAND
> Phone: +44 1344 899 007
> Fax: +44 1344 899 001
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
--
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND
Phone: +44 1344 899 007
Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi Paul
I think that NULL callIdentifier is better solution.
I believe that there are and probably there will be additional cases that
require sending of Q.931 message related to the whole multiplex.
One possible example is STATUS messages in Annex R.
So, probably in the specific case of the FACILITY message the security is
not significantly compromised, but I think we definitely cannot say the same
generally about all the cases when the Q.931 message relates to the
multiplex.
So I …
[View More]believe that definition of specific callIdentifier for such cases is
required.
Sasha
-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Sunday, December 10, 2000 7:57 PM
To: Sasha Ruditsky
Cc: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: Corrections to H.225.0v4 and H.323v4
Sasha,
The problem with that is that the Facility message contains a call
Identifier. The only place this is currently used is in setting the
multipleCalls flag. I don't think that's an issue, even with security
compromised. We have to have something that makes the text in H.323v4
work-- right now there's no way to send a Facility message to change the
multipleCalls flag.
As an alternative, we could specify that the CallIdentifier will contain 16
zeros when sending non-call-related messages, as opposed to using the empty
choice.
What's the group's preference?
Paul
----- Original Message -----
From: Sasha <mailto:sasha@tlv.radvision.com> Ruditsky
To: Paul E. Jones <mailto:paulej@PACKETIZER.COM>
Cc: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com>
Sent: Sunday, December 10, 2000 8:23 AM
Subject: RE: Corrections to H.225.0v4 and H.323v4
Hi Paul
Everything looks OK with me except the very 1st change.
Specifically the empty h323-message-body element for non call related Q.931
messages.
The empty h323-message-body does not allow to add tokens to the FACILITY
message so it cannot be authenticated and its integrity cannot be checked.
My proposal is to change wording here to allow non empty h323-message-body
in the case security is required
Sasha
-----Original Message-----
From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
Sent: Saturday, December 09, 2000 12:06 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Corrections to H.225.0v4 and H.323v4
Importance: High
H.323 Experts,
I have attached a document that contains the complete list of corrections
for H.225.0v4 and H.323v4, with differences against the decided text, that
we have discussed on the mailing list this past week.
I would like all interested parties to review these changes.
I am open to changing the wording, but I would like to get consensus on
making these changes. I have asked the TSB to see if we can make these
corrections prior to the publication of the documents. If so, I want to
have the support of everyone to make these corrections. I don't believe
that any of these issues should be contentious, but without these
corrections, I'm afraid that many more questions and interoperability
problems will arise.
If it turns out that we cannot update the approved text before publication,
I plan to submit this document (or a modified version with comments I
receive from you) to the next meeting in March. Personally, I'd rather
correct the Recommendation before publication, rather than adding this to
the Implementers Guide.
Thanks,
Paul
[View Less]
Hi Paul
Everything looks OK with me except the very 1st change.
Specifically the empty h323-message-body element for non call related Q.931
messages.
The empty h323-message-body does not allow to add tokens to the FACILITY
message so it cannot be authenticated and its integrity cannot be checked.
My proposal is to change wording here to allow non empty h323-message-body
in the case security is required
Sasha
-----Original Message-----
From: Paul E. Jones [mailto:paulej@…
[View More]PACKETIZER.COM]
Sent: Saturday, December 09, 2000 12:06 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Corrections to H.225.0v4 and H.323v4
Importance: High
H.323 Experts,
I have attached a document that contains the complete list of corrections
for H.225.0v4 and H.323v4, with differences against the decided text, that
we have discussed on the mailing list this past week.
I would like all interested parties to review these changes.
I am open to changing the wording, but I would like to get consensus on
making these changes. I have asked the TSB to see if we can make these
corrections prior to the publication of the documents. If so, I want to
have the support of everyone to make these corrections. I don't believe
that any of these issues should be contentious, but without these
corrections, I'm afraid that many more questions and interoperability
problems will arise.
If it turns out that we cannot update the approved text before publication,
I plan to submit this document (or a modified version with comments I
receive from you) to the next meeting in March. Personally, I'd rather
correct the Recommendation before publication, rather than adding this to
the Implementers Guide.
Thanks,
Paul
[View Less]
