- sg16-avd - lists.packetizer.com

[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

Re: H.323 URL Specification
by Orit Levin 31 Aug '00

31 Aug '00

My comments are inside the text. Orit -----Original Message----- From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Orit Levin' <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, August 31, 2000 4:44 PM Subject: RE: H.323 URL Specification Paul, Orit, This proposal looks good, but I have a few suggestions: a.. The default protocol should be mandatory. In this case, flexibility kills interworking. b.. OL: I agree.So the default for EACH ommited field is separately to be specified. c.. The port should be specified as belonging the specified protocol. d.. OL: Only Semantically? or also syntactically? I vote for syntactically as well. e.. For protocol, use h225rs or h323rs instead of ras. This controls the confusion with the dial-in protocol know as RAS. f.. For protocol, use h225cs or h323cs instead of q931. This controls the confusion with real Q.931 g.. For protocol, use h225ar or h323ar instead of annex-g. h.. OL: I don't mind. i.. 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. j.. OL: Yes, LRQ is definitely limiting k.. Do we need annex-f to be specified as a protocol? It appears to me that we have this need. l.. OL: I don't think so. We have the whole RAS procedure to negotiate it. As all other things, like the protocol to start from (i.e. the pre-granted ARQ). It is an never ending story. On the other hand, the specification for the TRANSPORT protocol is needed. Therefore, I would prefer to define a triple of (signalling, transport and the transport-port) - the way it is defined in the "Annex O" draft. m.. Is escaped limited to two hexdigits? How does one escape to Unicode characters? This should be possible. n.. OL: This has to be taken care of. o.. If nesting is supported, how is this defined or used? If not, then there is no nesting. p.. OL: The nesting has eventually be supported. I think, we can leave it to "Annex O" without breaking backwords compatibility. The nesting is done using the "user" field and is described in draft "Annex O". The "user-parameter" is added for that. If the parameter is not included, it is the destination domain policy to define and support the nesting. q.. When this URL is used in the url-id field, is the URL name inclusion mandatory? If not, what is the default? r.. OL: the scheme-name MAY be included. For H.323 url it is not mandatory. s.. 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). t.. OL: Yes, I thinks it is one procedure less, which is definitely a positive thing. If we agree on that, may we disallow the "user only" URL? It will solve additional issues... 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 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

Re: Progress Indicator IE in a PROGRESS Message
by Francois Audet 31 Aug '00

31 Aug '00

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] 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

1 0

Progress Indicator IE in a PROGRESS Message
by Wuerfel, Randy P 31 Aug '00

31 Aug '00

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

3 2

Re: Progress Indicator IE in a PROGRESS Message
by Agboh, Charles 31 Aug '00

31 Aug '00

Hi all, Is the flavor of Q.931 found in H.225.0 meant to be backward compatible with the "pure" Q.931? regards, charles -----Original Message----- From: Wuerfel, Randy P [mailto:Randy.P.Wuerfel@ICN.SIEMENS.COM] Sent: Thursday, August 31, 2000 1:41 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Progress Indicator IE in a PROGRESS Message 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

2 1

H.323 URL Specification (second try)
by Paul E. Jones 31 Aug '00

31 Aug '00

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