Revised H.323 URL document

Orit Levin orit at radvision.com
Mon Sep 11 17:45:25 EDT 2000


Bob!

Hopefully, Paul will formulate the minimal text for H.323v4.
After it is formulated, I will tell, if I can agree to it.
As for today, I do not agree to it, because it will limit the H.323 future
in a non-backward compatible manner.

For the November meeting, I will formulate the draft for the "Annex O".
Hopefully, after the H.323v4 decision, we will find time to go over the text
and discuss the proposed added features during the meeting, rather then
repeating ourselves on the mailing list.

Regards,
Orit.
  -----Original Message-----
  From: Mailing list for parties associated with ITU-T Study Group 16
[mailto:ITU-SG16 at MAILBAG.INTEL.COM]On Behalf Of Callaghan, Robert
  Sent: Monday, September 11, 2000 5:06 PM
  To: ITU-SG16 at MAILBAG.INTEL.COM
  Subject: Re: Revised H.323 URL document


  Orit,



  You still do not hear what I am saying.



  So I repeat, in order to have something for November;



    a.. 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.


    a.. 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.


    a.. 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 at ICN.Siemens.com

  ------------------------------------------------------------------



  -----Original Message-----
  From: Orit Levin [mailto:orit at radvision.com]
  Sent: Monday, September 11, 2000 3:01 PM
  To: Callaghan, Robert
  Cc: ITU-SG16 at 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 at radvision.com

  -----Original Message-----
  From: Callaghan, Robert <Robert.Callaghan at icn.siemens.com>
  To: 'Orit Levin' <orit at radvision.com>
  Cc: ITU-SG16 at mailbag.cps.intel.com <ITU-SG16 at 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 at ICN.Siemens.com

  ------------------------------------------------------------------



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


More information about the sg16-avd mailing list