Paul,
In my mind, Direct meant callable and Indirect meant not callable. In either case the DNS portion of the
URL identified the target entity for the initial contact. I have no problem with the use of a DNS
server providing the IP address of this entity through the use of the A
record. However, this is the limit
to the use of DNS records, at this time.
Until the procedures are resolve, there can be no use of service records
etc.
As to a domain being “administrative” or “DNS” – the DNS portion of the
URL has to relate to the DNS domain in that this is the definition of DNS. However, it may be possible to have
resolution of the URL addresses be an extension of Annex G so that the
information exchange between administrative domains may be used to resolve the
address. However, this is future.
Bob
------------------------------------------------------------------
Robert
Callaghan
Siemens
Enterprise Networks
Tel:
+1.561.923.1756 Fax:
+1.561.923.1403
Email: Robert.Callaghan@ICN.Siemens.com
------------------------------------------------------------------
-----Original
Message-----
From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
Sent: Sunday, September 10, 2000
12:12 AM
To: ITU-SG16@mailbag.cps.intel.com
Subject: Re: Revised H.323 URL
document
Bob and
Orit,
Indeed,
it would appear that this "proto" or "mode" parameter is
still a bit contentious.
Let me
make a few comments.. my immediate goal is to see H.323v4 brought to
Decision. We can haggle over Annex O (which will contain all of the
specific procedural text) later on. I agree with Bob-- we will have a few
of these meetings, I am sure.
There
is nothing in the URL scheme itself that would prevent a Gatekeeper or an
endpoint from utilizing DNS. When the mode is specified as
"direct", we specified that the hostname resolves has
an associated 'A' record in DNS. However, if I give you h323:paulej@packetizer.com, you can't assume
that 'packetizer.com' will have an 'A' record-- and if it does, it may not
contain H.323 entity (endpoint, GK, or BE). So, in the
"indirect" mode (the default), the endpoint must somehow turn this
URL into a callable address. Now, the procedure for this may involve DNS
or it may not. The text I last sent out suggested that this is the
"domain name", but I did not say DNS or "administrative domain
name". I can imagine that either may be utilized, but I also prefer
that the "domain name" refer to a DNS domain name and would also like
to propose that the "domain name" mentioned in this section
be qualified with "DNS domain name": that might not sit well--
Bob?
How
about this: what if I remove the text that says that "indirect" means
that "an endpoint shall use a Gatekeeper to resolve the
address". Instead, I will say "the mode value indirect
indicates that the address does not refer to a callable H.323
entity. The procedure for resolving such an address is
for further study." Making this change does not prevent a Gatekeeper
from being involved and it also does not prevent an endpoint from doing some
type of direct resolution. Perhaps this will get us past this-- we'll
debate this when we get to Annex O.
Orit,
one thing you say over and over again is "direct" and
"routed". I never used the word "routed"-- do not
mistake "indirect" for "routed". The word
"direct" versus "indirect" merely indicated that the entity
is callable or not.
Perhaps
this: in addition to making the above change, we change "mode" to "callable".
The URL will then take this form:
h323:paulej@packetizer.com;callable=no
or
h323:paulej@paris.packetizer.com;callable=yes
The
default would be "callable=no". This equates to the same thing
as "mode=direct" and "mode=indirect", but perhaps it's
clearer? (Or perhaps not... I personally prefer
"mode=[in]direct").
Paul
----- Original Message -----
To: 'Orit Levin' ; Paul E.
Jones
Cc: Mailing list for parties associated with
ITU-T Study Group 16 (E-mail)
Sent: Friday, September 08,
2000 4:45 PM
Subject: RE:
Re: Revised H.323 URL document
Orit,
Based on
this email, we have not agreement at all.
1)
I am not interest at all in developing an addressing scheme for the sole
reason that it mimics the addressing schemes used by SIP. SIP is very oriented towards the
concept of domains defined by DNS and a user in that domain. H.323 is oriented towards administration
domains defined by one or more gatekeepers and users attached to those
gatekeepers. The only commonality
is that a gatekeeper can be a server with a name defined by DNS. These distinctions must remain.
2)
It is unacceptable to force the implementation of annex G on any
endpoint, gatekeeper or administrative domain. Therefore the differentiation between the use of Annex G or
the use of LRQ should not known to the originating endpoint. The differentiation should be that this
address defines the destination endpoint (direct relationship) or it defines a
source for resolving the destination endpoint address (indirect).
In my
view, in the direct relation a SETUP message is routed towards the entity
defined by the DNS where the user portion is resolved. This may be direct routed or gatekeeper
routed, it does not matter. The
endpoint defined by the DNS may be a gatekeeper or the endpoint itself where the
user portion defines one of multiple users on that endpoint.
For the
indirect relationship, the endpoint must resolve the address of the destination
address before sending the SETUP message. Based on H.323 procedures, the endpoint sends
ARQ to its GK. How the GK resolves
the address is within the capabilities of the GK. It may use Annex G, it this is possible. Or, it may fall back to LRQ to the
entity specified by the DNS name.
3)
The definition of an H.323 URL cannot be the vehicle to implicitly
define new procedures for address resolution. If a new procedure for address resolution is to be defined,
it must be explicit, and it must be clear. These requirements have not been realized. I have seen no procedural text that has
full agreement. I have seen Annex
O as a working document, but this is a year from closure. I expect to have many discussions on
this subject in future meetings (note the plural). The H.323 URL we have for November must support the existing
H.323 procedures without any implicit extension or modification.
I think
that Paul’s proposal meets the requirements that I have stated.
Where does
this leave us now?
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax:
+1.561.923.1403
Email: Robert.Callaghan@ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Orit Levin
[mailto:orit@radvision.com]
Sent: Friday, September 08, 2000
3:57 PM
To: Paul E. Jones; Robert (Bob)
Callaghan
Subject: Re: Re: Revised H.323 URL
document
Hello
Paul and Bob!
I
prepared the following "speech" for the mailing list, but it is
definitely better to try to understand each other first...
---------------------------------------
I
hate to disappoint you, but I would strongly disagree with the proposed
"mode" terminology.
I
will try to explain below, why it does not fit the URL concept.
1.
The MAIN purpose of URL is to use the Internet DNS Infrastructure
for SERVICE+ADDRESS resolution ACROSS the DOMAINS.
(The
use of the "user-only" URL is [just] a possible additional feature.)
2.
The H.323 "direct vs. routed" concept specifies the relations
between an End Point and ITS Gatekeeper. It is an local policy
issue WITHIN their zone.
Today,
according to H.323 specification, the real flavor of the operational mode
in the DESTINATION zone is UNKNOWN (and irrelevant) to the originator
of the call.
Not
mentioning the future possible GK decomposition!...
3.
Following the proposed "mode" terminology, I guess,
"routed" would mean "LRQ" or "Access Request" and
"direct" would mean "Setup". In reality, the LRQ would lead
to the "direct call" and the Setup would lead to the "routed
call". And how to distinguish between the all three?
4.
The INTER-ZONE communication haven't been solidly defined so
far. (LRQ ? Annex G?)
The INTER-DOMAIN
communication is the subject of H.225.0 Annex G.
The
URL approach is an OPTION for all of the "intra" and
"inter" H.323 Zone and H.323 Domain cases.
It may
be used as a first lookup, before the LRQ or Annex G are performed.
It may
also have an overlapping functionality with LRQ and with very specific PARTS of
Annex G.
The
relations between the H.323 URL and H.225.0 "Annex G" are very
close to those of the SIP-URL and TRIP in a "SIP system".
Both have their uses and complement each other.
5.
The proposal is to have a possibility to "publish", using the URL,
the first procedure, to be issued towards the destination
"domain".
By
its nature, it is not an issue for standardization. It is a policy of the
destination domain, which also is responsible for the URL itself.
The
first procedure (i.e. the "method") required for establishing of a
specific call across domains/zones can be either of the following:
-
H.225.0 Annex G/AccessRequest
-
H.225.0/LRQ
-
H.225.0/CALL SETUP
Once, the
first message is issued towards the destination (which is a result of DNS
lookup using the URL), the rest of the procedures are, indeed, very
well defined by H.323 and H.225.0 Annex G all together.
Best
Regards,
Orit
Levin
RADVision Inc.
575 Corporate Drive Suite 420
Mahwah, NJ 07430
Tel: 1 201 529 4300 (230)
Fax: 1 201 529 3516
www.radvision.com
orit@radvision.com
-----Original Message-----
From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM>
To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM>
Date: Thursday, September 07, 2000
8:17 AM
Subject: Re: Revised H.323 URL
document
Paul,
I definitely like
"mode" as a replacement for "protocol." It clearly represents the required
procedure without over doing details.
I think that we got it.
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax:
+1.561.923.1403
Email: Robert.Callaghan@ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Paul E. Jones
[mailto:paulej@acm.org]
Sent: Wednesday, September 06, 2000
11:20 PM
To: Robert Callaghan; Orit Levin;
ITU-SG16@mailbag.cps.intel.com
Subject: Revised H.323 URL
document
Orit, Bob, et al,
Attached is the revised section covering the syntax of the H.323
URL. This (I hope) includes all of the changes we have discussed so
far. I am not sure that we settled on the "mode" parameter, but
I made the change here in this document-- feedback is welcome.
Best Regards,
Paul