Paul,
See below.
Bob
------------------------------------------------------------------
Robert
Callaghan
Siemens Enterprise
Networks
Tel:
+1.561.923.1756 Fax: +1.561.923.1403
Email: Robert.Callaghan@ICN.Siemens.com
------------------------------------------------------------------
(0) The use of
url means the "address resolution" is done (by the local GK) using
the DNS, not RAS! This is why the "user only" url of H.323, is really
an exceptional case. It is a question, if we want to keep it within the
url. It lets the local (source) GK know, that the "address resolution"
procedure should performed by other, then DNS, means. The
"protocol" means: the signaling H.323 protocol to contact the (next
hop towards the) destination, after the IP address had been
resolved.
(0) I will
remove the reference to RAS and expect to see an explicit description of the
procedure in Annex O. What I would expect is that the hostport
part will resolve to a GK to which LRQ messages are directed.
[RWC] Now I am confused. I thought that DNS was used to locate the
resolution server. Then LRQ(RAS) was used
to communicate with that server to resolve the address of the user. The server doing the address resolution may
not be involved in the final connections.
(1) I
disagree that it is the exception. I would contend that calling a
specific machine would be the exception. Sure, one can call and endpoint
directly, but that's not typical. It is in testing and development
environments, but in production environments, users enter telephone
numbers. Also, I can imagine intranets where the h323 URL might be
used. At work, I might post a page with "h323:paulej", but I
would never post "h323:@cisco.com". However, the latter is allowed,
of course. What I do not want is "h323:paulej@"
on a web page. That's ugly, in my opinion. I realize that the SIP
folks chose that, but it seems illogical to me.
[RWC] I do not see any relationship between an URL
and a telephone number. If a user
enters a telephone number the connection should be established using either the
dialedDigits alias or the partyNumber alias not the URL-id alias. For me, the URL user should be a name type structure
like in email users. This allows for a number
as a name but not as a telephone number.
I do not accept the SIP and ENUM concept where telephone numbers are
funny names with a default domain for DNS. In fact, I think that this will not work due to difficulties with
administration ownership of telephone numbers.
[RWC] I do agree
that user only will be an exception because it forces the use of a default domain
for DNS. It is not likely that there
will be universal default domain.
(2) If
I provided "h323:@192.168.1.1;proto=q931", a device should assume
that it can reach it on the default 1720 port or the default Annex E port (as
described in Annex E). If, however, I use a different port like
"h323:@192.168.1.1:2500;proto=q931", I would say that Annex E is out
of the picture. That is another reason why I believe the first step to
resolution should be through a Gatekeeper. The gatekeeper can not only
resolve the address, but also indicate any non-standard ports, including both
the TCP and Annex E transport information.
[RWC] In this case the endpoint that wished to use
Annex E must support the requirement of Annex E that requires the ability to
fall back to TCP.