- sg16-avd - lists.packetizer.com

[apc] Re: Request for 2 APC numbers for the Osaka Rapporteurs meeting
by Sakae OKUBO 11 Apr '00

11 Apr '00

Dear Mr. Euchner, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1753 >"White Paper H.235 VERSION 2 - SECURITY AND ENCRYPTION FOR H-SERIES >(H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS" APC-1754 >"White Paper H.323 Annex J - Security for H.323 Annex F" 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 ***********************************************************

1 0

Contribution for Uploading
by Roy, Radhika R, ALARC 10 Apr '00

10 Apr '00

Hi, Paul: I am enclosing one of the contributions for uploading in the ITU-T SG16 Ad Hoc Mobility Web server: MD-017: "H.323 Mobile Communications Environments and Intra-Zone Mobility Management." I plan to send MD-18 tomorrow. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com

1 0

[Robustness] Modifying Annex E to support Robustness?
by Tim Chen 10 Apr '00

10 Apr '00

Hi, There are a couple of thoughts we have regarding H.323 robustness: 1) As specified in TD87 from the Geneva meeting, "status inquiry" and "status" messages are used to resync call states. This may lead to a tremendous amount of load at the gatekeeper. A gatekeeper routed call requires 2 status inquiries and 2 status messages, plus the messages needed to re-establish the TCP connections. For a gatekeeper handling several thousand calls, this is a lot of messages. 2) Besides considering SCTP, have we considered modifying Annex E procedures to achieve robustness at network interface? If a NIC on a gatekeeper fails, endpoints trying to contact the gatekeeper could use a recovery address on another NIC to resend their messages. Is there any reason why this cannot be done or is undesirable? Such approach avoids invoking the procedures mentioned in TD87 to re-synchronize call states and to re-establish TCP connections. Since we are proposing a new set of procedures for a 323 entity to support robustness, backward compatibility doesn't seem like a problem. Thanks. Regards, Tim ------------------------------------------------------------ Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim(a)trillium.com http://www.trillium.com

3 2

Re: [Robustness] mechansims for H.450
by Callaghan, Robert 10 Apr '00

10 Apr '00

Maureen, I think what was talked about is that the H.450.x specification have fault detection built-in. As an example, messages are timed when waiting for a response. Also, irrevocable actions usually wait for a confirmation of success with a fall back on failure. In that features have a finite life, there is minimal need for long term recovery. I hope that this helps. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Maureen.Stillman(a)nokia.com [mailto:Maureen.Stillman@nokia.com] Sent: Monday, April 10, 2000 2:02 PM To: Robert Callaghan Subject: [Robustness] mechansims for H.450 Bob, At our last robustness teleconference, we recalled your discussion in Geneva of reliability mechanisms built into the protocol for H.450, but couldn't remember the details. Could you post a high level summary to the SG-16 mailing list of H.450 reliability mechanisms? Thanks. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

[Robustness] Next conference call - April 12 9AM EST USA - minute s attached from 1/6/2000 conference call
by Maureen Stillman 10 Apr '00

10 Apr '00

