H.323 Products

[Paul E. Jones]

See inline comments
 
Bob
 
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756              Fax: +1.561.923.1403
Email:      Robert.Callaghan at ICN.Siemens.com
------------------------------------------------------------------
 
*       The port should be specified as belonging the specified protocol. 
What do you mean?  Are you in favor of this:
h323:paulej at packetizer.com:1719 <mailto:h323:paulej at packetizer.com:1719> 
or do you want this:
h323:paulej at packetizer.com;proto=ras,port=1719
<mailto:h323:paulej at packetizer.com;proto=ras,port=1719> 
[RWC] I prefer choice one in the base specification.
 
*       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?
[RWC] I definitely don’t like q931 and annex-g.
 
As a secondary question, how is an endpoint to handle ras and annex-g?
Obtain the information directly or go through the GK?  This should be
stated.
 
Or how about this-- make it easier for those not familiar with the
protocols.  Specify the type of device:
    h323:paulej at packetizer.com;dev=gk
<mailto:h323:paulej at packetizer.com;device=gk> 
Or dev=ep or dev=be
[RWC] This was a mistake on my part.  I meant annex-k for the API link.  We
don’t need a device field.
 
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.
[RWC] The type of device for what: the endpoint for the contact point.  I
don’t think the URL should change the normal procedure of an endpoint using
the GK, if one is present.  Annex-g should never be used by and endpoint
(see annex g).  The only applies to GKs or boarder elements.
 
 
*       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.
[RWC] We cannot have UTF-8 in the domain part of the URL.   I would like to
see UTF-8 in the user part of the name through the use of escaped
characters.
 
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?
[RWC] 0-255 is not sufficient.
 
*       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.
[RWC] It is possible to pass a URL to a GK and have it respond with a
partyNumber under the rules of alias substitution by the GK.  Then the SETUP
is sent using the partyNumber alias not the url alias.
 
Paul
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000901/98866b2e/attachment-0002.htm>