Revised H.323 URL document

Callaghan, Robert Robert.Callaghan at icn.siemens.com
Fri Sep 8 16:45:35 EDT 2000


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 at ICN.Siemens.com
------------------------------------------------------------------
 
-----Original Message-----
From: Orit Levin [mailto:orit at 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 <http://www.radvision.com> 
orit at radvision.com <mailto:orit at radvision.com> 
-----Original Message-----
From: Callaghan, Robert < Robert.Callaghan at ICN.SIEMENS.COM
<mailto:Robert.Callaghan at ICN.SIEMENS.COM> >
To: ITU-SG16 at MAILBAG.INTEL.COM <mailto:ITU-SG16 at MAILBAG.INTEL.COM>  <
ITU-SG16 at MAILBAG.INTEL.COM <mailto:ITU-SG16 at 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 at ICN.Siemens.com
------------------------------------------------------------------
 
-----Original Message-----
From: Paul E. Jones [mailto:paulej at acm.org]
Sent: Wednesday, September 06, 2000 11:20 PM
To: Robert Callaghan; Orit Levin; ITU-SG16 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000908/4f5bd41a/attachment-0004.html>


More information about the sg16-avd mailing list