Third party registration/group registration

Paul Long plong at PACKETIZER.COM
Fri Dec 1 09:07:23 EST 2000


Oh, yeah, one other thing. Decomposition like this (unlike H.248) is totally
proprietary and any one subcomponent of the decomposed entity may not be
complaint. In particular, an EP which relies on another entity, e.g., IWF,
for RAS is not compliant by itself, but the composite EP functionality of
the EP+IWF(RAS) is compliant.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Paul Long [mailto:plong at]
Sent: Friday, December 01, 2000 7:31 AM
Subject: Re: Third party registration/group registration


Gettin' closer.

Re Q2: I simply can't justify making the user wait several seconds for a
discovery that will always fail in a system without a gatekeeper before he
or she can place or answer each and every call. Can you? Therefore, the user
should be able to turn off RAS.

Re Q3: I agree with you, except that with some endpoints the user may then
turn off RAS and place or answer calls without RAS. Note that the typical
user will most likely not do this, since at least placing a call without a
gatekeeper would require more knowledge than the average user posseses,
e.g., the IP address of the called party.

Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there is
something called the "as if" rule. Applying it here, if the system
experiences consistent behavior from a possibly decomposed entity that is
acting "as if" it were a corporate entity, it is compliant IMO. Who cares
where messages originate as long as the effect is the same? In a different
way, the "as if" rule is what allows routing gatekeepers to do what they
do--they can fiddle with messages streams all they want as long as they
maintain consistency "as if" the message streams were originating from a
compliant endpoint.

Note that when I say, "user," I mean either the actual user of the endpoint
or possibly an administrator of the system. I think it's perfectly
reasonable to make the use of RAS an administrated setting.

Paul Long
ipDialog, Inc.

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list