Orit,
You
still do not hear what I am saying.
So
I repeat, in order to have something for
November;
- The
H.323 URL is used as an H.323 alias.
The means that it has all of the properties of an H.323 alias, and
nothing beyond these properties.
To expand this, this alias is used in ARQs LRQs, SETUP, etc. messages
exactly the same as any other alias.
It is not used for any purpose beyond that for which all other
aliases are used in H.323.
- There
are no new functions, features, or capabilities added to H.323v4 based on
the addition of the H.323 URL as a new alias
type.
- Any
other uses for the H.323 URL are for future
study.
Can
we agree to these statements for the H.323 URL in
H.323v4?
If
we agree on this, can the URL format be formulated to support these
statements?
If
the URL can be formulated, can it be submitted and approved by IETF before
November?
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: Monday, September 11, 2000 3:01
PM
To: Callaghan,
Robert
Cc:
ITU-SG16@mailbag.cps.intel.com
Subject: Re: Revised H.323 URL
document
Bob!
Below is
my take on the current situation.
The three of us
have the following different views on the possible use of the H.323
URL.
If I try to map
them into the H.323 "classic" picture of EP1---GK1-------GK2---EP2 . The GKs
are optional. If exist, they may contain BE as well.
I understand
the following:
Bob:: indirect:
EP1---GK1; direct: EP1 --------Zone2
Paul:: indirect:
Zone1-------GK2; direct: Zone1------EP2
Orit::
Zone1-------Zone2 (with H.225.0 Q.931, LRQ or Annex G) possible between them
for a specific call.
We "agree" that
all of the scenarios should be allowed.
"It seems like"
we disagree about the priority/emergency of each of the
applications above.
Saying that,
I don't like very much to define a solution based on the
"perceived priority" of the applications.
My proposed
approach is, above all, guided by the fact, that the DESTINATION is
the one to design its URL scheme, implement and, eventually, publish its
URL(s).
The URL
- has a key (I.e.
the DNS domain) for IP resolution only
- says what is the
first H.323 protocol to contact this IP address, all the scenarios above are
addressed.
If the DNS
portion (I.e. "host") is not present, it automatically means, that the local
(pre-configured or RAS discovered) gatekeeper will resolve the "user" name
(using RAS, Annex G, another DNS lookup, other means). It is an exception, but
it is still consistent with the approach above (The local zone is responsible
for the URL scheme, it published.)
The bottom
line: I agree with the last proposal for H.323v4:
No parameters
at all. The default: H.225.0/Q.931/Setup with its default TCP port.
Paul?
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: 'Orit Levin' <orit@radvision.com>
Cc: ITU-SG16@mailbag.cps.intel.com
<ITU-SG16@mailbag.cps.intel.com>
Date: Monday, September 11, 2000 1:53
PM
Subject: RE: Revised H.323
URL document
Orit,
Let us
try to focus on a few points first:
(These are snippets from the
thread.)
OL: Are you
interested in efficiently running H.323 over the
Internet?
RC: Yes! For clarification, this is the H.323
as defined in H.323v4 and H.225.0v4.
For the November decision, there should not be any extensions, implicit
or explicit.
OL:
The picture, in my mind, is different from yours and fits the "traditional"
H.323. For every H.323 call, logically there are (at least) two GKs: source
and destination. (Physically, both of them are optional, based on the "mode"
policy inside the corresponding H.323
zones.)
RC: I agree with your model of two
endpoint each with an optional GKs based on zone policies. The source and destination policies
are independent from each other.
I don't know how this is different, as you
state.
OL:
By
specifying in H323-URL the "mode" of operation between the source EP and a GK,
you propose to use the URL for "publishing" the relations between the EP and
"ITS" GK PER DESTINATION! It is, indeed, very different from the H.323 today.
Moreover, you implicitly introduce a concept of a "source" GK, being
re-defined each time BY THE DESTINATION. (This case may be considered as an
additional application for the H.323 URL)
RC: I make so such
assumption. In the "Direct"
model, I assume that the given address is directly callable. The routing model is not specified nor
assumed. If the term "Direct" is
a problem in that the term overlaps with the routing model then the use of
"Callable" would be fine. The use
of the DNS service to convert the DNS domain to an IP address is assumed. This is also the only use of the DNS
server. No DNS records beyond the
"A" record will be used. If the
initial use of the H.323 URL could be limited to this
service.
RC: The use of the "Indirect" or "non
callable" form has bothered me in that its use is not clearly defined. My view is that this was a means to
access an H.323 repository to obtain the true address. Apparently there are other views. Therefore I suggest that a solution
would be to drop this form for now.
OL:
The natural use of URLs is between the zones/domain. For H.323, it is an
OPTION, what kind of address resolution to propose and use. The beauty of
the URL approach is that the DESTINATION provides an option to be reached
using the DNS lookup, if it chooses so and populates properly the
DNS.
RC:
The may be beautify for some; but it is definitely new. I know of nothing in H.323v4 that
describes the procedures and rules for this type of address resolution. This can be discussed as part of Annex
O, after the decision on H.323v4.
OL: We don't have to
agree on the mailing list. We can spend more then one meeting in order to
reach "the consensus". In that case, I would support the inclusion
of the minimal H323-URL only (without any parameters and without the PORT
number) towards the H.323v4.
RC: I agree that it
is not possible to agree to a complex solution on the mailing list. However, I hope that we can agree to a
simple URL without any parameters or port (ouch! J) where this URL is
the actual address to be used in a SETUP message. This should not change anything in
H.323 including the use of the GK.
I hope that this
helps.
Bob
------------------------------------------------------------------
Robert
Callaghan
Siemens
Enterprise Networks
Tel:
+1.561.923.1756
Fax: +1.561.923.1403
Email:
Robert.Callaghan@ICN.Siemens.com
------------------------------------------------------------------