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

H.323 Annex M.1 White Paper
by Francois Audet 16 Jun '00

16 Jun '00

I have sent the Whitepaper for H.323 Annex M.1 on QSIG tunnelling to Mr. Bigi. The document is available in: ftp://standard.pictel.com/avc-site/Incoming/. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

H.450.9 Whitepaper Call Completion service
by Klaghofer Karl ICN SIB NL D1 16 Jun '00

16 Jun '00

As agreed in the Osaka meeting, I have sent my input for the Whitepaper to Mr. Bigi already today. The document I sent to ITU as my whitepaper input is a clean copy of the document I have put on the pictel site for your review on May 31 ( ftp://standard.pictel.com/avc-site/0011_Gen/ ). I.e. there had been no changes since that. Regards, Karl Klaghofer, Siemens AG - Editor of H.450.9 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
by Callaghan, Robert 16 Jun '00

16 Jun '00

Orit, In my opinion, an email-ID alias conforms to RFC-822 and is interpreted according the rules stated in H.225.0. An H.323-URL-ID conforms to TD-40a/Osaka and is interpreted according to the rules stated in TD-40a. An H.323-ID is a character string without any rules of interpretation. I see no need to blend these contexts. All three addressing modes can be use; each in its own context. However, these are my opinion. Maybe more work is needed in Portland. 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: Wednesday, June 14, 2000 11:45 AM To: Callaghan, Robert; 'Paul E. Jones' Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) Subject: Re: H.323 URL Hello Bob and Paul! I don't see backwards compatibility problem, when the URL says explicitly H323-URL. An appropriate change may be to state, that the default meaning of url, encoded into email-ID alias, is according to RFC-822. Now, I feel a need to put a chapter explaining what is the meaning of email URL (apart from its syntax) when used in H.323 Network. There is some explanation in H.225.0 Appendix IV. Do you find it clear and sufficient? 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: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' <orit(a)radvision.com> Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) <ITU-SG16(a)mailbag.cps.intel.com> Date: Wednesday, June 14, 2000 9:56 AM Subject: H.323 URL >Paul, > >I have a backward compatibility item for you to think about. > >TD-40/Osaka states that the H323-URL may be coded into the email-ID for >alias address. However, H.225.0 states that the email-ID shall conform to >RFC822. This is an exclusionary requirement in that other standards may not >be used. Also, Note 4 of the BNF definition of the H323-URL clearly states >that that the H323-URL is *not* compatible with RFC822. > >Therefor, I propose that the H323-URL cannot be coded into the email-ID for >alias address because of compatibility problems. > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Enterprise Networks >Tel: +1.561.923.1756 Fax: +1.561.923.1403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

h.323+java clients
by Apoorv Misra 15 Jun '00

15 Jun '00

Does H.323 support JAVA clients? Shachi Singh, Developer, PARSEC Technologies India Ltd. India. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Revised report of the Osaka meeting
by Sakae OKUBO 14 Jun '00

14 Jun '00

Dear Q12-14/16 experts, I have placed the Osaka meeting report at the following place: ftp://standard.pictel.com/avc-site/0005_Osa/APC-1871a.zip or http://standard.pictel.com/ftp/avc-site/APC-1871a.zip This is a revision to APC-1871.zip having been in /Incoming with correction of an editorial error advised by Mr. Fortinsky and change of status to "confirmed by the participants." Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
by Orit Levin 14 Jun '00

14 Jun '00

Bob! On theoretical basis, I COMPLETELY agree with your statement. >From practical point of view (how many, and what type of aliases, the end user has the access to) we may need more work in Portland. 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: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Orit Levin' <orit(a)radvision.com>; 'Paul E. Jones' <paulej(a)PACKETIZER.COM> Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) <ITU-SG16(a)mailbag.cps.intel.com> Date: Wednesday, June 14, 2000 3:51 PM Subject: RE: H.323 URL >Orit, > >In my opinion, an email-ID alias conforms to RFC-822 and is interpreted >according the rules stated in H.225.0. An H.323-URL-ID conforms to >TD-40a/Osaka and is interpreted according to the rules stated in TD-40a. An >H.323-ID is a character string without any rules of interpretation. I see >no need to blend these contexts. All three addressing modes can be use; >each in its own context. > >However, these are my opinion. Maybe more work is needed in Portland. > >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: Wednesday, June 14, 2000 11:45 AM >To: Callaghan, Robert; 'Paul E. Jones' >Cc: Mailing list for parties associated with ITU-T Study Group 16 >(E-mail) >Subject: Re: H.323 URL > > >Hello Bob and Paul! >I don't see backwards compatibility problem, when the URL says explicitly >H323-URL. An appropriate change may be to state, that the default meaning of >url, encoded into email-ID alias, is according to RFC-822. >Now, I feel a need to put a chapter explaining what is the meaning of email >URL (apart from its syntax) when used in H.323 Network. There is some >explanation in H.225.0 Appendix IV. Do you find it clear and sufficient? >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: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> >To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' ><orit(a)radvision.com> >Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) ><ITU-SG16(a)mailbag.cps.intel.com> >Date: Wednesday, June 14, 2000 9:56 AM >Subject: H.323 URL > > >>Paul, >> >>I have a backward compatibility item for you to think about. >> >>TD-40/Osaka states that the H323-URL may be coded into the email-ID for >>alias address. However, H.225.0 states that the email-ID shall conform to >>RFC822. This is an exclusionary requirement in that other standards may >not >>be used. Also, Note 4 of the BNF definition of the H323-URL clearly states >>that that the H323-URL is *not* compatible with RFC822. >> >>Therefor, I propose that the H323-URL cannot be coded into the email-ID for >>alias address because of compatibility problems. >> >>Bob >> >>------------------------------------------------------------------ >>Robert Callaghan >>Siemens Enterprise Networks >>Tel: +1.561.923.1756 Fax: +1.561.923.1403 >>Email: Robert.Callaghan(a)ICN.Siemens.com >>------------------------------------------------------------------ >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.245 Terminates Fast Connect
by Helpdesk MIS 14 Jun '00

