Re: H.323 URL Specification
Paul, Orit,
This proposal looks good, but I have a few suggestions:
* The default protocol should be mandatory. In this case, flexibility kills interworking. * The port should be specified as belonging the specified protocol. * 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". * 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". * Do we need annex-f to be specified as a protocol? It appears to me that we have this need. * Is "escaped" limited to two hexdigits? How does one escape to Unicode characters? This should be possible. * If nesting is supported, how is this defined or used? If not, then there is no nesting. * When this URL is used in the url-id field, is the URL name inclusion mandatory? If not, what is the default? * 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).
Sorry about being so picky, but details are important when it must be correct forever.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Thursday, August 31, 2000 12:48 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: H.323 URL Specification (second try)
Hi Paul, Bob and others! I am attaching a slightly modified version with changes, that I think, are MUST. In addition, I have the following reservations: 0. I have a problem with explicitly binding "RAS" with "LRQ". May be, the default should be "SHALL", "RAS" and "LRQ". But "RAS" shall NOT mean "LRQ first". 1. In case only the "user" is specified, I would prefer to always have the "@" sign: "user@". Indeed, it is visually deferent from the simple "user", but - It is going to be placed in a different alias type - It will make the parsers' logic easier when distinguishing between the cases: "h323-user@; parameters" and "foreign-url-with-its-own-parameters@" - We may not predict today all possible complications. I am not sure, we will always be able to keep the user part in a clean "escaped" format. 2. Once we go forward with the currently proposed definition, we allow for each url link FOR THE REST OF THE H323-URL LIFE only a single combination of (signaling-protocol, transport-protocol, transport-protocol-port). In order to specify more then one possibility for the START procedures, separate URLs will need to be provided. Any opinions? 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@radvision.com mailto:orit@radvision.com -----Original Message----- From: Paul E. Jones < paulej@PACKETIZER.COM mailto:paulej@PACKETIZER.COM > To: ITU-SG16@MAILBAG.INTEL.COM mailto:ITU-SG16@MAILBAG.INTEL.COM < ITU-SG16@MAILBAG.INTEL.COM mailto:ITU-SG16@MAILBAG.INTEL.COM > Date: Thursday, August 31, 2000 2:07 AM Subject: H.323 URL Specification (second try) Orit, Bob, and Others,
Please disregard the previous e-mail. It contained a slightly out-of-date revision of the text. I believe the URL proper is the same in both documents, but the surrounding text has changed.
Again, I welcome feedback.
Best Regards, Paul
Bob and others,
Please see my comments inline:
a.. The default protocol should be mandatory. In this case, flexibility kills interworking. Agreed. a.. The port should be specified as belonging the specified protocol. What do you mean? Are you in favor of this: h323:paulej@packetizer.com:1719 or do you want this: h323:paulej@packetizer.com;proto=ras,port=1719
a.. For protocol, use “h225rs” or “h323rs” instead of “ras”. This controls the confusion with the dial-in protocol know as RAS. b.. 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: h323:paulej@packetizer.com;dev=gk 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.
a.. 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. a.. 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. a.. 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? a.. 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. a.. 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. a.. 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
participants (2)
-
Callaghan, Robert -
Paul E. Jones