H248 Implementers Guide Draft Now Available

[Christian Groves]

Bob,

HTML mail makes replying hard....  or at least Outlook Express doesn't work real well.

   

  ·       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

  or do you want this:

  h323:paulej at packetizer.com;proto=ras,port=1719

  [RWC] I prefer choice one in the base specification.



I also prefer the first choice.

 

  ·       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.

My view on this is that the endpoint should have one of two options:

1) It contacts the endpoint directly, or

2) It sends to URL to the GK for resolution



This suggests to me that we're taking the wrong approach with this "proto" extension and we should just remove it.



Perhaps we should replace "proto" with "mode".  We could have this format:



h323:paulej at packetizer.com;mode=direct

or

h323:paulej at packetizer.com;mode=indirect (default if "mode" is not specified)



The "direct" mode would suggest that the endpoint is reachable directly with the specified URL.  In other words, a Setup message may be sent directly to the endpoint at "packetizer.com" (the endpoint would have to resolve the address to get an 'A' record from DNS).



The "indirect" mode would suggest that the endpoint should send the query to it's GK.  The Gatekeeper would then perform a DNS query looking for the Gatekeeper associated with "packetizer.com" or would send the query to its Border Element for resolution.



If it finds a Gatekeeper for the given domain, it would then send an LRQ to the Gatekeeper.



If it finds a Border Element for the given domain, the Border Element would send an AccessRequest to the Border Element.



I believe Annex O should define the procedure for how we define and specify Gatekeepers and Border Elements stored in DNS.

 

  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

  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.

 So perhaps the user part of the name should be defined as a UTF-8 encoded string of characters, with the only restrictions being that "%" and "@" must be escaped if they exist in the user part.  Sound good?

  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 believe that the above mentioned change (re: UTF-8) will give us the means of allowing the full range of unicode characters for the user name part.



However, this raises another question: how do we enforce the rule that names are not case sensitive.  That would suggest that for any given character set within unicode, the manufacturer will have to know which characters are the upper and lower case ranges.  Is this desirable to recommend?  I like names that are not case sensitive, but this might be overly complex to try to do.  It would make internationalization of a Gatekeeper, for example, much more difficult than it is today-- I suspect some vendors will not go through the effort.



Should we re-think the "case insensitive" issue?





  ·       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.

Agreed.  This should be done when the endpoint indicates that it can map aliases.



Paul



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000904/8c75ef71/attachment-0001.htm>