- 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

None
by Paul E. Jones 31 Aug '00

31 Aug '00

Orit, Bob, and Others, I have attached the modified H.323 URL specification for review, which hopefully includes all of the comments from the meeting. Please let me know if you see any errors or find things that you want to change. Thanks, Paul

1 0

Re: response to open letter from Tom Taylor
by Tom-PT Taylor 30 Aug '00

30 Aug '00

This has gone far enough, and I'm sorry if the whole matter is due to a misunderstanding. My previous note explained my precise point of sensitivity in your remarks, but it has occurred to me that you may simply have been trying to make the reference clear. Apparently I've left the impression that Nortel is trying to get rid of you. Definitely not! We recognize the valuable job you are doing. All I ask is a certain amount of care (when you speak as chair) that you not name individual ITU-T members in an unfavourable context (whether it's saying that IETF participants cannot be trusted or naming Nortel Networks as the contributor of a non-SG 16 document you proceed to criticize). Tom Taylor

1 0

Re: response to open letter from Tom Taylor
by Tom-PT Taylor 30 Aug '00

30 Aug '00

What I found most irregular was your specific attribution of the document in question to Nortel Networks. It is not that we are ashamed of the document, but that your naming of Nortel Networks in the process of your commentary seemed calculated to affect the attitude of other parties present in Q.13/16 toward Nortel. I have not observed such behaviour in other delegates, and believe that it is incompatible with a chairman's role. > -----Original Message----- > From: Skran, Dale [mailto:DSkran@SONUSNET.COM] > Sent: Wednesday, August 30, 2000 9:30 AM > To: ITU-SG16(a)MAILBAG.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 >

1 0

response to open letter from Tom Taylor
by Skran, Dale 30 Aug '00

30 Aug '00

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

1 0

Test - please ignore <eom>
by Patrick_Luthi＠PICTEL.COM 29 Aug '00

29 Aug '00

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [sip-h323] SIP-H.323 IWF protocol requirements
by Paul E. Jones 29 Aug '00

29 Aug '00

Jean-Francois, Here are a few benefits for using v3: H.323v3 introduces new fields to allow the GK to signal whether Annex E should be used or not. For build large-scale devices, Annex E is definitely worth considering. (Annex E was written for V2, but related RAS fields were added in v3.) It is possible to use the same TCP connection for multiple calls. Text was added to explain the use of Lightweight RRQs (this may have been in the IG, but I can't recall). A number of things are better explained, revisions have been made via the IG that may result in interworking issues if the latest texts (including the IG are not followed). Indeed, things should be backward compatible, but the clarifications are important, as they were obviously points of confusion. Version 4 has even more. Here's a few: * Gateway decomposition section * Support for new services and features * Annex L, Annex K, H.450.x, etc. * Generic Extensibility Framework * Additive Registrations * Alternate Gatekeeper usage fully defined * Usage Information Reporting * Endpoint Capacity Reporting * Desired protocol indication * Reporting call status with multiple IRRs * Call Linkage * Early H.245 * Support for pre-paid calling cards You can definitely see some advantages to v4. Probably the most important introduction in V4 is the Generic Extensibility Framework. With that, we can now add new features to the H.323 protocol specification that the signaling entities in the middle of the call can remain completely ignorant about. This allows us to add new features that work end to end without forcing the intermediate equipment to be updated-- that's one very good reason for moving to v4. It's quite possible that v4 may serve as the minimum specification for some time to come. Of course, this was possible before with "non-standard" mechanisms, but it is hoped that the GEF will introduce fewer ripples in the H.323 standardization effort and the software development cycle. This extensibility framework may also serve well for feature interaction between SIP and H.323. I realize that feature interaction is not an immediate goal, but it's nice to have the foundation in place to try to utilize it. That's why I suggested at the meeting to go with the latest: v4. It's true that the differences between v2 and v3 are small, but a few scalability issues were addressed. Since signaling interworking is not a major CPU consumer, I would think you'd want to take every possible step to increase the number of calls handled on a single box. That could easily go over the number of sockets the box can support. So using Annex E or carrying multiple calls over a call signaling channel is desirable. Of course, I realize that NetMeeting does not support these features, but I think that heavier consideration should be given to other H.323 entities. I cannot recommend trying to offer residential phone service using H.323v2 where SIP interworking is required: it's not nearly as scalable as v3 since SIP interworking forces all calls to be directed to one box or a few boxes. SIP works well there, but one really needs Annex E/H.323 to get comparable scaling ability from H.323. Paul ----- Original Message ----- From: "Jean-Francois Mule" <jfmule(a)clarent.com> To: <paulej(a)packetizer.com> Cc: "Wang, Dave" <dwang(a)nuera.com>; "aHit! IMTC (E-mail)" <ahitag(a)imtc.org> Sent: Tuesday, August 29, 2000 12:53 PM Subject: RE: [sip-h323] SIP-H.323 IWF protocol requirements > Paul, > Based on the current aHit IWF requirements, could help the group identify > what particular h323v3 functionality would be mandatory for the IWF. > If we can meet the requirements with v2, then we should mandate v2 which > means also that v3 implementations will meet the requirements since there is > some backward compatibility. > > Jean-Francois Mule > Clarent Corp. > > > -----Original Message----- > > From: Wang, Dave [mailto:dwang@nuera.com] > > Sent: Tuesday, August 29, 2000 8:59 AM > > To: aHit! IMTC (E-mail) > > Subject: FW: [sip-h323] SIP-H.323 interworking Requirements Draft > > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Monday, August 28, 2000 11:53 PM > > > To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com; > > > ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft > > > > > > > > > Radhika, > > > > > > A few months ago, I published the final set of ASN.1 > > > corrections for H.323v3 > > > to the ITU-T SG16 mailing list and to the IMTC H.323 mailing > > > list. I also > > > contact 11 companies that have H.323v3 products or products > > > in development > > > that I was aware of. > > > > > > There are certainly plenty of v3 implementations in > > progress and it's > > > important to be prepared for those implementations. H.323v4 will be > > > approved in November and I expect even quicker adoption of that > > > Recommendation, because it introduces a lot of new functionality. > > > > > > I think what the group should try to strive for is a > > > specification that will > > > work with the most recent version of H.323-- H.323v4. Of > > > course there will > > > be few implementations, but there are not a large number of > > > new mandatory > > > features. (I don't have a list handy.) > > > > > > For a "bigger picture" view of what's new in the various > > > versions of H.323, > > > see: > > > http://www.packetizer.com/iptel/h323/ > > > > > > Best Regards, > > > Paul > > > > > > ----- Original Message ----- > > > From: "Roy, Radhika R, ALCOO" <rrroy(a)att.com> > > > To: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>; <sip-h323(a)egroups.com> > > > Sent: Monday, August 28, 2000 10:32 PM > > > Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft > > > > > > > > > > Hi, Everyone: > > > > > > > > Here is my view as stated below: > > > > > > > > It is very difficult to find any vendor to support H.323 > > > version 3. Many > > > > companies are now testing vendor implementations of H.323 > > > version 2, and > > > it > > > > is also reported that multivendor interoperability at the > > > version 2 level > > > is > > > > still problematic. In many cases, no promise has been > > > obtained from the > > > > major vendors when they will support version 3. It may be > > > very nice to > > > have > > > > SIP/H.323 v3 interworking, but we think SIP/H.323 v2 > > > interworking should > > > > come first. > > > > > > > > Considering all factors, I think that we should keep our first > > > interworking > > > > requirements to support H.323 version 2 as defined in the > > > present draft > > > > (while we may consider for H.323 version 3 in the future). > > > > > > > > So, I recommend that we should make any changes in the > > > present draft. > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > AT&T > > > > +11 732 420 1580 > > > > > > > > -----Original Message----- > > > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > > > Sent: Sunday, August 27, 2000 10:32 PM > > > > To: sip-h323(a)egroups.com > > > > Subject: [sip-h323] SIP-H.323 interworking Requirements Draft > > > > > > > > > > > > Hi, Everyone: > > > > > > > > I have just returned from the ITU-T SG16 Q.13 (H.323) > > > meeting where our > > > > SIP-H.323 Interworking requirement draft was also discussed. > > > > > > > > The Q.13 members have strongly recommended that we should > > > consider H.323 > > > > version 3 (instead of version 2) for our SIP-H.323 > > > interworking work. > > > > > > > > We would appreciate if you would kindly provide your > > comments on the > > > point. > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > AT&T > > > > +1 732 420 1580 > > > > rrroy(a)att.com > > > > > > > > > > > > To Post a message, send it to: sip-h323(a)eGroups.com > > > > > > > > To Unsubscribe, send a blank message to: > > > sip-h323-unsubscribe(a)eGroups.com > > > > > > > > > > > > To Post a message, send it to: sip-h323(a)eGroups.com > > > > > > > > To Unsubscribe, send a blank message to: > > > sip-h323-unsubscribe(a)eGroups.com > > > > > > > > > > > > To Post a message, send it to: sip-h323(a)eGroups.com > > > > > > > > To Unsubscribe, send a blank message to: > > > sip-h323-unsubscribe(a)eGroups.com > > > > > > > > > > -------------------------- eGroups Sponsor > > > -------------------------~-~> > > > Need EDA tools on a short term or peak load basis? > > > Take a free 7 day trial! > > > http://click.egroups.com/1/8464/7/_/302437/_/967548702/ > > > -------------------------------------------------------------- > > > -------_-> > > > > > > To Post a message, send it to: sip-h323(a)eGroups.com > > > > > > To Unsubscribe, send a blank message to: > > > sip-h323-unsubscribe(a)eGroups.com > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [sip-h323] SIP-H.323 interworking Requirements Draft
by Agboh, Charles 29 Aug '00

29 Aug '00

hi all, perhaps we can procede as we planned with H.323v2 and add H.323v3 features as an extension package of some sort. regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Tuesday, August 29, 2000 4:43 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: FW: [sip-h323] SIP-H.323 interworking Requirements Draft FYI -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Monday, August 28, 2000 10:41 PM To: 'sip-h323(a)egroups.com'; sip-h323(a)egroups.com Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Henning: I agree with you (please also see my response provided below). Best regards, Radhika R. Roy -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Monday, August 28, 2000 12:12 PM To: sip-h323(a)egroups.com Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft "Roy, Radhika R, ALCOO" wrote: > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. What practical difference does it make? Could you summarize the relevant differences? Presumably, a v3 terminal is going to interoperate with v2 terminals. For the next year, at the very least, the only real implementation to worry about is NetMeeting (v2, I assume). -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Monday, August 28, 2000 10:32 PM To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Everyone: Here is my view as stated below: It is very difficult to find any vendor to support H.323 version 3. Many companies are now testing vendor implementations of H.323 version 2, and it is also reported that multivendor interoperability at the version 2 level is still problematic. In many cases, no promise has been obtained from the major vendors when they will support version 3. It may be very nice to have SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should come first. Considering all factors, I think that we should keep our first interworking requirements to support H.323 version 2 as defined in the present draft (while we may consider for H.323 version 3 in the future). So, I recommend that we should make any changes in the present draft. Best regards, Radhika R. Roy AT&T +11 732 420 1580 -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Sunday, August 27, 2000 10:32 PM To: sip-h323(a)egroups.com Subject: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Everyone: I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our SIP-H.323 Interworking requirement draft was also discussed. The Q.13 members have strongly recommended that we should consider H.323 version 3 (instead of version 2) for our SIP-H.323 interworking work. We would appreciate if you would kindly provide your comments on the point. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.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: Parlay
by Roy, Radhika R, ALCOO 29 Aug '00

29 Aug '00

Hi, Joerg: I will definitely refer the Mbus work to the Parlay community to have the close cooperation with IETF in addition to ITU-T's H.323/H.248 activities. I appreciate your efforts for referring the Mbus work in this respect. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Joerg Ott [mailto:jo@tzi.uni-bremen.de] Sent: Tuesday, August 29, 2000 10:17 AM To: Roy, Radhika R, ALCOO; ITU-SG16(a)mailbag.cps.intel.com Cc: dku(a)tzi.uni-bremen.de; csp(a)isi.edu Subject: Re: Parlay Radhika and all, sometimes, something more encompassing than a simple API might be helpful, particularly if we are talking about potentially distributed implementations of IP phones, supporting workstation GUI, etc. where not in all cases a strict client - server relationship can be identified (or persists for all time). We are jointly working with others on the Mbus infrastructure that allows modularization of IP telephony/multimedia endpoints, gateways, gatekeepers/ proxies, etc. As a special case (one piece of the manyfold interactions that are possible), this allows to provide call control APIs based on simple (low overhead) message passing mechanisms (and, or course, can carry any API on top, such as Parlay). We are looking for further input on the particular subject of call and conference control and, in this context, are also looking at a model for describing and controlling capabilities and media channel attributes that seamlessly fits with the SDPng work undertaken in the IETF. The Mbus (short for "Message Bus") provides a number of features for modular and robust system design including - automated detection of new system components; - may use host-local or link-local multicast (and thus inherently allows distribution of an endpoint across a LAN); - scalable mechanism for detecting component liveness; - tuple-based addressing for system-local unicast, multicast, broadcast; - simple message format with arbitrary payloads (easy to parse & implement); - extensible command sets (very small basic command set); - simple security mechanisms against eavesdropping on messages and spoofing; - supports client-server and peer-to-peer scenarios; - simple synchronization mechanisms; - provides a lightweight concept for policy mechanisms and voting (e.g. to determine permissions for placing a call or address resolution in parallel); The basic Mbus stack implementations are available for reseach and evaluation purposes in C, C++, and Java from the Mbus web site. In addition, various command sets have been and are being defined for the Mbus to allow for control of audio sources/sinks, RTP stacks, and call control. Further work is needed on the latter and on capability descriptions -- which is in progress. Take a look at http://www.mbus.org/ for an outline of the work and the current Internet Drafts. Note that this is a work item of the MMUSIC WG of the IETF. We would appreciate further input on this work. Best regards, Joerg >Hi, Everyone: > >In the last Q.13/16 Rapporteur meeting (August 21-25), we talked about the >Parlay organization. The detail about Parlay can be found in the following >URL: > >http://www.parlay.org > >It can be seen that it is an OPEN industry consortia for development of the >APIs, and its call control API spec 2.1 seems to be the most advanced work >that can support the call control applications like H.323, MEGACO/H.248, and >others. The Parlay spec is written in UML, and recently CORBA IDL spec has >also been produced. > >The comments on the Parlay CC spec 2.1 are being sought for updating the >spec across the industry. Many trials are also underway for the Parlay CC >API. > >I am co-chairing the Parlay call control work group. If any company is >interested to join the Parlay, they are welcome right away. The next Parlay >meeting will be held on Sept 27-29, 2000 in Stockholm. > >The efforts are under way to create one call control API spec across the >industry: 3GPP N5, ETSI SPAN5, ITU-T, JAIN, and others. It is expected that >representatives from all standard organizations will come to the next Parlay >meeting (Sept 26-28) to discuss how a common CC API spec can be produced >across the industry. > >If you have any questions, please let me or others know. > >Best regards, > >Radhika R. Roy >AT&T >+1 732 420 1580 >rrroy(a)att.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: Parlay
by Joerg Ott 29 Aug '00

29 Aug '00

Radhika and all, sometimes, something more encompassing than a simple API might be helpful, particularly if we are talking about potentially distributed implementations of IP phones, supporting workstation GUI, etc. where not in all cases a strict client - server relationship can be identified (or persists for all time). We are jointly working with others on the Mbus infrastructure that allows modularization of IP telephony/multimedia endpoints, gateways, gatekeepers/ proxies, etc. As a special case (one piece of the manyfold interactions that are possible), this allows to provide call control APIs based on simple (low overhead) message passing mechanisms (and, or course, can carry any API on top, such as Parlay). We are looking for further input on the particular subject of call and conference control and, in this context, are also looking at a model for describing and controlling capabilities and media channel attributes that seamlessly fits with the SDPng work undertaken in the IETF. The Mbus (short for "Message Bus") provides a number of features for modular and robust system design including - automated detection of new system components; - may use host-local or link-local multicast (and thus inherently allows distribution of an endpoint across a LAN); - scalable mechanism for detecting component liveness; - tuple-based addressing for system-local unicast, multicast, broadcast; - simple message format with arbitrary payloads (easy to parse & implement); - extensible command sets (very small basic command set); - simple security mechanisms against eavesdropping on messages and spoofing; - supports client-server and peer-to-peer scenarios; - simple synchronization mechanisms; - provides a lightweight concept for policy mechanisms and voting (e.g. to determine permissions for placing a call or address resolution in parallel); The basic Mbus stack implementations are available for reseach and evaluation purposes in C, C++, and Java from the Mbus web site. In addition, various command sets have been and are being defined for the Mbus to allow for control of audio sources/sinks, RTP stacks, and call control. Further work is needed on the latter and on capability descriptions -- which is in progress. Take a look at http://www.mbus.org/ for an outline of the work and the current Internet Drafts. Note that this is a work item of the MMUSIC WG of the IETF. We would appreciate further input on this work. Best regards, Joerg >Hi, Everyone: > >In the last Q.13/16 Rapporteur meeting (August 21-25), we talked about the >Parlay organization. The detail about Parlay can be found in the following >URL: > >http://www.parlay.org > >It can be seen that it is an OPEN industry consortia for development of the >APIs, and its call control API spec 2.1 seems to be the most advanced work >that can support the call control applications like H.323, MEGACO/H.248, and >others. The Parlay spec is written in UML, and recently CORBA IDL spec has >also been produced. > >The comments on the Parlay CC spec 2.1 are being sought for updating the >spec across the industry. Many trials are also underway for the Parlay CC >API. > >I am co-chairing the Parlay call control work group. If any company is >interested to join the Parlay, they are welcome right away. The next Parlay >meeting will be held on Sept 27-29, 2000 in Stockholm. > >The efforts are under way to create one call control API spec across the >industry: 3GPP N5, ETSI SPAN5, ITU-T, JAIN, and others. It is expected that >representatives from all standard organizations will come to the next Parlay >meeting (Sept 26-28) to discuss how a common CC API spec can be produced >across the industry. > >If you have any questions, please let me or others know. > >Best regards, > >Radhika R. Roy >AT&T >+1 732 420 1580 >rrroy(a)att.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

Parlay
by Roy, Radhika R, ALCOO 29 Aug '00

29 Aug '00

Hi, Everyone: In the last Q.13/16 Rapporteur meeting (August 21-25), we talked about the Parlay organization. The detail about Parlay can be found in the following URL: http://www.parlay.org It can be seen that it is an OPEN industry consortia for development of the APIs, and its call control API spec 2.1 seems to be the most advanced work that can support the call control applications like H.323, MEGACO/H.248, and others. The Parlay spec is written in UML, and recently CORBA IDL spec has also been produced. The comments on the Parlay CC spec 2.1 are being sought for updating the spec across the industry. Many trials are also underway for the Parlay CC API. I am co-chairing the Parlay call control work group. If any company is interested to join the Parlay, they are welcome right away. The next Parlay meeting will be held on Sept 27-29, 2000 in Stockholm. The efforts are under way to create one call control API spec across the industry: 3GPP N5, ETSI SPAN5, ITU-T, JAIN, and others. It is expected that representatives from all standard organizations will come to the next Parlay meeting (Sept 26-28) to discuss how a common CC API spec can be produced across the industry. If you have any questions, please let me or others know. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [sip-h323] SIP-H.323 interworking Requirements Draft
by Roy, Radhika R, ALCOO 29 Aug '00

29 Aug '00

Hi, Paul: I understand your points, and we also believe that we should work for version 3, but it would be nice if we could finish for version 2 first. Presently, my company (AT&T), like many other companies, has also difficulties to get version 3 implemented because of problems as stated earlier. However, we all realize that version 3 is needed and will be working for version 3 immediately as soon as we finish our work for version 2. I also like to point out that we are working for the informational RFCs and hope that we can produce the interworking spec for version 3 very quickly once we finish the same for version 2. My guess is that version 3 needs some incremental changes from those of version 2. So, I think that the work for version 3 can be completed quickly. Hope that this will answer your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, August 28, 2000 11:53 PM To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft Radhika, A few months ago, I published the final set of ASN.1 corrections for H.323v3 to the ITU-T SG16 mailing list and to the IMTC H.323 mailing list. I also contact 11 companies that have H.323v3 products or products in development that I was aware of. There are certainly plenty of v3 implementations in progress and it's important to be prepared for those implementations. H.323v4 will be approved in November and I expect even quicker adoption of that Recommendation, because it introduces a lot of new functionality. I think what the group should try to strive for is a specification that will work with the most recent version of H.323-- H.323v4. Of course there will be few implementations, but there are not a large number of new mandatory features. (I don't have a list handy.) For a "bigger picture" view of what's new in the various versions of H.323, see: http://www.packetizer.com/iptel/h323/ Best Regards, Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)att.com> To: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>; <sip-h323(a)egroups.com> Sent: Monday, August 28, 2000 10:32 PM Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft > Hi, Everyone: > > Here is my view as stated below: > > It is very difficult to find any vendor to support H.323 version 3. Many > companies are now testing vendor implementations of H.323 version 2, and it > is also reported that multivendor interoperability at the version 2 level is > still problematic. In many cases, no promise has been obtained from the > major vendors when they will support version 3. It may be very nice to have > SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should > come first. > > Considering all factors, I think that we should keep our first interworking > requirements to support H.323 version 2 as defined in the present draft > (while we may consider for H.323 version 3 in the future). > > So, I recommend that we should make any changes in the present draft. > > Best regards, > Radhika R. Roy > AT&T > +11 732 420 1580 > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Sunday, August 27, 2000 10:32 PM > To: sip-h323(a)egroups.com > Subject: [sip-h323] SIP-H.323 interworking Requirements Draft > > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. > > We would appreciate if you would kindly provide your comments on the point. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > > -------------------------- eGroups Sponsor -------------------------~-~> > GET A NEXTCARD VISA, in 30 seconds! Get rates > of 2.9% Intro or 9.9% Ongoing APR* and no annual fee! > Apply NOW! > http://click.egroups.com/1/7872/7/_/302437/_/967516325/ > ---------------------------------------------------------------------_-> > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [sip-h323] SIP-H.323 interworking Requirements Draft
by Paul E. Jones 28 Aug '00

28 Aug '00

Radhika, A few months ago, I published the final set of ASN.1 corrections for H.323v3 to the ITU-T SG16 mailing list and to the IMTC H.323 mailing list. I also contact 11 companies that have H.323v3 products or products in development that I was aware of. There are certainly plenty of v3 implementations in progress and it's important to be prepared for those implementations. H.323v4 will be approved in November and I expect even quicker adoption of that Recommendation, because it introduces a lot of new functionality. I think what the group should try to strive for is a specification that will work with the most recent version of H.323-- H.323v4. Of course there will be few implementations, but there are not a large number of new mandatory features. (I don't have a list handy.) For a "bigger picture" view of what's new in the various versions of H.323, see: http://www.packetizer.com/iptel/h323/ Best Regards, Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)att.com> To: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>; <sip-h323(a)egroups.com> Sent: Monday, August 28, 2000 10:32 PM Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft > Hi, Everyone: > > Here is my view as stated below: > > It is very difficult to find any vendor to support H.323 version 3. Many > companies are now testing vendor implementations of H.323 version 2, and it > is also reported that multivendor interoperability at the version 2 level is > still problematic. In many cases, no promise has been obtained from the > major vendors when they will support version 3. It may be very nice to have > SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should > come first. > > Considering all factors, I think that we should keep our first interworking > requirements to support H.323 version 2 as defined in the present draft > (while we may consider for H.323 version 3 in the future). > > So, I recommend that we should make any changes in the present draft. > > Best regards, > Radhika R. Roy > AT&T > +11 732 420 1580 > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Sunday, August 27, 2000 10:32 PM > To: sip-h323(a)egroups.com > Subject: [sip-h323] SIP-H.323 interworking Requirements Draft > > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. > > We would appreciate if you would kindly provide your comments on the point. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > > -------------------------- eGroups Sponsor -------------------------~-~> > GET A NEXTCARD VISA, in 30 seconds! Get rates > of 2.9% Intro or 9.9% Ongoing APR* and no annual fee! > Apply NOW! > http://click.egroups.com/1/7872/7/_/302437/_/967516325/ > ---------------------------------------------------------------------_-> > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: [sip-h323] SIP-H.323 interworking Requirements Draft
by Roy, Radhika R, ALCOO 28 Aug '00

28 Aug '00

FYI -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Monday, August 28, 2000 10:41 PM To: 'sip-h323(a)egroups.com'; sip-h323(a)egroups.com Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Henning: I agree with you (please also see my response provided below). Best regards, Radhika R. Roy -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Monday, August 28, 2000 12:12 PM To: sip-h323(a)egroups.com Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft "Roy, Radhika R, ALCOO" wrote: > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. What practical difference does it make? Could you summarize the relevant differences? Presumably, a v3 terminal is going to interoperate with v2 terminals. For the next year, at the very least, the only real implementation to worry about is NetMeeting (v2, I assume). -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Monday, August 28, 2000 10:32 PM To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Everyone: Here is my view as stated below: It is very difficult to find any vendor to support H.323 version 3. Many companies are now testing vendor implementations of H.323 version 2, and it is also reported that multivendor interoperability at the version 2 level is still problematic. In many cases, no promise has been obtained from the major vendors when they will support version 3. It may be very nice to have SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should come first. Considering all factors, I think that we should keep our first interworking requirements to support H.323 version 2 as defined in the present draft (while we may consider for H.323 version 3 in the future). So, I recommend that we should make any changes in the present draft. Best regards, Radhika R. Roy AT&T +11 732 420 1580 -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Sunday, August 27, 2000 10:32 PM To: sip-h323(a)egroups.com Subject: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Everyone: I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our SIP-H.323 Interworking requirement draft was also discussed. The Q.13 members have strongly recommended that we should consider H.323 version 3 (instead of version 2) for our SIP-H.323 interworking work. We would appreciate if you would kindly provide your comments on the point. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

IP Telecom Services Workshop 2000: Final Call for Participation
by Gregory W. Bond 28 Aug '00

28 Aug '00

[Please accept our apologies for multiple copies of this call.] ------------- FINAL CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two distinguished invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner President and CEO of dynamicsoft "The End of Telephony" Invited Speaker - Joe Rinde AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com) WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Open Letter To Dale Skran
by Tom-PT Taylor 26 Aug '00

26 Aug '00

At the meeting just concluded, you described and criticized a contribution to 3GPP2, naming Nortel Networks as the contributor. In the process, you managed to imply that Nortel was less than competent, that 3GPP2 was gullible, and that no other company provided a contribution favouring the eventual 3GPP2 decision. I have to assume that in doing so you felt it your duty as Q.13/16 Rapporteur to publicly admonish a major company that supports the use of H.323 only in the enterprise environment. Any other interpretation of your motives would imply immediately that you had abused your position as Rapporteur on behalf of your employer or for personal reasons. However, I would argue that even with the stated motive, your actions were improper within the context of an ITU-T meeting. The ITU-T (unlike many private fora) is neither a marketing organization nor a religious exercise. In our respective domains, both Francois Audet and I have made significant contributions to the work of Study Group 16 on behalf of our employer. You have performed your work as Rapporteur with great skill, and we all appreciate it. This does not give you the right to use your position as a pulpit to denounce sinners. I would hope that on reflection you agree and are prepared to say so publicly. Tom Taylor Nortel Networks

1 0