Hi Roy, Chris;
RAS is RECOMMENDED. It is NOT MANDATORY (hence optional) whether the
sigalals are incoming or outgoing. Please, just indicate where in H.323
RAS is mandated.
Regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
Sent: Thursday, November 30, 2000 6:33 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
Hi, Chris:
Yes, I do.
Regards,
Radhika
-----Original Message-----
From: Chris Wayman …
[View More]Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Thursday, November 30, 2000 12:01 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Cc: Roy, Radhika R, ALCOO
Subject: Re: Third party registration/group registration
All,
A clarification:
I am sure Radhika will agree that when he refers to call setup this includes
the case of incoming call setup as well as that of outgoing call setup!
Regards,
Chris
"Roy, Radhika R, ALCOO" wrote:
>
> Hi, All:
>
> Let me add a little.
>
> An H.323 entity needs to have the capability to support RAS messages.
> However, whether the RAS messages will be used or not before the call
setup
> is up to that entity.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 8: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
>
> "Agboh, Charles" wrote:
> >
> > Chris,
> >
> > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Thursday, November 30, 2000 12:49 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > > The answer to your first question depends on the capabilities of D.
> > > RAS is OPTIONAL so I could have a D device that does not implement
RAS.
> > > In my last email, the "third-party" would be a C device and
> "first-party"
> > > would be a D device (second-party is the A device) .
> > RUBBISH!
> > RAS is NOT optional. See Table 18/H.225.0.
> > Besides, how would your crippled H.323 endpoint tell its RAS handler to
> send
> > the various RAS messages (like for instance ARQ to ask permission to
make
> a
> > call...)?
> >
> > Regards,
> > Chris
> >
> > >
> > > Regards,
> > >
> > > charles
> > >
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > Sent: Thursday, November 30, 2000 10:43 AM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Charles,
> > >
> > > In your definition of "third-party" registration, consider a scenario
> > > involving
> > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
> > > gateway/IWF/registering-entity (C) and an entity of some sort on whose
> > > behalf C
> > > is registering (which we'll call D). Assuming that B is not routing
> > > call-signalling, to which entity would A send its "Setup" message in
> order
> > > to
> > > contact D?
> > >
> > > If the answer to this question is "C", this is well-covered in the
> > standard
> > > -
> > > it is simply that the term "third-party registration" is not used for
> it.
> > > It
> > > is simply viewed as C registering (potentially) lots of aliases. This
> > > parallels Tom's second case.
> > > If the answer is "D" (parallelling Tom's first case), then D is a very
> odd
> > > device (it can't be a full H.323 implementation or it would register
for
> > > itself). Why have a device implementing all of H.323 except
gatekeeper
> > > registration? After all, D would have to handle all the rest of RAS
for
> > > itself
> > > - what would it be gaining by not registering on its own behalf?
> > >
> > > In the same scenario, to what entities are you referring,
respectively,
> as
> > > the
> > > "third-party" in your latest contribution?
> > >
> > > PLEASE clarify your definitions of "first-party" and "third-party" in
> > cases
> > > where you use these terms. I am certain that the ends you are trying
to
> > > achieve are perfectly possible - and not even that hard. Either will
> > > result, I
> > > believe, in a brief discussion with early consensus emerging. I
believe
> > the
> > > problems, and the large amount of mail this is generating on this
list,
> > come
> > > about entirely from the use of these terms without anyone
understanding
> > > exactly
> > > what is meant by them.
> > >
> > > I agree with Tom that once we can agree on terminology we can move on
> > quite
> > > easily, and thank him for his usual high-quality clear-sighted input.
> > >
> > > Regards,
> > > Chris
> > >
> > > ------------------------------------
> > >
> > > The registration feature allows endpoints to bind their identities to
> > > transport
> > > address(es) at the GK. This is well described in H.323. When an
> > endpoint
> > > delegates another endpoint to perform this fearture on its behalf the
> > > definition in H.323 is not there. The signaling that follows the
> > > registration
> > > whether, its
> > > first or third-party may interrogate this binding. The third-party
> > > registration feature can enhance the user experience much more than a
> > normal
> > > first-party
> > > registration. I don't believe that the third-party has to be in the
> > > signaling
> > > flow that may follow the third-registration. I agree with Tom-PTs
> view.
> > >
> > > Best regards,
> > >
> > > charles
> > >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Wednesday, November 29, 2000 7:39 PM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Accurate terminology is obviously useful, but in this case, at
> least,
> > it
> > > looks like something people can agree on and then move on. The more
> > > important point seems to be the underlying distinction in
> > requirements:
> > >
> > > -- register on behalf of H.323 endpoints
> > > -- register on behalf of other endpoints
> > > where I use "other" in the sense that the contact address is
> > associated
> > > with a non-H.323 signalling protocol. Purity is beside the point here
> --
> > > it's the intention of the contact address that matters. Stating
the
> > > requirement in this way makes it obvious that the second requirement
> > > includes
> > > the need to state which protocol the endpoints expects to receive.
> > >
> > > There is another possibility, of course: use the same mechanism to
> > > satisfy
> > > all requirements, and allow for the possibility that the endpoint
> > > supports multiple protocols. I think the design would be cleaner
if
> > we
> > > took the approach: one contact point, one protocol -- even if it meant
> > > repeating the contact information for each protocol a
multiprotocol
> > > endpoint supports.
> > >
> > > --
> > > 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
>
> --
> 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
[View Less]
Hi, Charles:
Pl. see the statement carefully. The use of RAS is Optional, but RAS needs
to be supported.
Thanks,
Radhika
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@gts.com]
Sent: Thursday, November 30, 2000 12:49 PM
To: Roy, Radhika R, ALCOO; ITU-SG16(a)MAILBAG.INTEL.COM
Subject: RE: Third party registration/group registration
Hi Roy, Chris;
RAS is RECOMMENDED. It is NOT MANDATORY (hence optional) whether the
sigalals are incoming or outgoing. Please, just …
[View More]indicate where in H.323
RAS is mandated.
Regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
Sent: Thursday, November 30, 2000 6:33 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
Hi, Chris:
Yes, I do.
Regards,
Radhika
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Thursday, November 30, 2000 12:01 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Cc: Roy, Radhika R, ALCOO
Subject: Re: Third party registration/group registration
All,
A clarification:
I am sure Radhika will agree that when he refers to call setup this includes
the case of incoming call setup as well as that of outgoing call setup!
Regards,
Chris
"Roy, Radhika R, ALCOO" wrote:
>
> Hi, All:
>
> Let me add a little.
>
> An H.323 entity needs to have the capability to support RAS messages.
> However, whether the RAS messages will be used or not before the call
setup
> is up to that entity.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 8: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
>
> "Agboh, Charles" wrote:
> >
> > Chris,
> >
> > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Thursday, November 30, 2000 12:49 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > > The answer to your first question depends on the capabilities of D.
> > > RAS is OPTIONAL so I could have a D device that does not implement
RAS.
> > > In my last email, the "third-party" would be a C device and
> "first-party"
> > > would be a D device (second-party is the A device) .
> > RUBBISH!
> > RAS is NOT optional. See Table 18/H.225.0.
> > Besides, how would your crippled H.323 endpoint tell its RAS handler to
> send
> > the various RAS messages (like for instance ARQ to ask permission to
make
> a
> > call...)?
> >
> > Regards,
> > Chris
> >
> > >
> > > Regards,
> > >
> > > charles
> > >
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > Sent: Thursday, November 30, 2000 10:43 AM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Charles,
> > >
> > > In your definition of "third-party" registration, consider a scenario
> > > involving
> > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
> > > gateway/IWF/registering-entity (C) and an entity of some sort on whose
> > > behalf C
> > > is registering (which we'll call D). Assuming that B is not routing
> > > call-signalling, to which entity would A send its "Setup" message in
> order
> > > to
> > > contact D?
> > >
> > > If the answer to this question is "C", this is well-covered in the
> > standard
> > > -
> > > it is simply that the term "third-party registration" is not used for
> it.
> > > It
> > > is simply viewed as C registering (potentially) lots of aliases. This
> > > parallels Tom's second case.
> > > If the answer is "D" (parallelling Tom's first case), then D is a very
> odd
> > > device (it can't be a full H.323 implementation or it would register
for
> > > itself). Why have a device implementing all of H.323 except
gatekeeper
> > > registration? After all, D would have to handle all the rest of RAS
for
> > > itself
> > > - what would it be gaining by not registering on its own behalf?
> > >
> > > In the same scenario, to what entities are you referring,
respectively,
> as
> > > the
> > > "third-party" in your latest contribution?
> > >
> > > PLEASE clarify your definitions of "first-party" and "third-party" in
> > cases
> > > where you use these terms. I am certain that the ends you are trying
to
> > > achieve are perfectly possible - and not even that hard. Either will
> > > result, I
> > > believe, in a brief discussion with early consensus emerging. I
believe
> > the
> > > problems, and the large amount of mail this is generating on this
list,
> > come
> > > about entirely from the use of these terms without anyone
understanding
> > > exactly
> > > what is meant by them.
> > >
> > > I agree with Tom that once we can agree on terminology we can move on
> > quite
> > > easily, and thank him for his usual high-quality clear-sighted input.
> > >
> > > Regards,
> > > Chris
> > >
> > > ------------------------------------
> > >
> > > The registration feature allows endpoints to bind their identities to
> > > transport
> > > address(es) at the GK. This is well described in H.323. When an
> > endpoint
> > > delegates another endpoint to perform this fearture on its behalf the
> > > definition in H.323 is not there. The signaling that follows the
> > > registration
> > > whether, its
> > > first or third-party may interrogate this binding. The third-party
> > > registration feature can enhance the user experience much more than a
> > normal
> > > first-party
> > > registration. I don't believe that the third-party has to be in the
> > > signaling
> > > flow that may follow the third-registration. I agree with Tom-PTs
> view.
> > >
> > > Best regards,
> > >
> > > charles
> > >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Wednesday, November 29, 2000 7:39 PM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Accurate terminology is obviously useful, but in this case, at
> least,
> > it
> > > looks like something people can agree on and then move on. The more
> > > important point seems to be the underlying distinction in
> > requirements:
> > >
> > > -- register on behalf of H.323 endpoints
> > > -- register on behalf of other endpoints
> > > where I use "other" in the sense that the contact address is
> > associated
> > > with a non-H.323 signalling protocol. Purity is beside the point here
> --
> > > it's the intention of the contact address that matters. Stating
the
> > > requirement in this way makes it obvious that the second requirement
> > > includes
> > > the need to state which protocol the endpoints expects to receive.
> > >
> > > There is another possibility, of course: use the same mechanism to
> > > satisfy
> > > all requirements, and allow for the possibility that the endpoint
> > > supports multiple protocols. I think the design would be cleaner
if
> > we
> > > took the approach: one contact point, one protocol -- even if it meant
> > > repeating the contact information for each protocol a
multiprotocol
> > > endpoint supports.
> > >
> > > --
> > > 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
>
> --
> 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
[View Less]
No (except for Annex F terminals).
We had that discussions in standards. Just do H.245 TCS and M/S
determination
after fastStart has completed (preferably using H.245 tunnelling). Then you
can
use the null TCS procedures of 8.4.6/H.323.
> -----Original Message-----
> From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM]
> Sent: Thursday, November 30, 2000 10:10 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: FastConnect W/O any OLC - can it be?
>
>
> Would that be a …
[View More]way to do a third-party initiated pause when using
> FastConnect?
>
> charles
>
> -----Original Message-----
> From: Adi Shmul [mailto:adi@tundo.com]
> Sent: Thursday, November 30, 2000 6:29 PM
> To: h323implementors(a)imtc.org
> Subject: FastConnect W/O any OLC - can it be?
>
>
>
>
> Regards
> Adi Shmul
> Standards & Interoperability Manager
> Tundo
> Tel: +1-866-9388636 ext. 271
> Cell: +972-54-852229
> Fax: +972-9-8852249
> P.O.B 8420
> Natanya 42505
> Israel
> Site: http://www.tundo.com/
>
>
>
>
> --------------------------------------------------------------
> -------------
> ------------------------------
> Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to
> subscribe or unsubscribe from this list
> ------------------------------
> --------------------------------------------------------------
> -------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
[View Less]
Would that be a way to do a third-party initiated pause when using
FastConnect?
charles
-----Original Message-----
From: Adi Shmul [mailto:adi@tundo.com]
Sent: Thursday, November 30, 2000 6:29 PM
To: h323implementors(a)imtc.org
Subject: FastConnect W/O any OLC - can it be?
Regards
Adi Shmul
Standards & Interoperability Manager
Tundo
Tel: +1-866-9388636 ext. 271
Cell: +972-54-852229
Fax: +972-9-8852249
P.O.B 8420
Natanya 42505
Israel
Site: http://www.tundo.com/
-------------------…
[View More]--------------------------------------------------------
------------------------------
Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to
subscribe or unsubscribe from this list
------------------------------
---------------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Chris,
Clarification:
The examples you give only suggest the RAS parameters and messages that must
be supported when the EP/entity is supporting RAS.
Regards,
charles
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
Sent: Thursday, November 30, 2000 2:56 PM
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 …
[View More]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
"Agboh, Charles" wrote:
>
> Chris,
>
> RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
>
> charles
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 12:49 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> Charles,
>
> > The answer to your first question depends on the capabilities of D.
> > RAS is OPTIONAL so I could have a D device that does not implement RAS.
> > In my last email, the "third-party" would be a C device and
"first-party"
> > would be a D device (second-party is the A device) .
> RUBBISH!
> RAS is NOT optional. See Table 18/H.225.0.
> Besides, how would your crippled H.323 endpoint tell its RAS handler to
send
> the various RAS messages (like for instance ARQ to ask permission to make
a
> call...)?
>
> Regards,
> Chris
>
> >
> > Regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Thursday, November 30, 2000 10:43 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > In your definition of "third-party" registration, consider a scenario
> > involving
> > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
> > gateway/IWF/registering-entity (C) and an entity of some sort on whose
> > behalf C
> > is registering (which we'll call D). Assuming that B is not routing
> > call-signalling, to which entity would A send its "Setup" message in
order
> > to
> > contact D?
> >
> > If the answer to this question is "C", this is well-covered in the
> standard
> > -
> > it is simply that the term "third-party registration" is not used for
it.
> > It
> > is simply viewed as C registering (potentially) lots of aliases. This
> > parallels Tom's second case.
> > If the answer is "D" (parallelling Tom's first case), then D is a very
odd
> > device (it can't be a full H.323 implementation or it would register for
> > itself). Why have a device implementing all of H.323 except gatekeeper
> > registration? After all, D would have to handle all the rest of RAS for
> > itself
> > - what would it be gaining by not registering on its own behalf?
> >
> > In the same scenario, to what entities are you referring, respectively,
as
> > the
> > "third-party" in your latest contribution?
> >
> > PLEASE clarify your definitions of "first-party" and "third-party" in
> cases
> > where you use these terms. I am certain that the ends you are trying to
> > achieve are perfectly possible - and not even that hard. Either will
> > result, I
> > believe, in a brief discussion with early consensus emerging. I believe
> the
> > problems, and the large amount of mail this is generating on this list,
> come
> > about entirely from the use of these terms without anyone understanding
> > exactly
> > what is meant by them.
> >
> > I agree with Tom that once we can agree on terminology we can move on
> quite
> > easily, and thank him for his usual high-quality clear-sighted input.
> >
> > Regards,
> > Chris
> >
> > ------------------------------------
> >
> > The registration feature allows endpoints to bind their identities to
> > transport
> > address(es) at the GK. This is well described in H.323. When an
> endpoint
> > delegates another endpoint to perform this fearture on its behalf the
> > definition in H.323 is not there. The signaling that follows the
> > registration
> > whether, its
> > first or third-party may interrogate this binding. The third-party
> > registration feature can enhance the user experience much more than a
> normal
> > first-party
> > registration. I don't believe that the third-party has to be in the
> > signaling
> > flow that may follow the third-registration. I agree with Tom-PTs
view.
> >
> > Best regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, November 29, 2000 7:39 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Accurate terminology is obviously useful, but in this case, at
least,
> it
> > looks like something people can agree on and then move on. The more
> > important point seems to be the underlying distinction in
> requirements:
> >
> > -- register on behalf of H.323 endpoints
> > -- register on behalf of other endpoints
> > where I use "other" in the sense that the contact address is
> associated
> > with a non-H.323 signalling protocol. Purity is beside the point here
--
> > it's the intention of the contact address that matters. Stating the
> > requirement in this way makes it obvious that the second requirement
> > includes
> > the need to state which protocol the endpoints expects to receive.
> >
> > There is another possibility, of course: use the same mechanism to
> > satisfy
> > all requirements, and allow for the possibility that the endpoint
> > supports multiple protocols. I think the design would be cleaner if
> we
> > took the approach: one contact point, one protocol -- even if it meant
> > repeating the contact information for each protocol a multiprotocol
> > endpoint supports.
> >
> > --
> > 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
--
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
[View Less]
Hi, Chris:
Yes, I do.
Regards,
Radhika
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Thursday, November 30, 2000 12:01 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Cc: Roy, Radhika R, ALCOO
Subject: Re: Third party registration/group registration
All,
A clarification:
I am sure Radhika will agree that when he refers to call setup this includes
the case of incoming call setup as well as that of outgoing call setup!
Regards,
Chris
"Roy, Radhika R, …
[View More]ALCOO" wrote:
>
> Hi, All:
>
> Let me add a little.
>
> An H.323 entity needs to have the capability to support RAS messages.
> However, whether the RAS messages will be used or not before the call
setup
> is up to that entity.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 8: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
>
> "Agboh, Charles" wrote:
> >
> > Chris,
> >
> > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Thursday, November 30, 2000 12:49 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > > The answer to your first question depends on the capabilities of D.
> > > RAS is OPTIONAL so I could have a D device that does not implement
RAS.
> > > In my last email, the "third-party" would be a C device and
> "first-party"
> > > would be a D device (second-party is the A device) .
> > RUBBISH!
> > RAS is NOT optional. See Table 18/H.225.0.
> > Besides, how would your crippled H.323 endpoint tell its RAS handler to
> send
> > the various RAS messages (like for instance ARQ to ask permission to
make
> a
> > call...)?
> >
> > Regards,
> > Chris
> >
> > >
> > > Regards,
> > >
> > > charles
> > >
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > Sent: Thursday, November 30, 2000 10:43 AM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Charles,
> > >
> > > In your definition of "third-party" registration, consider a scenario
> > > involving
> > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
> > > gateway/IWF/registering-entity (C) and an entity of some sort on whose
> > > behalf C
> > > is registering (which we'll call D). Assuming that B is not routing
> > > call-signalling, to which entity would A send its "Setup" message in
> order
> > > to
> > > contact D?
> > >
> > > If the answer to this question is "C", this is well-covered in the
> > standard
> > > -
> > > it is simply that the term "third-party registration" is not used for
> it.
> > > It
> > > is simply viewed as C registering (potentially) lots of aliases. This
> > > parallels Tom's second case.
> > > If the answer is "D" (parallelling Tom's first case), then D is a very
> odd
> > > device (it can't be a full H.323 implementation or it would register
for
> > > itself). Why have a device implementing all of H.323 except
gatekeeper
> > > registration? After all, D would have to handle all the rest of RAS
for
> > > itself
> > > - what would it be gaining by not registering on its own behalf?
> > >
> > > In the same scenario, to what entities are you referring,
respectively,
> as
> > > the
> > > "third-party" in your latest contribution?
> > >
> > > PLEASE clarify your definitions of "first-party" and "third-party" in
> > cases
> > > where you use these terms. I am certain that the ends you are trying
to
> > > achieve are perfectly possible - and not even that hard. Either will
> > > result, I
> > > believe, in a brief discussion with early consensus emerging. I
believe
> > the
> > > problems, and the large amount of mail this is generating on this
list,
> > come
> > > about entirely from the use of these terms without anyone
understanding
> > > exactly
> > > what is meant by them.
> > >
> > > I agree with Tom that once we can agree on terminology we can move on
> > quite
> > > easily, and thank him for his usual high-quality clear-sighted input.
> > >
> > > Regards,
> > > Chris
> > >
> > > ------------------------------------
> > >
> > > The registration feature allows endpoints to bind their identities to
> > > transport
> > > address(es) at the GK. This is well described in H.323. When an
> > endpoint
> > > delegates another endpoint to perform this fearture on its behalf the
> > > definition in H.323 is not there. The signaling that follows the
> > > registration
> > > whether, its
> > > first or third-party may interrogate this binding. The third-party
> > > registration feature can enhance the user experience much more than a
> > normal
> > > first-party
> > > registration. I don't believe that the third-party has to be in the
> > > signaling
> > > flow that may follow the third-registration. I agree with Tom-PTs
> view.
> > >
> > > Best regards,
> > >
> > > charles
> > >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Wednesday, November 29, 2000 7:39 PM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Accurate terminology is obviously useful, but in this case, at
> least,
> > it
> > > looks like something people can agree on and then move on. The more
> > > important point seems to be the underlying distinction in
> > requirements:
> > >
> > > -- register on behalf of H.323 endpoints
> > > -- register on behalf of other endpoints
> > > where I use "other" in the sense that the contact address is
> > associated
> > > with a non-H.323 signalling protocol. Purity is beside the point here
> --
> > > it's the intention of the contact address that matters. Stating
the
> > > requirement in this way makes it obvious that the second requirement
> > > includes
> > > the need to state which protocol the endpoints expects to receive.
> > >
> > > There is another possibility, of course: use the same mechanism to
> > > satisfy
> > > all requirements, and allow for the possibility that the endpoint
> > > supports multiple protocols. I think the design would be cleaner
if
> > we
> > > took the approach: one contact point, one protocol -- even if it meant
> > > repeating the contact information for each protocol a
multiprotocol
> > > endpoint supports.
> > >
> > > --
> > > 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
>
> --
> 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
[View Less]
Paul,
Based on the rule that the SIP-H.323 gateway appears to the endpoints as an
H.323 firewall, then this will work. If there ever is any difference, then
there is a problem
I prefer to keep the "h323" designation.
Bob
-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Wednesday, November 29, 2000 8:33 PM
To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: Draft Status Update
Bob,
I was not suggesting that we use the h323-ID field any …
[View More]differently-- it was
the "h323" field inside the supportedProtocols choice. It is used to
indicate a gateway that gateways to H.323 devices. However, it could serve
just as well to say it gateways to any IP telephony protocol. That's why I
suggested we call it "ipgw".
Whether we do that or add a "sip" field makes no difference to me, but the
latter option may take 2 years.
Paul
----- Original Message -----
From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com>
To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>;
<ITU-SG16(a)mailbag.cps.intel.com>
Sent: Wednesday, November 29, 2000 4:18 AM
Subject: RE: Draft Status Update
> Paul,
>
> I thought that the object of the IWF is to make the mixing of H.323
> terminals and SIP terminals transparent.
>
> However, I could see supporting SIP: URLs in the H.323 URL field along
with
> the H.323 URL. This would be possible under the URL rules for H.323v4. I
> would also expect SIP terminals to support the H.323 URL.
>
> The does not solve the problem of true E.164 Ids or the TEL: URL. A true
> E.164 Id does not allow for a service prefix. In that this is the normal
Id
> for voice calls, it must have a solution. An added problem is "Number
> Portability" which tends to kill number grouping.
>
> I do not accept the concept of hidden usages of any field. Therefor I do
> not support the use of the H.323ID field having a special format that
> indicates a SIP connection. The H.323ID field should remain a free format
> string.
>
> As it was stated, the gateway identifieds as having H.323 protocol is used
> by firewalls doing H.323-H.323. Also voice indicates any gateway support
> voice only connections. These should be mis-used. Adding a new protocol
> type for a gateway would have to wait.
>
> Bob
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
> Sent: Tuesday, November 28, 2000 12:08 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: Draft Status Update
>
>
> Charles,
>
> I have discussed that idea with people before.
>
> I'm certainly open to the idea of adding a "sip" codepoint. However,
since
> H.323v4 was just approved, we'd have to wait for 2 years to get it in
there.
> We might be able to persuade folks to use the "h323" field for IP GWs and
> document that in the H.323 Implementers Guide-- perhaps even changing the
> name in v5 to "ipgw".
>
> Paul
[View Less]
************************************************
First Call For Papers
---------------------
ACIVS'2001
3rd International Conference on
ADVANCED CONCEPTS FOR INTELLIGENT VISION SYSTEMS
Theory and Applications
Baden-Baden (Germany)
July 30 - August 3, 2001
(in conjunction with the 13th Int. Conf. on
Systems Research, Informatics and Cybernetics)
************************************************
* CONFERENCE SCOPE
ACIVS'2001 is the third of a series of conferences focusing on techniques for
…
[View More]building adaptive, intelligent, safe and secure imaging systems.
Papers are sollicited in the areas of image processing, pattern recognition,
compression and algorithm assessment.
Topics include (but are not limited to):
- Image Processing
(adaptive filtering and image restoration, adaptive segmentation, model-based
algorithms, learning and nonlinear optimization, recurrent networks,
multiresolution and scale-space theory, fractals and multifractals).
- Pattern Recognition
(statistical and structural pattern recognition, robust matching and parsing
algorithms, application of automata and grammars).
- Image and Video Compression Algorithms
(wavelets, vector quantization, fractals, hybrid techniques, semantic image
compression, watermarking).
- Image Quality and Algorithmic Performance Evaluation
(empirical evaluation techniques, image and video quality metrics [objective
and perceptually based metrics], methods [ROC curves, etc.] and professional
applications [medical, military, etc.]).
* PROGRAM COMMITTEE
Scott Acton, University of Virginia, Charlottesville, USA.
Sos S. Agaian, University of Texas, San Antonio, USA.
Mauro Barni, Universita' di Siena, Italy.
Jacques Blanc-Talon, CTA, Arcueil, France.
Philippe Bolon, LAMII, University of Savoie, Annecy, France.
Don Bone, Mediaware Solutions, Canberra, Australia.
Adam Borkowski, IFTP, Warsaw, Poland.
Nikolaos Bourbakis, SUNY, Binghamton, USA.
Horst Bunke, IAM, Bern, Switzerland.
Jennifer Davidson, Iowa State University, Ames, USA.
Edward J. Delp, Purdue University, USA.
Georgy Gimel'Farb, University of Auckland, New Zealand.
Daniele Giusto, University of Cagliari, Italy.
Haomin Jin, University of Tokyo, Japan.
Itsuo Kumazawa, Tokyo Institute of Technology, Japan.
Hideo Kuroda, Nagasaki University, Japan.
Bruce Litow, James Cook University, Townsville, Australia.
Hitoshi Maekawa, Saitama University, Japan.
Anamitra Makur, Indian Institute of Science, India.
Masoud Mohammadian, University of Canberra, Australia.
Wojciech S. Mokrzycki, IPIPAN, Warsaw, Poland.
Annick Montanvert, UPMF, Grenoble, France.
Naoya Ohta, Gunma University, Kiryu, Japan.
Andrew P. Paplinski, Monash University, Melbourne, Australia.
Marcin Paprzycki, University of Southern Mississippi, USA.
Fernando Pereira, Instituto Superior Técnico, Lisboa, Portugal.
Sylvie Philip, ENSEA, Cergy, France.
Wilfried Philips, Vakgroep TELIN, Gent, Belgium.
Moshe Porat, Dept. of Electrical Eng., Technion, Israel.
Dan Popescu, CSIRO, Canberra, Australia.
Georges Stamon, IARFA, Paris VI University, France.
Wojciech Szpankowski, Purdue University, USA.
Frederic Truchetet, Le2i, Le Creusot, France.
Juan Jose Villanueva, CVC Univ. Autonoma de Barcelona, Spain.
* IMPORTANT DATES
Expression of interest: December 22, 2000
Tutorials proposal: December 22, 2000
Notification of tutorials acceptance: January 26, 2001
Deadline for paper submission: March 16, 2001
Notification of paper acceptance: May 4, 2001
Camera-ready manuscripts: June 1, 2001
Conference date: July 30/August 4, 2001
* EXPRESSION OF INTEREST
Any person who intends to participate is invited to fill and send a reply
card available at: http://www.etca.fr/CTA/ACIVS01
* CONFERENCE WEB SERVER
Information about the conference can be found at:
http://www.etca.fr/CTA/ACIVS01
* TUTORIAL SUBMISSION
Tutorials are sollicited on the following topics:
- adaptive segmentation
- pattern recognition
- video compression
- watermarking
- algorithmic performance evaluation
* PAPER SUBMISSION AND REVIEW PROCESS
All submissions will be reviewed by at least 2 members of the International
Programme Committee; additional reviewers may be consulted if needed. The
papers have to provide sufficient information about the background to the
problem, clearly indicate the original contribution, evaluate the results,
draw conclusions and provide adequate references.
Full regular papers are 5 pages long (including figures) in times 11pt, A4.
There will be an extra cost for any additional page.
We strongly recommend the use of LaTex format; the style macros will be
available soon at the conference web server (see above). Word documents or
other formats are also accepted, but only accompanied by the corresponding
PostScript files. Make sure that PS files are kept within reasonable limits.
The papers can be sent by e-mail to either member of the steering committee.
* PROCEEDINGS
All accepted papers will be published in the Conference Proceedings.
Selected papers will be considered for publication in a book series.
* STEERING COMMITTEE
Dr Jacques Blanc-Talon Dr Dan Popescu
Geographie-Imagerie-Perception Mathematical and Information Science
CTA/GIP CMIS/CSIRO
16 bis, Av. Prieur de la cote d'or, GPO Box 664
94114, Arcueil, FRANCE Canberra, ACT 2601, AUSTRALIA
Jacques.Blanc-Talon(a)etca.fr Dan.Popescu(a)cmis.csiro.au
------------------------------------------------------------
Prof. Dr. D.D.Giusto
------------------------------------------------------------
e-mail: ddgiusto(a)unica.it - ddgiusto(a)ieee.org
url: http://www.diee.unica.it/~pytheas
ph: +39-070-675-5896/5866 - fax: +39-070-675-5900
mobile: +39-348-8757022 (RAM_CNIT: 302)
mail: Department of Electrical and Electronic Engineering
University of Cagliari, Piazza d'Armi, Cagliari 09123 Italy
------------------------------------------------------------
Die Strassen teilen sich auf, wie die Spitzen eines Sternes,
Und jede ist der Heimweg. (H.Hesse)
------------------------------------------------------------
[View Less]
Hi, All:
Let me add a little.
An H.323 entity needs to have the capability to support RAS messages.
However, whether the RAS messages will be used or not before the call setup
is up to that entity.
Best regards,
Radhika
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
Sent: Thursday, November 30, 2000 8: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, …
[View More]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
"Agboh, Charles" wrote:
>
> Chris,
>
> RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
>
> charles
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 12:49 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> Charles,
>
> > The answer to your first question depends on the capabilities of D.
> > RAS is OPTIONAL so I could have a D device that does not implement RAS.
> > In my last email, the "third-party" would be a C device and
"first-party"
> > would be a D device (second-party is the A device) .
> RUBBISH!
> RAS is NOT optional. See Table 18/H.225.0.
> Besides, how would your crippled H.323 endpoint tell its RAS handler to
send
> the various RAS messages (like for instance ARQ to ask permission to make
a
> call...)?
>
> Regards,
> Chris
>
> >
> > Regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Thursday, November 30, 2000 10:43 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > In your definition of "third-party" registration, consider a scenario
> > involving
> > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
> > gateway/IWF/registering-entity (C) and an entity of some sort on whose
> > behalf C
> > is registering (which we'll call D). Assuming that B is not routing
> > call-signalling, to which entity would A send its "Setup" message in
order
> > to
> > contact D?
> >
> > If the answer to this question is "C", this is well-covered in the
> standard
> > -
> > it is simply that the term "third-party registration" is not used for
it.
> > It
> > is simply viewed as C registering (potentially) lots of aliases. This
> > parallels Tom's second case.
> > If the answer is "D" (parallelling Tom's first case), then D is a very
odd
> > device (it can't be a full H.323 implementation or it would register for
> > itself). Why have a device implementing all of H.323 except gatekeeper
> > registration? After all, D would have to handle all the rest of RAS for
> > itself
> > - what would it be gaining by not registering on its own behalf?
> >
> > In the same scenario, to what entities are you referring, respectively,
as
> > the
> > "third-party" in your latest contribution?
> >
> > PLEASE clarify your definitions of "first-party" and "third-party" in
> cases
> > where you use these terms. I am certain that the ends you are trying to
> > achieve are perfectly possible - and not even that hard. Either will
> > result, I
> > believe, in a brief discussion with early consensus emerging. I believe
> the
> > problems, and the large amount of mail this is generating on this list,
> come
> > about entirely from the use of these terms without anyone understanding
> > exactly
> > what is meant by them.
> >
> > I agree with Tom that once we can agree on terminology we can move on
> quite
> > easily, and thank him for his usual high-quality clear-sighted input.
> >
> > Regards,
> > Chris
> >
> > ------------------------------------
> >
> > The registration feature allows endpoints to bind their identities to
> > transport
> > address(es) at the GK. This is well described in H.323. When an
> endpoint
> > delegates another endpoint to perform this fearture on its behalf the
> > definition in H.323 is not there. The signaling that follows the
> > registration
> > whether, its
> > first or third-party may interrogate this binding. The third-party
> > registration feature can enhance the user experience much more than a
> normal
> > first-party
> > registration. I don't believe that the third-party has to be in the
> > signaling
> > flow that may follow the third-registration. I agree with Tom-PTs
view.
> >
> > Best regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, November 29, 2000 7:39 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Accurate terminology is obviously useful, but in this case, at
least,
> it
> > looks like something people can agree on and then move on. The more
> > important point seems to be the underlying distinction in
> requirements:
> >
> > -- register on behalf of H.323 endpoints
> > -- register on behalf of other endpoints
> > where I use "other" in the sense that the contact address is
> associated
> > with a non-H.323 signalling protocol. Purity is beside the point here
--
> > it's the intention of the contact address that matters. Stating the
> > requirement in this way makes it obvious that the second requirement
> > includes
> > the need to state which protocol the endpoints expects to receive.
> >
> > There is another possibility, of course: use the same mechanism to
> > satisfy
> > all requirements, and allow for the possibility that the endpoint
> > supports multiple protocols. I think the design would be cleaner if
> we
> > took the approach: one contact point, one protocol -- even if it meant
> > repeating the contact information for each protocol a multiprotocol
> > endpoint supports.
> >
> > --
> > 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
--
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
[View Less]
Charles,
Only if a there is no Gateway!
Ries
> -----Original Message-----
> From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM]
> Sent: Thursday, November 30, 2000 1:10 PM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: Third party registration/group registration
>
>
> Chris,
>
> RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
>
> charles
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> …
[View More]Sent: Thursday, November 30, 2000 12:49 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
>
> Charles,
>
> > The answer to your first question depends on the capabilities of D.
> > RAS is OPTIONAL so I could have a D device that does not
> implement RAS.
> > In my last email, the "third-party" would be a C device and
> "first-party"
> > would be a D device (second-party is the A device) .
> RUBBISH!
> RAS is NOT optional. See Table 18/H.225.0.
> Besides, how would your crippled H.323 endpoint tell its RAS
> handler to send
> the various RAS messages (like for instance ARQ to ask
> permission to make a
> call...)?
>
> Regards,
> Chris
>
> >
> > Regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > Sent: Thursday, November 30, 2000 10:43 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > In your definition of "third-party" registration, consider
> a scenario
> > involving
> > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
> > gateway/IWF/registering-entity (C) and an entity of some
> sort on whose
> > behalf C
> > is registering (which we'll call D). Assuming that B is not routing
> > call-signalling, to which entity would A send its "Setup"
> message in order
> > to
> > contact D?
> >
> > If the answer to this question is "C", this is well-covered in the
> standard
> > -
> > it is simply that the term "third-party registration" is
> not used for it.
> > It
> > is simply viewed as C registering (potentially) lots of
> aliases. This
> > parallels Tom's second case.
> > If the answer is "D" (parallelling Tom's first case), then
> D is a very odd
> > device (it can't be a full H.323 implementation or it would
> register for
> > itself). Why have a device implementing all of H.323
> except gatekeeper
> > registration? After all, D would have to handle all the
> rest of RAS for
> > itself
> > - what would it be gaining by not registering on its own behalf?
> >
> > In the same scenario, to what entities are you referring,
> respectively, as
> > the
> > "third-party" in your latest contribution?
> >
> > PLEASE clarify your definitions of "first-party" and
> "third-party" in
> cases
> > where you use these terms. I am certain that the ends you
> are trying to
> > achieve are perfectly possible - and not even that hard.
> Either will
> > result, I
> > believe, in a brief discussion with early consensus
> emerging. I believe
> the
> > problems, and the large amount of mail this is generating
> on this list,
> come
> > about entirely from the use of these terms without anyone
> understanding
> > exactly
> > what is meant by them.
> >
> > I agree with Tom that once we can agree on terminology we
> can move on
> quite
> > easily, and thank him for his usual high-quality
> clear-sighted input.
> >
> > Regards,
> > Chris
> >
> > ------------------------------------
> >
> > The registration feature allows endpoints to bind their
> identities to
> > transport
> > address(es) at the GK. This is well described in H.323. When an
> endpoint
> > delegates another endpoint to perform this fearture on its
> behalf the
> > definition in H.323 is not there. The signaling that follows the
> > registration
> > whether, its
> > first or third-party may interrogate this binding. The third-party
> > registration feature can enhance the user experience much
> more than a
> normal
> > first-party
> > registration. I don't believe that the third-party has to
> be in the
> > signaling
> > flow that may follow the third-registration. I agree with
> Tom-PTs view.
> >
> > Best regards,
> >
> > charles
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, November 29, 2000 7:39 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Third party registration/group registration
> >
> > Accurate terminology is obviously useful, but in this
> case, at least,
> it
> > looks like something people can agree on and then move on. The more
> > important point seems to be the underlying distinction in
> requirements:
> >
> > -- register on behalf of H.323 endpoints
> > -- register on behalf of other endpoints
> > where I use "other" in the sense that the contact address is
> associated
> > with a non-H.323 signalling protocol. Purity is beside the
> point here --
> > it's the intention of the contact address that matters.
> Stating the
> > requirement in this way makes it obvious that the second requirement
> > includes
> > the need to state which protocol the endpoints expects
> to receive.
> >
> > There is another possibility, of course: use the same
> mechanism to
> > satisfy
> > all requirements, and allow for the possibility that the endpoint
> > supports multiple protocols. I think the design would
> be cleaner if
> we
> > took the approach: one contact point, one protocol -- even
> if it meant
> > repeating the contact information for each protocol a
> multiprotocol
> > endpoint supports.
> >
> > --
> > 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
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