14 Jun '00

From: Paul E. Jones Pete, We do have one more Rapporteur's meeting, so we can try to introduce some corrective text to address this issue and then put that forward as a delayed contribution or a Rapporteur's TD (latter preferred if we can come to an agreement). I may be missing your point in (2), but perhaps this will address the question: H.323v2 says that if an endpoint initiates H.245 (tunneled or a separate connection) before getting a response to Fast Connect, Fast Connect is terminated. However, there is no such rule with H.323v3/4. An H.323v2 device could initiate a Fast Connect call and then send an H.245 message to a V3 device to terminate Fast Connect, but the V3 device would not recognize that as a termination of Fast Connect. Thus, we have two devices that are out of sync. Between two V2 devices, we have a race condition, because one side could send an H.245 message to terminate FC, while the other side returns a message with fastStart to accept Fast Connect. Again, the two are out of sync. This is what we tried to address by removing the text, but we did not address the V2/V3 interoperability issue. So, we still have a potential problem. We could resolve this by simply stating noting the V2 behavior and discouraging a V3+ device from sending an H.245 message to a V2 device prior to learning whether FC was accepted. As a worst case, if it did send an H.245 message, it should assume that it is terminating Fast Connect in the V2 device and that a race condition may exist. For V3 and V4, FC is not terminated in this way as the text now stands-- endpoints are free to start H.245 in parallel. In addition, fast connect can be explicitly rejected, which gives an endpoint the "go ahead" to do logical channel signaling to get audio and video channels open prior to CONNECT. There may be additional, more complex issues-- I may be over-simplifying the interoperability issues here in this reply. It seems simple on the surface, but I know that I have heard from more than one vendor that they were not happy with these changes. However, I think that if we could add some explanatory text to H.323v3/4 to describe the V2 behavior and document the issues, I think we can move forward with the text as it is now, but I do not want to make that conclusion without others also taking a serious look at this issue. Paul ----- Original Message ----- From: "Pete Cordell" <pete(a)TECH-KNOW-WARE.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, June 13, 2000 9:39 AM Subject: Re: H.245 Terminates Fast Connect > Paul, > > Two things... > > 1) What will be the procedure used in Geneva to decide v4. Will we have the > opportunity to put a delta document in? If we are, the correct (not > necessarily sensible!) procedure is to have the white paper as agreed in > Osaka, and un-do it (as a result of further information) in Geneva. > > 2) Fast start is limited to working on session IDs 1 and 2. As long as > H.245 specifies other session IDs with its OLC I believe this can get around > the alleged race condition. Does this make any sense? > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete(a)tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Paul E. Jones <paulej(a)PACKETIZER.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: 13 June 2000 11:17 > Subject: H.245 Terminates Fast Connect > > > > Folks, > > > > As you know, we added some text to the H.323 Implementers Guide (section > > 6.1.7) removing the text from 8.2.1/H.323 that used to state: > > > > ``The sending of encapsulated H.245 messages or the initiation of the > > separate H.245 connection by either endpoint prior to the sending of a > Q.931 > > message containing fastStart by the called endpoint terminates the Fast > > Connect procedures.'' > > > > There was also some further supporting text added to the IG, but removed > > before the final agreed document that read (this is somewhat out of date > now > > that H.323v4 devices that use Fast Connect *shall* tunnel, but text is > > necessary for V2 and V3 entities): > > ``It is possible to switch to H.245 procedures before the Fast Connect > > procedure completes. If h245Tunneling is enabled, the terminating party > may > > start using tunneling as described in 8.2.1. If H.245 transport address > is > > included in the Setup message, then the terminating party may start the > > switch to H.245 as described in 8.2.3. In either case the Fast Connect > > procedure is terminated.'' > > > > Unfortunately, removing this text (particular the text that was already > > existing the H.323) has caused all kinds of grief, as there are > > implementations that do, in fact, behave according to this text found in > > H.323v2 and H.323v3. I know a few people have discussed reversing this > > decision, but no formal proposal has been submitted. > > > > We need to have a discussion on this topic. I want to propose that the > > H.323v4 white paper *not* have this text removed. If people agree with > > that, I will bring a contribution that will propose reinstating this text. > > > > Part of the reason for its removal is that there is a race condition that > > can occur. For example, if the caller sends a Setup with fastStart and > then > > later initiates H.245 while at the same time, the called endpoint returns > a > > message with fastStart, what state is H.245 in? > > > > I believe that we can resolve the issues by documenting the fact that a > race > > condition exists and introducing a few new rules. For example, we could > say > > > > that if, as in this example above, the calling endpoint initiates H.245 > and > > then gets a fastStart element in a message, the caller shall recognize the > > fact that Fast Connect was accepted. Hopefully, no logical channel > > signaling will have taken place. If it has, the called party should > reject > > any conflicting channels, so the calling endpoint can recognize that a > > rejected channel is the result of Fast Connect being accepted and the > > channel is actually open (as per the FC received). > > > > I would like to see if we can come to any kind of agreement on this issue > > and a recommendation for a direction forward. > > > > Best Regards, > > Paul > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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
by Orit Levin 14 Jun '00

