Revised H.323 URL document

[Callaghan, Robert]

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! :-)) 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 at ICN.Siemens.com
------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000911/3b968d47/attachment-0004.html>