September 2000 - sg16-avd - lists.packetizer.com

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

[JAIN] Fw: H.323 Experts required
by Paul E. Jones 01 Sep '00

01 Sep '00

Folks, I received this message from Steve Grover. He is looking for experts for the H.323 API specification development. If anybody is interested, I would invite you to contact him. He also provided these URLs: •How to get started •http://java.sun.com/aboutJava/communityprocess/getstarted.html •The JSPA •http://java.sun.com/aboutJava/communityprocess/JSPA.pdf Best Regards, Paul ----- Original Message ----- From: "Steven Grover" <steven.grover(a)sun.com> To: "Paul E. Jones" <paulej(a)packetizer.com> Sent: Friday, September 01, 2000 5:41 AM Subject: [Fwd: H.323 Experts required] > Dear Paul, > > John de Keijzer has passed me your details with reference to the > JAIN H.323 API Specification. We now have a Specification Lead > and we need to gather Experts for this Expert Group... (see mail > below) > > Are there any Members of your group that may wish to become an > Expert in this API Specification development? > > I look forward to hearing from you. > > Best regards, > Steven Grover > > > > -------- Original Message -------- > Subject: H.323 Experts required > Date: Fri, 01 Sep 2000 10:14:37 +0100 > From: Steven Grover <steven.grover(a)sun.com> > Reply-To: steven.grover(a)sun.com > Organization: Sun Microsystems - Network Service Provider Group > To: jain_community(a)sun.com > > Dear Community Members, > > I am pleased to inform you that the JSR for H.323 is almost ready > for submission. There has been considerable interest from the > Community for H.323 and there are currently Members interested in > becoming the Specification Lead for this API specification. > > We are now at the stage where it is necessary to poll the > Community for interested companies who would like to become an > Expert in the H.323 Expert Group. > > I look forward to hearing from any interested parties who would > like to participate. > > Best regards, > Steven Grover > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 01 Sep '00

01 Sep '00

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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Thursday, August 31, 2000 12:48 PM To: ITU-SG16(a)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(a)radvision.com <mailto:orit@radvision.com> -----Original Message----- From: Paul E. Jones < paulej(a)PACKETIZER.COM <mailto:paulej@PACKETIZER.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> < ITU-SG16(a)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

2 1

IPTEL official "minutes" and the "CPL liaison" posting
by Orit Levin 01 Sep '00

01 Sep '00

Hello! For those who are interested in CPL work and other IPTEL activities, I am attaching the "IPTEL minutes" from IETF48 by J. Rosenberg. I am also posting the SG-16 "CPL liaison" (TD-44d) on the IPTEL reflector. 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(a)radvision.com

1 0

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

01 Sep '00

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

2 1

AW: Progress Indicator IE in a PROGRESS Message
by Klaghofer Karl ICN EN HC SE 81 01 Sep '00

01 Sep '00

Even if Progress Indicator IE is optional in H.225.0 for sending, it shall be mandatory to support (and act upon) if received. Otherwise, the rules we established recently in v4 on the subject of controlling tones and announcements provided from B (or from a Gateway) to a calling EP A would not work well. Note that there are some applications (like Call Park) where we use PROGRESS message as the first end-to-end backward message which does not necessarily require a Progress Indicator IE. Regards, Karl Klaghofer -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet am: Donnerstag, 31. August 2000 19:37 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Progress Indicator IE in a PROGRESS Message I kind of vaguely remember that being a bug in an early version of Q.931. Pretty fuzzy however. -----Original Message----- From: Glen Freundlich [ mailto:ggf@AVAYA.COM <mailto:ggf@AVAYA.COM> ] Sent: Thursday, August 31, 2000 7:06 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Progress Indicator IE in a PROGRESS Message I don't recall intentionally leaving the Progress Indicator IE optional - this looks like a mistake to me. Glen Rich Bowen wrote: > This may have been an oversight -- I'm not sure a Progress message > without a Progress Indicator makes any sense. Having only been > involved in this area for the last couple of years, I'll have to rely > on someone else to provide the original reason why this was made > optional. > > This IE was also optional in H.225.0 v2. However, section 7.2.2.23 of > the v4 draft indicates that it is mandatory for a gateway to forward > this IE from ISDN to H.323. > > Rich Bowen > > "Wuerfel, Randy P" wrote: > > > > In reading through APC-1939 (draft H.225.0 V4) for the Portland meeting, I > > noticed that the Progress Indicator IE is shown as "O", optional, in the > > PROGRESS message. It is also shown this way in my copy of H.225.0 V3. > > However, in Q.931 the Progress Indicator IE is mandatory in the PROGRESS > > message. > > > > Is there some reason why, for H.225.0 usage, the Progress Indicator IE in > > the PROGRESS message is optional rather than mandatory, or was this an > > oversight? > > > > Randy Wuerfel > > Siemens Enterprise Networks > > 4900 Old Ironsides Drive Fax: (408) 492-4666 > > M/S 200 Tel: (408) 492-4375 > > P.O. Box 58075 E-mail: > > Randy.P.Wuerfel(a)icn.siemens.com > > Santa Clara, CA 95052-8075 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0