- sg16-avd - lists.packetizer.com

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Jaakko Sundquist 06 Sep '00

06 Sep '00

Mr. Roy & other parties interested in H.323 Annex H, I found your posting addressing such general level issues that I think it is better to write a whole new mail as a response instead of responding to your claims and comments point by point... First of all you question the mandate of Annex H and its relation to the H.323 protocols. I find it very odd that you, without any real arguments to support for it, restrict the H.323 recommendations and thus also Annex H to handle ONLY the H.323 entities that have been defined prior to Annex H. The first real work that we got done for Annex H was to identify the functionalities that were (are) needed for Mobility Management and that were missing from H.323. This is how we (in an ad hoc meeting in Red Bank, in which you yourself was also present) came up with the four new H.323 (functional) entities: HLF, VLF, AuF and IWF. Thus we have defined NEW H.323 entities that were NOT present prior to Annex H. If it is illegal for us to define new H.323 entities (as you seem to claim), I can't see how the Border Element ever got defined, since it was not defined prior to the H.225 Annex G. Second, you seem to have defined the HLF, VLF and AuF as back-end services. This is NOT how I see them. I see back-end services as services that are NOT defined in the H.323 series recommendations, but that may be used by gatekeepers. In other words, back-end services or the functionalities they provide do NOT have any real definition in H.323, nor is it illegal to define new entities to H.323 that provide same kind of functionalities that could be achieved by using some back-end service. The back-end services that are used in some implementations of the H.323 system can undoubtedly be used for similar purposes as the new functional entities of Annex H are, but this does not make the new entities back-end services. Furthermore, the whole point (or mandate) of Annex H is to make recommendations that allow for different manufacturer's equipment to be used in different parts of the (mobility enhanced) H.323 system and still allow the users/terminals to move around in the network. Thus, in my opinion, it is one of the most important issues of Annex H to define, how the HLF, VLF and AuF communicate with each other. By just stating that they are back-end services we would in essence NOT define this, since back-end services are NOT defined in H.323. Third, the protocol(s) that are used between the HLF, VLF and AuF are still and open issue. The reason, why the H.225 Annex G protocol is used in the present draft is that it is the only protocol that has been seriously mentioned for this purpose. (Not only by the editor, but in various contributions as well, although the editor takes full responsibility of the current text in the draft.) It has been identified that the H.225 Annex H protocol already has the functionality for locating a User with a certain aliasAddress. Really roughly said, this functionality is "half" of the functionality that is needed for Mobility Management, the other half being the location updating procedures (which are not really addressed by the protocol yet). This is why the protocol is being considered for the Annex H usage. However, I would really like to see contributions suggesting other (preferably existing) protocols as well. Intel's contribution APC-1902, was the first one of this kind. These contributions should, however, state clearly how the suggested protocols should be used, if there is any ambiguity. I.e. just stating: "Use Mobile IP" is not enough (I'm not trying to refer to the APC-1902 with this comment), but information flows for the needed Mobility Management procedures should be presented (these include at least the location updating procedures, call establishment procedures, call termination procedures and unregistration procedures). Fourth, the needed enhancements of the RAS, Q.931, etc. protocols will be provided by finishing the information flows on chapter 10. I admit that not much of this has yet been done, but on the other hand, at least so far I have found that there is not too much that has to be done with respect to these protocols. (There will probably be certain message fields that will be mandatory for Mobile Terminals that are optional in H.323 normally, etc., but I don't see a need for too many new message fields or messages.) Last, but not least, we a really in a hurry, if we want to get the Annex H determined in November. This is why I suggest that the interested parties provide the contributions describing the usage of other protocols as the Mobility Management protocols of Annex H as soon as possible. Also it would be very nice, if these contributions were made modeling the chapter 10 of the current draft, so that incorporating them to the annex would be as fast as possible. I'm still a bit in the middle of the process of digesting the information I have gotten about the Annex H work in Portland, but I'll try to send a mail summarizing (what I think is) our current situation later this week (probably on Friday). I will also make a "cleaner" version of the TD-42a as the "starting point" for our interim work before Geneva (this new draft will not contain any other than editorial changes compared to TD-42a). ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q.13/1 6
by Roy, Radhika R, ALCOO 05 Sep '00

05 Sep '00

Hi, Everyone (including Rapporteurs and WP 2 Chairman): I appreciate that Istvan Sebestyen has rightly pointed out, " ... By this development the "enterprise" and the "mobile carrier" solution are likely to develop separately, which is not too good for compatibility and interoperability." I am just curious to know more technical insights: Enterprise vs. Carrier solution for H.323 mobility. It is a very useful discussion to clarify further what we are up to. May be I have missed some of the discussions. H.323 is a transport independent multimedia application. So, H.323 mobility solution is applicable for both wire-line and wireless (wireless LAN, packet-switched [pico-, micro-, and macro-cell) network. So, as Istvan pointed out, the H.323 mobility solution will be only one that is applicable for all networking conditions. The next question comes: Does H.323 Annex H is going to meet our objectives as it stands now? The answer is "No." First of all: What is the mandate of Annex H? Its mandate is to extend H.323 to support mobility. What do we mean by H.323 protocol? These protocols are H.323 base specs, H.225.0 (RAS, Q.931, Annex G),and H.245 where the communications are performed among the H.323 entities: Terminals, GKs, BEs, and GWs. So, Q.13/16 has the charter to extend those protocols to support mobility among its functional entities: Terminals, GKs, BEs, and GWs. If you examine the write-up of the present Annex H, one can easily see that there is almost no mention how the H.323 base specs, H.225.0 (RAS, Q.931, Annex G) need to be extended to support mobility among H.323 entities like Terminals, GKs, BEs, and GWs. Many contributions are there, and many emails have been sent. But nothing is coming out of this. Rather, it is interesting to see that some folks are trying to push something that may not be the charter of Q.13/16, or even may not be the charter of SG16. For example, communications between VLF and HLF, between VLF and AuF, or between HLF and AuF. These are generic protocols and no special treatment is needed because of H.323. For example, IMT-2000 is also working in this area. We can use those protocols for this purpose, or if needed, a joint work item can be developed between the SG16 and other SGs. We are NOT sure why we are spending an enormous amount of time in doing this in Q.13/16 while ignoring the basic work of Q.13/16 to extend the existing H.323 protocol to support mobility for its existing functional entities. Another wild suggestion is being made: Use of the H.323 Annex G for the VLFs, HLFs, AuFs, etc. This suggestion shows how we are creating confusions in the development of mobility protocol. VLFs, HLFs, AuFs, etc. are known as the backend servers, and these protocols are known as the backend services (BES) protocols. H.323 has NOT developed any BES protocol so far. Please note that H.225.0 Annex G protocol is being used for communications between the GKs/BEs, and "NOT" for communications between the Backend servers like VLFs, HLFs, AuFs, etc. The protocols for communications between VLF and HLF, between VLF and AuF, or between HLF and AuF should be a separate sets of protocols, not the extension H.225.0 Annex G. However, these protocols may use some useful functional features that are suitable for the backend services protocols (e.g., hopcount, etc.), but these MUST be termed as the NEW backend services protocols. Many contributions have been made to explain those things. I have not seen any progress that we have made so far in this direction. So, the final proposal is this for H.323 Annex H: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Sebestyen Istvan ICN M CS 27 [mailto:Istvan.Sebestyen@ICN.SIEMENS.DE] Sent: Tuesday, September 05, 2000 6:21 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: response to open letter from Tom Taylor Importance: High Dear Colleagues, ... By this development the "enterprise" and the "mobile carrier" solution are likely to develop separately, which is not too good for compatibility and interoperability. Kind regards, Istvan Sebestyen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: response to open letter from Tom Taylor
by Sebestyen Istvan ICN M CS 27 05 Sep '00

05 Sep '00

Dear Colleagues, I fully agree with the comments made by Dale Skran, and this was also the essence what he said in the Welches, OR meeting - in his usual humorous, but occasionally a bit provocative way (that, by the way, I personally love so much...). The subject, as it came up also in the Oregon meeting, is very important, can not and should not be ignored (this was supported by several people). As I have pointed out already in the Osaka meeting, large companies seems to be divided on the subject (so nobody is blaming here anybody). The "enterprise" side of those very same companies favour very clearly the H.323 mobility, while the "mobile carrier" side supports (rightly or wrongly, that the discussion point) the SIP based solution. As it was pointed out, originally the requirement for the SIP based solution came from the carriers (e.g. MCI Worldcom come to my mind), so from our customers, who are the kings...but, as a matter of fact they were then supported by a few supporting contributions coming from manufacturers. By this development the "enterprise" and the "mobile carrier" solution are likely to develop separately, which is not too good for compatibility and interoperability. Kind regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/standards ---------------------------------------------------------------------------- ---------------- > ---------- > From: Skran, Dale[SMTP:DSkran@SONUSNET.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, August 30, 2000 3:29 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: response to open letter from Tom Taylor > > Dear Tom: > Allow me to repeat the comments I made during the meeting. I noted that a > large contribution comparing SIP and H.323 had been submitted to 3GPP, > having the conclusion of SIP's superiority. I complained that I was > disappointed in the non-technical nature of much of the material provided, > and urged the delegates to bring in real technical contributions > concerning > the possible demerits of H.323, with a view to the improvement thereof. > My > goal, then, as now, is the improvement of H.323, and also to call the > delegates attention to a document whose existance they may not have been > aware of, and which might stimulate them to bring in additional > contributions. > Any implication that, for example, 3GPP members are gullible, or there > were > no other contributions in 3GPP on this topic appears to be speculation. > In > addition, the idea that I or Sonus might profit in some fashion from these > comments is both speculative and humorous. As you can clearly see, they > have brought me nothing but trouble so far. I am still hoping for the > real > gain of additional valuable H.323 related contributions. > I would like to take this opportunity to thank Francois Audet for his many > contributions to H.323 over the years, both as an editor and as a > contributor, and also to his many contributions to the ATM Forum. > Francois > has been, without fail, a positive and helpful member of Q13 and the H.323 > community, and I would like to thank Nortel for supporting his standards > work. > One of the criticisms of H.323 in the 3GPP discussions appeared to be the > idea that SIP would be easier to modify for the wireless environment than > H.323, apparently because of a perception that the SIP community is more > open to change. I feel this is completely unfair and untrue. As > rapporteur, I have always welcomed new contributors and new ideas into the > H.323 system of recommendations, and would like to urge the further > consideration of H.323 for wireless/mobile applications by groups other > than > 3GPP (of course, further consideration by 3GPP is also welcome!). Such > groups will find Q13/WP2/SG16 ready and eager to work with them in > defining > any changes needed for the wireless/mobile environment. > I would also like to call attention to the continuing work of Q13 in H.323 > Annex H and I. > H.323 Annex H (User Service, and Terminal Mobility in H.323) > Determination 11/00 Editor J. Sundquist (Nokia) > H.323 Annex I (Packet based MM Telephony over Error Prone Channels) > Determination 11/00 Editor B. Aronson (Toshiba) > > Sincrely, > Dale Skran > Q13 Rapporteur > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Support bi-directional channels in annex C fast start
by Roni Even 05 Sep '00

05 Sep '00

Paul, TD14 from 9902-MON clearly states that the change was done to support fast start. This is the implementer guide for version 2. I am including the text as well as attaching the TD. I would think that the problem was not putting the extra text in the fast start procedure. IF it is not clear I can add some text to annex C Thanks Roni H.323 Annex C - Indication of ATM capabilities in TransportCapability Description: Annex C requires that the indication of ATM be indicated in the Terminal Capability Set, but it implies that it is done in the capability exchange procedures. While this is valid when fast start is not used, it is not when fast start procedures are used since they do not use the capability exchange procedures before setting up the channels. The current wording unfortunately prohibits the use of fast start with Annex C. This contribution proposes that the wording be amended to allow for this indication to be provided in fast start as well. More specifically, the current Annex mandates that the Terminal Capability set be used to indicate the ATM capabilities. If fast start is used, the TransportCapability (where the ATM information is included) is not included. It is however included in the OpenLogicalChannel. Annex C shall be amended the text to reflect this. It shall also be clarified that OpenLogicalChannel is used instead of OpenLogicalChannelAck when fast start is used..This change will be reflected in H.323 v3. C.3.6 Transport Capabilities added to TerminalCapabilityTransportCapability Set For operation of H.323 on AAL5, an addition to the TerminalCapabilityTransportCapability set is made in H.245. This includes transport level capabilities such as support for ATM Transfer Capability (DBR, SBR1, SBR2, SBR3, ABT/DT, ABT/IT, ABR) as defined in Recommendation I.371. Terminals that do not send this new capability parameter shall not make use of the new methods described in this Annex. The TransportCapability information can be sent as part of the Terminal Capability set exchange in the capability exchange phase. It is also included in the OpenLogicalChannel. ... C.3.7.1 ATM address The ATM address for an RTP stream shall be given in the mediaChannel subfield of H2250LogicalChannelParameters of the H.245 OpenLogicalChannelAck message (or the OpenLogicalChannel in the case of fast start). The mediaChannel subfield UnicastAddress or MulticastAddress shall be filled with the 20-octet NSAP-style ATM End System Address. ... C.3.8.2 Bidirectional logical channels If the bidirectional usage is indicated, the receiving endpoint shall send an OpenLogicalChannelAck (or the OpenLogicalChannel in the case of fast start) and then it must watch for an ATM VC to be opened by the other endpoint. When ATM VC is completed, it may then use the reverse direction for the media type indicated in the OpenLogicalChannel command. The endpoint that initiates the OpenLogicalChannel command is the endpoint that shall open the ATM VC. ... -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, September 05, 2000 9:13 AM To: Mailing list for parties associated with ITU-T Study Group 16; Roni_e(a)ACCORD.CO.IL Subject: Re: Support bi-directional channels in annex C fast start Ron, Here are the facts that led to this: 1) In H.323v3 (which is what the Implementers Guide is correcting), it is illegal to use a bi-directional channel with Fast Connect. 2) Section C.3.8.2 and it's parent section C.3.8 were written with H.245 signaling in mind-- there was no thought of Fast Connect here. The procedure is not defined. With H.323v4, Fast Connect was extended to include bi-directional TCP channels, but nothing has been contributed for bi-directional ATM VCs. To simply say it is allowed opens a very large hole. I will quote the authors of the e-mail sent to me that prompted my proposed correction. Since it was sent privately, I will withhold their names. It states: [[ begin quote ]] We believe that there is a conflict between Annex C and H.323 version 3 WRT the Faststart and the method used to open logical channels. Annex C talks about using B-directional OLCs and H.323 V3 claims that only uni- directional OLCs are used during Faststart. ... Annex C in H.323v3 (C.3.8.2) still allows for bidirectional channels in FastStart. It doesn't go into any details, but I can think of two possibilities: - It either opens an exception and allows for the reverse channel to be specified, or - It takes advantage of the fact that the *two* unidirectional channels (forward and reverse) are sent in the same message and somehow associates them as being the same SVC (using the SessionID and/or the mediaChannel value). [[ end quote ]] The author of that e-mail definitely pointed out a whole in the specification. Annex C references bi-directional channels used with Fast Connect, but that is explicitly illegal in V3. I am not at all opposed to re-inserting this text into H.323v4, but we definitely need some clarifying text that explains how this shall be used in Annex C. We cannot assume that the readers understand how it works. Would you be willing to draft text for Annex C to be included in the decided document in November? Best Regards, Paul ----- Original Message ----- From: "Roni Even" <Roni_e(a)ACCORD.CO.IL> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Sunday, September 03, 2000 6:03 AM Subject: Support bi-directional channels in annex C fast start > Hi, > During the Portland meeting I had a concern about the change in H.323 V4 and > Implementers guide described in APC 1875a item 17 that was added by the > editor. This change was also added by the editor to the white draft of H.323 > V4. The editor pointed out that there is a contradiction between the text in > Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use of > bi-directional channels. > I looked at the subject and my suggestion is to keep the text in annex C and > add to the end of the first paragraph of 8.1.7.1 "or one bi-directional > channel logical channel as described in annex C" > Thanks > Roni Even > > ******************************** > Roni Even > VP Product Planning > Accord Networks > Phone: +972-3-9251200 > Fax: +972-3-9211571 > email: roni_e(a)accord.co.il > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

H.323 Products
by Paul E. Jones 05 Sep '00

05 Sep '00

Folks, Frequently, I am asked for a list of H.323 products (IP phones, gateways, MCUs, etc.) What I would like to do is build a fairly complete list of products (both hardware and software). I will make the list available on Packetizer so that people can be directed to one place for the list. If your company has an H.323-compliant product on the market, please send me the following: Category: Phone (Terminal) MCU Gateway Gatekeeper Other (Lucent's "Phone on a Chip" is a good example) Company Name URL pointing to the product description on the web Once I get a few responses, I will post the information. Thanks! Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Support bi-directional channels in annex C fast start
by Roni Even 05 Sep '00

05 Sep '00

Hi, During the Portland meeting I had a concern about the change in H.323 V4 and Implementers guide described in APC 1875a item 17 that was added by the editor. This change was also added by the editor to the white draft of H.323 V4. The editor pointed out that there is a contradiction between the text in Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use of bi-directional channels. I looked at the subject and my suggestion is to keep the text in annex C and add to the end of the first paragraph of 8.1.7.1 "or one bi-directional channel logical channel as described in annex C" Thanks Roni Even ******************************** Roni Even VP Product Planning Accord Networks Phone: +972-3-9251200 Fax: +972-3-9211571 email: roni_e(a)accord.co.il ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H248 Implementers Guide Draft Now Available
by Christian Groves 04 Sep '00

04 Sep '00

G'Day all, The first draft of the H.248 Implementers Guide can be found at: ftp://standard.pictel.com/avc-site/Incoming/H248_implementors_guide_v1.zip It is in PDF and Word format. Enjoy. Cheers, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 URL Specification
by Callaghan, Robert 04 Sep '00

04 Sep '00

See inline comments Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)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@packetizer.com:1719 <mailto:h323:paulej@packetizer.com:1719> or do you want this: h323:paulej@packetizer.com;proto=ras,port=1719 <mailto:h323:paulej@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@packetizer.com;dev=gk <mailto:h323:paulej@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

2 1

Annex K over multiple domains (Regarding APC-1934)
by Espen Skj�ran 01 Sep '00

01 Sep '00

Dear M.Ishii and S.Minono, Thank you for addressing the errors and ambiguities in H.323 Annex K in APC-1934. I am sorry I could not attend to the meeting, but will try to explain my comments here. I have also though about the use of Annex K (and other service control mechanisms using the ServiceControlSession scheme) outside the local zone, for example using Annex K from home domain to the visiting terminal would be of great value. However, I have intentionally delayed contributions on this field as I wanted the mobility work to have a clear architecture and messages before the service control issues are brought in. I have targeted the ServiceControl codepoints for Annex K in call signaling messages, along with RCF and SCI, for simplicity. The other RAS messages have included this for other applications, e.g. the call credit. I have assumed that annex K communication exist between the local gatekeeper and the endpoint, or between two entities in a call. Now as you suggest, we can also do useful services between different entities out of a call, and that shouldn't be restricted. 2.5.1 Adding ServiceControl fields to LRJ/LCF I have sort of assumed that most applications want the possibility to update a session later, in which case they need an open channel towards the endpoint. The LCF/LRJ message is a one-time thing. Also, to do services that interact with call control layer a service provider needs the call signaling channel anyway, in which case they wouldn't need the URL in the LCF message, but rather do the whole thing within the call signaling channel. But as you say, lightweight applications could take use of a ServiceControlSession in LRJ/LCF messages, for example by showing a list of other call addresses through the H.323 URL. I have nothing against adding the ServiceControlSession to LRJ/LCF. 2.5.2. Forwarding the SCI message by gatekeepers Forwarding the SCI message, I think, will require quite substantial changes to the SCI message, along with addressing schemes in the existing gatekeepers. I like the idea that the RAS messages (well, at least most of them), have clear states and are kept on the same interface, in this case terminal-gatekeeper. What about following the same schemes as H.450 and H.323 Annex L instead? Using call independent signaling? (ConferenceGoal = callIndependentSupplementaryService) This way we don't have to include addressing info in SCI, we reuse existing gatekeeper policing and addressing schemes. Services will be available even if the client's gatekeeper does not support v4 or Annex K. Also, the use of the sessionID will be clear (as these are defined over one specific interface). I hope this clarifies my points and that my suggestions satisfy you. I guess the addition of ServiceControl fields to LRQ and LCF would be the job of H.225 editor, while I can bring in a statement about the use of call independent signaling in K.2.1 and K.2.2? Regards, Espen Skjaeran ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Re: H.323 URL Specification (second try)
by Orit Levin 01 Sep '00

01 Sep '00

(0) The use of url means the "address resolution" is done (by the local GK) using the DNS, not RAS! This is why the "user only" url of H.323, is really an exceptional case. It is a question, if we want to keep it within the url. It lets the local (source) GK know, that the "address resolution" procedure should performed by other, then DNS, means. The "protocol" means: the signaling H.323 protocol to contact the (next hop towards the) destination, after the IP address had been resolved. (1) Since "user only" is an exception in H.323, I still believe, that it is dangerous to leave it just as an "user"... (2) If you would like to say that the destination can be reached by either "RAS on UDP on port #n" or by "H.225.0/Q.931 on "Annex E" port #m", you need to advertise two different URL for the same (?) service. It may be OK, but we all have to agree on the meaning. BTW, I think that specifying the "message name" instead of the protocol is a great idea. It really fits the URL concept. On the other hand, I disagree with the "dev" proposal, from the same reason. Now you have the job to put all the interleaving and agreed upon comments in the new url draft text and start the next round. It is fun to work on the mailing list... Cheers, 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(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)packetizer.com> To: Orit Levin <orit(a)radvision.com> Cc: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Friday, September 01, 2000 10:13 AM Subject: Re: Re: H.323 URL Specification (second try) Orit, 1.. The reason for suggesting LRQ for RAS is simply that if you have a URL and I tell you that you use RAS to resolve this, how do you expect to resolve it? The endpoint may pass it to the GK, but the GK still has to resolve the address somehow. I don't mind removing the statement about LRQ. After all, we really need explicit procedure in Annex O to really use this URL properly. 2.. I do not like having URLs like this: h323:paulej@. I would much rather follow the conventions of UNIX programs like "finger", which allows one to do such things as "finger @hostname.com" and "finger user". It seems much more logical, in my opinion. I really only want to associate the "@" with the hostport. 3.. I don't understand your comments here. Can you clarify? Let me comment on the revisions you made to the document: "The only url-parameter defined.." -> "Currently, the only url-parameter defined" I would prefer to leave the that sentence there as it is, or modify is as follows: "The protocol parameter shall be interpreted as the..." thus removing all references to what is "currently" defined. Below, there is a statement that says that the definition of additional semicolon-delimited url-parameters, so that will address future changes. When no protocol is specified, I said that the interpreting entity shall assume the protocol is ras. I would prefer to leave it as shall to avoid any interoperability issues. Also, I agree that the last proposed sentence you provided about unknown parameters shall be ignored is good-- I will add that to the document. Paul ----- Original Message ----- From: Orit Levin To: ITU-SG16(a)mailbag.cps.intel.com Sent: Thursday, August 31, 2000 12:47 PM 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 orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)PACKETIZER.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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

1 0