The next robustness conference call will be held on April 12 9AM EST USA. The phone number is: (613)688-2795 The passcode is: 9501# You must enter the # sign after the passcode. Agenda: We will be discussing the IETF SCTP and DDP protocols and their applicability to H.323 robustness. DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt) Please join us. Here are the minutes from the last robustness teleconference: Minutes of H.323 Robustness Teleconference - April 6, 2000 Prepared by Maureen Stillman, Nokia Next Teleconference: Scheduled for April 12, 2000 9AM EST USA Action items from 4/6/2000 teleconference: 1. Post meeting minutes to mailing list 2. Jorg Ott will provide failure scenarios for gatekeepers for the Robustness Framework document. 3. Review Terry Anderson's H.225 and H.245 state machine document. We need to begin to determine what state information should be kept and how it should be restored under different failure scenarios. 4. Review IETF's SCTP and DDP protocols. Randy Smith and Qiaobing Xie will join us to answer questions about these protocols. 5. Ask Bob Callahan about the robustness built into the H.450 protocol. Attending the 4/6/2000 teleconference: Maureen Stillman maureen.stillman(a)nokia.com Sasha Ruditsky sasha(a)tlv.radvision.com Paul Jones paul.jones(a)ties.itu.int Randy Stewart rstewar1(a)email.mot.com Qiaobing Xie xieqb(a)cig.mot.com Terry Anderson tla(a)lucent.com Timothy Sipsey Timothy.Sipsey(a)Aspect.com Summary of Teleconference: Elements of call state: We discussed the "Elements of call state" document produced by Terry Anderson of Lucent. What we need to do next with this information is to determine the following: 1) What state information needs to be kept under what circumstances? 2) What information needs to be restored under what conditions? 3) Where does a component get this state information? 4) What state information needs to be exchanged? There needs to be some way of notating this information on the "Elements of Call State" table that is included in the document. If we decide to support different levels of robustness then under different conditions some state information will be considered vital, and some will not. An example of this is billing. If billing is critical to the system, then all information critical to billing needs to be restored, otherwise some of it can be omitted. We may want to specify some range of necessity of restoration of state information. There are two parts to the state information: 1) State information that is relevant to call setup 2) State information that is exchanged after call setup is complete and the call is in a stable state. State information is exchanged in the form of messages. We need to define what we mean by "the call is in a stable state". Some state information might not be needed once the call setup is complete. Additional media channels can be opened once the call is in progress. We have agreed to only try to restore calls that are in a "stable state" in other words; we don't try to recover calls that are in the call setup phase. We need a list of failure modes to know what intermediate states can be present after a failure. We discussed failure of supplementary services H.450. We need to ask Bob Callahan to summarize the robustness mechanisms built into the H.450 protocol. Adding End to end ACKs for H.323 We discussed the possibility of adding end-to-end ACKs for all messages in order to increase the reliability of H.323 and discover that there has been a failure sooner. Annex E defines link-by-link acknowledgements, but not end to end. SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt) Randy Stewart gave a summary of the differences between SCTP and TCP. 1) SCTP setup takes one round trip time whereas TCP takes one and a half round trips. 2) SCTP is aware of multi-homing and can handle congestion. It supports network-level fault tolerance through multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. 3) SCTP gets around TCP's head of line blocking by using a stream mechanism. For example, in TCP if messages 1, 2 and 3 are sent and 1 gets lost, then 2 and 3 are held up while 1 is retransmitted. SCTP allows 2 and 3 to be delivered without waiting for 1.; supports sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages. 4) TCP takes 3-4 minutes to discover a failure and this is too long; SCTP discovers failures more quickly. 5) In Randy's performance tests of TCP versus SCTP, SCTP performed equal to TCP or better. The status of SCTP is that it is about to become an RFC. The IETF is interested in adoption of SCTP for HTTP and AAA. DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt >From the IETF internet-draft abstract: "Data Distribution Protocol (DDP) provides a fault tolerant data transfer mechanism over IP networks. DDP uses a name-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, DDP defines each logical communication destination as a named group, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. DDP is designed to take full advantage of the network level redundancy provided by the Simple Transmission Control Protocol (SCTP). But it can also use other transport protocol like TCP." We discussed the use of DDP with H.323, for example, the case where there would be a server pool of gatekeepers. We discussed the handling of state information in failure scenarios. Using DDP, the H.323 application layer will only need to determine what state information needs to be saved in case of failure, where that information should be stored and how to get it to the right place after the failure occurs. This provides a clean interface between the application layer and the DDP protocol. The decisions would be as follows: 1) What points (states) to fall back to. 2) When and where to checkpoint 3) How to reconstruct state from check pointed state information The DDP protocol allows the specification of policies for several different server pool types including: Round robin % of load (load balancing) primary -- backup The group will review the SCTP and DDP and discuss these in our next teleconference. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

Re: H.323 Mobility Contribution Numbers
by Roy, Radhika R, ALARC 10 Apr '00

10 Apr '00

Paul: Thank you very much: I would also request another MD number: "H.323 Inter-Domain Mobility Management" Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > Sent: Saturday, April 08, 2000 8:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility Contribution Numbers > > Radhika > > Your contributions numbers are MD-017 ND MD-018. Can you please load them > onto the ftp site. > > Senthil > > Please arrange as before the conference bridge for 17 April, again at 8 > a.m. > PST. Thanks. > > Paul > > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: 07 April 2000 15:27 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.323 Mobility Contribution Numbers > > Paul: > > Please provide me the numbers for the following two > contributions to be > submitted in the upcoming ad hoc mobility conf call: > > 1. H.323 Mobile Communications Environments and Intra-Zone > Mobility > Management > 2. H.323 Inter-Zone Mobility Management > > Best regards, > Radhika R. Roy > AT&T

1 0

[H.323 Mobility:] MD011b uploaded
by Jaakko Sundquist 10 Apr '00

10 Apr '00

Hi all, I have uploaded an updated version of MD011 to the ftp server (URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/). The document is in a zipped file, called Md011b.zip. I have tried to refine the document to better describe the intentions I had for the scenarios. I hope the new document clarifies and corrects some issues raised in the previous teleconference. I would appreciate, if the members of the ad hoc group (or anyone else) sent their comments regarding the contribution to the mailing list already before next Monday's teleconference so that we can already have some discussions beforehand. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------

1 0

Mobility: Contribution for Monday
by Stephen Terrill 10 Apr '00

10 Apr '00

Hi All, I couldn´t load this on the server (can I be helped with this), however I would like to distibute this for the mobility meeting next week. Regards, ..//steve

1 0

[H.323 Mobility] Contribution Number Request
by Nicolas Tran 10 Apr '00

10 Apr '00

Hi Paul G., and Mob group, Please provide me a number for the Alcatel's contribution "All-H.323 scenarios" in attachment. Best regards. (See attached file: mdxxxAlcV3.doc)

1 0

Re: Updated notice of the Osaka meeting
by Sakae OKUBO 09 Apr '00

09 Apr '00

Dear Mr. Adam H. Li, >As I mentioned in my email to the Q12-14 reflector, we are >anticipating to present a technical contribution to Annex I of H.323 >and also the simulation result for it. Could you please assign us two >APC numbers for our documents? Thanks a lot for your help. Thank you for your projected contributions to which APC-1751 and APC-1752 have been allocated. 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 ***********************************************************

1 0