Bob and others,
Please see my comments inline:
- The
default protocol should be mandatory.
In this case, flexibility kills
interworking.
Agreed.
- The
port should be specified as belonging the specified
protocol.
What do you mean? Are you in favor of this:
or do you want this:
- For
protocol, use “h225rs” or “h323rs” instead of “ras”. This controls the confusion with the
dial-in protocol know as RAS.
- For
protocol, use “h225cs” or “h323cs” instead of “q931”. This controls the confusion with
real Q.931 For
protocol, use “h225ar” or “h323ar” instead of
“annex-g”.
I really like the use of "ras", even though there are
conflicts in other contexts. However, I agree that q931 is not really
ideal. How about these: lrq, setup,
ar (for AccessRequest)? So rather than specifying a protocol, we specify
the message to use?
Or how about this-- make it easier for those not familiar with
the protocols. Specify the type of device:
Or dev=ep or dev=be
The software/hardware can then determine the protocol.
This might be the best solution, since "h323" is supposed to represent the
protocol in the first place.
- The
specification of “ras” belonging to LRQ is limiting. For me, the first contact is over
ARQ to my GK. Then the GK may
use LRQ or any other means to resolve the address. From this view point, there is no
difference between “ras” and “annex-g”.
If we just specify the type of device the URL is associated
with it will resolve this issue.
- Do
we need annex-f to be specified as a protocol? It appears to me that we have this
need.
We could add "dev=a-set" as an option (audio SET), but I'm not
fond of that idea. I suppose it might be useful in the enterprise
environment where one may, indeed, have all SET devices and calls are placed
directly between each other.
- Is
“escaped” limited to two hexdigits? How does one escape to Unicode
characters? This should be
possible.
It has never been proposed to use unicode, so, yes, the
"escaped" set is limited to two bytes (the data type is actually
IA5String). However, we could add a statement that says that the entire
H323-URL is UTF-8 encoded. In that way, characters from other languages
could converted to UTF-8 and then escaped where necessary.
However, this does bring to my attention the fact that the
character set is now very limited. Any character can be represented, but
it would be nice to allow François to enter his name like that, rather than
Fran%83ois. What character set limitations does IA5 impose on us?
Can we use any binary value between 0-255 for each character? If so, I
would also like to propose that we change the "unreserved" production to allow
any character between 0-255, excluding % and @ (since those have special
meanings). What do you think?
- If
nesting is supported, how is this defined or used? If not, then there is no
nesting.
I don't envision nesting one address type inside the URL, if
that's what you are asking. You convinced me before that, if the user
alias is not sufficient, then other URL schemes should suffice, such as "tel"
for reaching phone numbers.
- When
this URL is used in the url-id field, is the URL name inclusion
mandatory? If not, what is the
default?
I would say "yes" and double "yes". If the scheme name is not
present, one could not determine that it was the H323-URL. We definitely
want to allow the usage of "http" or "tel" or even "sip". I can image an
H.323 endpoint that gets launched and the only address on hand is sip:paulej@packetizer.com and the
Gatekeeper must route the call to an IP gateway than can provide interworking
functions.
- I
see no need for the URL ARQ be resolved to a URL. It could be resolved to any alias
using the alias replacement rules. The means that an URL in and ARQ
could be replaced with a partyNumber (last
paragraph).
You lost me here. If you are saying that there's no need
to put a partyNumber inside a URL or that the GK should be allowed to map the
URL alias to a partyNumber when returning an ACF, I agree. Otherwise, I
need some clarification.
Paul