14 Jun '00

Hello Bob and Paul! I don't see backwards compatibility problem, when the URL says explicitly H323-URL. An appropriate change may be to state, that the default meaning of url, encoded into email-ID alias, is according to RFC-822. Now, I feel a need to put a chapter explaining what is the meaning of email URL (apart from its syntax) when used in H.323 Network. There is some explanation in H.225.0 Appendix IV. Do you find it clear and sufficient? 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: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' <orit(a)radvision.com> Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) <ITU-SG16(a)mailbag.cps.intel.com> Date: Wednesday, June 14, 2000 9:56 AM Subject: H.323 URL >Paul, > >I have a backward compatibility item for you to think about. > >TD-40/Osaka states that the H323-URL may be coded into the email-ID for >alias address. However, H.225.0 states that the email-ID shall conform to >RFC822. This is an exclusionary requirement in that other standards may not >be used. Also, Note 4 of the BNF definition of the H323-URL clearly states >that that the H323-URL is *not* compatible with RFC822. > >Therefor, I propose that the H323-URL cannot be coded into the email-ID for >alias address because of compatibility problems. > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Enterprise Networks >Tel: +1.561.923.1756 Fax: +1.561.923.1403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ >

1 0

H.323 URL
by Callaghan, Robert 14 Jun '00

14 Jun '00

Paul, I have a backward compatibility item for you to think about. TD-40/Osaka states that the H323-URL may be coded into the email-ID for alias address. However, H.225.0 states that the email-ID shall conform to RFC822. This is an exclusionary requirement in that other standards may not be used. Also, Note 4 of the BNF definition of the H323-URL clearly states that that the H323-URL is *not* compatible with RFC822. Therefor, I propose that the H323-URL cannot be coded into the email-ID for alias address because of compatibility problems. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.245 Terminates Fast Connect
by Paul E. Jones 13 Jun '00

13 Jun '00

Folks, As you know, we added some text to the H.323 Implementers Guide (section 6.1.7) removing the text from 8.2.1/H.323 that used to state: ``The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures.'' There was also some further supporting text added to the IG, but removed before the final agreed document that read (this is somewhat out of date now that H.323v4 devices that use Fast Connect *shall* tunnel, but text is necessary for V2 and V3 entities): ``It is possible to switch to H.245 procedures before the Fast Connect procedure completes. If h245Tunneling is enabled, the terminating party may start using tunneling as described in 8.2.1. If H.245 transport address is included in the Setup message, then the terminating party may start the switch to H.245 as described in 8.2.3. In either case the Fast Connect procedure is terminated.'' Unfortunately, removing this text (particular the text that was already existing the H.323) has caused all kinds of grief, as there are implementations that do, in fact, behave according to this text found in H.323v2 and H.323v3. I know a few people have discussed reversing this decision, but no formal proposal has been submitted. We need to have a discussion on this topic. I want to propose that the H.323v4 white paper *not* have this text removed. If people agree with that, I will bring a contribution that will propose reinstating this text. Part of the reason for its removal is that there is a race condition that can occur. For example, if the caller sends a Setup with fastStart and then later initiates H.245 while at the same time, the called endpoint returns a message with fastStart, what state is H.245 in? I believe that we can resolve the issues by documenting the fact that a race condition exists and introducing a few new rules. For example, we could say that if, as in this example above, the calling endpoint initiates H.245 and then gets a fastStart element in a message, the caller shall recognize the fact that Fast Connect was accepted. Hopefully, no logical channel signaling will have taken place. If it has, the called party should reject any conflicting channels, so the calling endpoint can recognize that a rejected channel is the result of Fast Connect being accepted and the channel is actually open (as per the FC received). I would like to see if we can come to any kind of agreement on this issue and a recommendation for a direction forward. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 2