Orit,
I'm not sure I am clear on what you are saying by "Zone1...GK2"
I expect the URL to be used these ways: 1.. The endpoint just hands the URL to the GK for resolution 2.. The GK may perform some DNS operation to resolve the address (ffs - Annex O) 3.. If the "mode" of the URL is "direct", the endpoint may resolve the address of the endpoint and send a Setup (ffs - Annex O)
I can agree with having a basic URL, but we either have little or no text in the URL section (which it is quite short enough) or we decide, at the very least, what the difference is between a URL that represents a callable entity, versus one that is not a callable entity.
I am proposing: h323:paulej@packetizer.com;mode=indirect h323:paulej@paris.packetizer.com;mode=direct
Where "mode=indirect" would be the default. Your proposal below is that without parameters, a Setup is the default-- and I do not agree with that. In my opinion, it is far more likely that the query is going to require the services of some entity (such as a Gatekeeper) to resolve my address. This is especially true when I use a dynamic IP address, have my network hierarchy "undisclosed" to the external community, etc. Also, URLs are likely to follow e-mail addresses. Of course, that begs the question of why we don't just put more emphasis on that. Of course, I agree that URLs provide more flexibility, as they can be expanded to allow us to select an MCU and conference on the MCU, for example.
I would be willing to drop the "port" portion of the URL if we agree that it's only applicable for the "direct" mode. In that case, the syntax might be:
h323:paulej@paris.packetizer.com;mode=direct,port=1720
Note that there are two values: one to indicate the mode and one to indicate the port. We could allow the port to be semicolon (";") separated, rather than coma separated. It makes no big difference to me, but the port should only be available for "direct" calls. When the calls are "indirect" (i.e., resolution by some Annex O means), the GK may receive the request or the port will be learned from SRV queries-- that we can determine later.
Is this acceptable?
Paul
----- Original Message ----- From: Orit Levin To: ITU-SG16@mailbag.cps.intel.com Sent: Monday, September 11, 2000 3:01 PM Subject: Re: Revised H.323 URL document
Bob! Below is my take on the current situation. The three of us have the following different views on the possible use of the H.323 URL. If I try to map them into the H.323 "classic" picture of EP1---GK1-------GK2---EP2 . The GKs are optional. If exist, they may contain BE as well. I understand the following:
Bob:: indirect: EP1---GK1; direct: EP1 --------Zone2 Paul:: indirect: Zone1-------GK2; direct: Zone1------EP2 Orit:: Zone1-------Zone2 (with H.225.0 Q.931, LRQ or Annex G) possible between them for a specific call.
We "agree" that all of the scenarios should be allowed. "It seems like" we disagree about the priority/emergency of each of the applications above. Saying that, I don't like very much to define a solution based on the "perceived priority" of the applications. My proposed approach is, above all, guided by the fact, that the DESTINATION is the one to design its URL scheme, implement and, eventually, publish its URL(s).
The URL - has a key (I.e. the DNS domain) for IP resolution only - says what is the first H.323 protocol to contact this IP address, all the scenarios above are addressed.
If the DNS portion (I.e. "host") is not present, it automatically means, that the local (pre-configured or RAS discovered) gatekeeper will resolve the "user" name (using RAS, Annex G, another DNS lookup, other means). It is an exception, but it is still consistent with the approach above (The local zone is responsible for the URL scheme, it published.)
The bottom line: I agree with the last proposal for H.323v4: No parameters at all. The default: H.225.0/Q.931/Setup with its default TCP port. Paul?
Best Regards, 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 orit@radvision.com -----Original Message----- From: Callaghan, Robert Robert.Callaghan@icn.siemens.com To: 'Orit Levin' orit@radvision.com Cc: ITU-SG16@mailbag.cps.intel.com ITU-SG16@mailbag.cps.intel.com Date: Monday, September 11, 2000 1:53 PM Subject: RE: Revised H.323 URL document
Orit,
Let us try to focus on a few points first: (These are snippets from the thread.)
OL: Are you interested in efficiently running H.323 over the Internet?
RC: Yes! For clarification, this is the H.323 as defined in H.323v4 and H.225.0v4. For the November decision, there should not be any extensions, implicit or explicit.
OL: The picture, in my mind, is different from yours and fits the "traditional" H.323. For every H.323 call, logically there are (at least) two GKs: source and destination. (Physically, both of them are optional, based on the "mode" policy inside the corresponding H.323 zones.)
RC: I agree with your model of two endpoint each with an optional GKs based on zone policies. The source and destination policies are independent from each other. I don't know how this is different, as you state.
OL: By specifying in H323-URL the "mode" of operation between the source EP and a GK, you propose to use the URL for "publishing" the relations between the EP and "ITS" GK PER DESTINATION! It is, indeed, very different from the H.323 today. Moreover, you implicitly introduce a concept of a "source" GK, being re-defined each time BY THE DESTINATION. (This case may be considered as an additional application for the H.323 URL)
RC: I make so such assumption. In the "Direct" model, I assume that the given address is directly callable. The routing model is not specified nor assumed. If the term "Direct" is a problem in that the term overlaps with the routing model then the use of "Callable" would be fine. The use of the DNS service to convert the DNS domain to an IP address is assumed. This is also the only use of the DNS server. No DNS records beyond the "A" record will be used. If the initial use of the H.323 URL could be limited to this service.
RC: The use of the "Indirect" or "non callable" form has bothered me in that its use is not clearly defined. My view is that this was a means to access an H.323 repository to obtain the true address. Apparently there are other views. Therefore I suggest that a solution would be to drop this form for now.
OL: The natural use of URLs is between the zones/domain. For H.323, it is an OPTION, what kind of address resolution to propose and use. The beauty of the URL approach is that the DESTINATION provides an option to be reached using the DNS lookup, if it chooses so and populates properly the DNS.
RC: The may be beautify for some; but it is definitely new. I know of nothing in H.323v4 that describes the procedures and rules for this type of address resolution. This can be discussed as part of Annex O, after the decision on H.323v4.
OL: We don't have to agree on the mailing list. We can spend more then one meeting in order to reach "the consensus". In that case, I would support the inclusion of the minimal H323-URL only (without any parameters and without the PORT number) towards the H.323v4.
RC: I agree that it is not possible to agree to a complex solution on the mailing list. However, I hope that we can agree to a simple URL without any parameters or port (ouch! J) where this URL is the actual address to be used in a SETUP message. This should not change anything in H.323 including the use of the GK.
I hope that this helps.
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax: +1.561.923.1403
Email: Robert.Callaghan@ICN.Siemens.com
------------------------------------------------------------------