- sg16-avd - lists.packetizer.com

Re: [Robustness] DDP Checkpointing (Part 2)
by Qiaobing Xie 12 Apr '00

12 Apr '00

Part 2: -Qiaobing Terry L Anderson wrote: ...snip... > It would seem preferable to either break up state information into a > number of subsets (to avoid resending large amounts each time) or to > only send differences. Since DDP gives reliable delivery to the other > members of the pool, perhaps only changes need be sent. Did your trials > solve this problem. Perhaps each call would be a separate subset. I think it's a good idea to define a checkpoint call record structure for each call that should contain the minimal information you need to recover the call. The call processing engine will checkpoint the call record at the proper time. You can for example to index the call record using call ref number. In general, what and when to checkpoint is solely an application decision. This is another big reason we left checkpointing out of DDP. > > One issue is how to solve reliable end-to-end delivery. SCTP would > guarantee delivery to other end of connection but the H.225 and H.245 > protocols may pass through intermediate nodes (e.g., routing GKs). If a > node fails after acknowledging the message but before sending it on, > end-to-end delivery fails and no live element knows. Either we need far If that message is crucial to the continuation of the call, the receiver of the message should probably checkpoint the info received before acking the sender. This way, if the receiver dies after acking the sender, the back-up of the receiver will still be able to get the info from the shared memory. In most cases, the back-up server knows it's taking over a failed peer, and will examine the recovered info from the share memory and decide what to do with the call. > end acknowledgement or backup elements must accept delivery > reponsibility once acknowledgement has been sent by its later failed > peer. DDP would guarantee delivery but the recipient would have to > checkpoint this message before acknowledgement to guarantee that a peer > taking over whould know that there was an outstanding message that it > must deliver and receive acknowledgement for. This mechanism would > require checkpoint after receipt of but before sending acknowledgement > of a message and again after receiving acknowledgement from its next > neighbor. Does this seem reasonable? It's reasonable. Again, which message/response needs to be checkpointed is REALLY an application decision which should be made case by case in each call scenario. In most cases, not every message in a call flow needs to be checkpointed since the call model itself usually have some error recovering mechanism built-in and it can recover by itself if the faulure hits at certain points of the call. > Unless the amount of data sent in > such checkpointing is kept very small this would seem to add too much > network activity to be acceptible. Always a good practice to minimize the checkpointed call record to only include critical information of the call. Also, the checkpointing traffic are localized to the server group. Proper network engineering can help a lot (eg, don't let the checkpointing traffic of a pair of heavy duty call servers run through a bottleneck router that is also handling signalling traffic).

1 0

Re: [Robustness] DDP Checkpointing
by Qiaobing Xie 12 Apr '00

12 Apr '00

See my comments below... (also see Randy's answer, mine is more from an architectural point of view) (Part 1: my mail server doesn't like long message for some reason :-) -Qiaobing Terry L Anderson wrote: > > Randy Stewart - > > You described a "checkpointing" mechanism for DDP during last week's > robustness call but it is not in the current DDP draft. However, you > have evidently thought about this some and stated (in private mail) that > you had built such mechanism on top of DDP using the SEND_TO_ALL > mechanism. How would you envision something like this being done to > synch state for a pool of H.323 entities? Would this be a application > level library that could be called from H.323 software at appropriate > checkpoint times? Could you describe this checkpointing idea in some > more detail? > We consider DDP covering only session-level fault tolerant data transfer, and therefore have left checkpointing out of DDP spec. We believe that the implementors should have full freedom to choose the most suitable checkpointing mechanism for their specific applications. Examples for checkpointing/replication mechnisms include: 1. Networked application servers on multiple hosts using one of the following replicating techniques: - IP multicast (cheap but unreliable) - DDP SEND_TO_ALL, a.k.a. groupcast (reliable, not very efficient in large group) - some Reliable Multicast protocol (still being worked on by IETF rmt WG, not sure whether they are considering "many-to-many" case though) - etc. 2. Multiple servers on the same host, using local shared memory IPC (Effective and efficient, but won't survive if the host crash, scaling problem too) 3. Servers on duplicated hardware cards on same platform (eg, cPCI box) with hardware-assist reflected memory (Very fast, not very scalable, a little expensive, won't survive platform crash.) 4. Shared network disk array (Cheap, but non-real time, disk array may become single-point-of-failure.) Internally at Motorola, we have prototyped a hybrid of 1 and 2 and created a networked (virture) shared memory using IP multicast. It works great :-)

1 0

[Robustness] DDP Checkpointing
by Terry L Anderson 12 Apr '00

12 Apr '00

Randy Stewart - You described a "checkpointing" mechanism for DDP during last week's robustness call but it is not in the current DDP draft. However, you have evidently thought about this some and stated (in private mail) that you had built such mechanism on top of DDP using the SEND_TO_ALL mechanism. How would you envision something like this being done to synch state for a pool of H.323 entities? Would this be a application level library that could be called from H.323 software at appropriate checkpoint times? Could you describe this checkpointing idea in some more detail? It would seem preferable to either break up state information into a number of subsets (to avoid resending large amounts each time) or to only send differences. Since DDP gives reliable delivery to the other members of the pool, perhaps only changes need be sent. Did your trials solve this problem. Perhaps each call would be a separate subset. One issue is how to solve reliable end-to-end delivery. SCTP would guarantee delivery to other end of connection but the H.225 and H.245 protocols may pass through intermediate nodes (e.g., routing GKs). If a node fails after acknowledging the message but before sending it on, end-to-end delivery fails and no live element knows. Either we need far end acknowledgement or backup elements must accept delivery reponsibility once acknowledgement has been sent by its later failed peer. DDP would guarantee delivery but the recipient would have to checkpoint this message before acknowledgement to guarantee that a peer taking over whould know that there was an outstanding message that it must deliver and receive acknowledgement for. This mechanism would require checkpoint after receipt of but before sending acknowledgement of a message and again after receiving acknowledgement from its next neighbor. Does this seem reasonable? Unless the amount of data sent in such checkpointing is kept very small this would seem to add too much network activity to be acceptible. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

2 1

H.248 Package Coordination
by Tom-PT Taylor 12 Apr '00

12 Apr '00

We have a number of proposed new packages in Megaco, and I'm looking for thoughts on the process for agreeing amongst the various interested parties about which should become Megaco work items and which should be worked elsewhere. I should say that this should be a two-way street -- work introduced elsewhere may be something Megaco wants to get into. Currently, I suggest that interested parties take a look at the following drafts, all available at http://www.ietf.org/internet-drafts/<draft-name> draft-bouwen-megaco-isdn-00.txt Issues for Megaco - Sigtran Interworking in ISDN Access Gateways draft-brown-supplpkgs-00.txt Supplemental Packages for Megaco/H.248 Very shortly these will be joined by packages having to do with R1 and R2 signalling. I can pass the file names along if there is interest. Tom Taylor

1 0

Re: Mob ad hoc contribution numbers
by Roy, Radhika R, ALARC 12 Apr '00

12 Apr '00

Hi, Everyone: We are getting 3 to 4 messages when we send one message to the reflector. Is that a problem with the reflector itself? Best regards, Radhika R. Roy > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Wednesday, April 12, 2000 7:30 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc contribution numbers > > As Paul asked, I have uploaded MDs 16-19 to the ftp site, I will do the > same > for Radhika's contribution MD-020 when it arrives. > > -Jaakko > > > -----Original Message----- > > From: EXT Guram Paul-LPG019 [mailto:lpg019@email.mot.com] > > Sent: 11. April 2000 15:09 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Mob ad hoc contribution numbers > > > > > > Hi mob group > > > > Nicholas Tran's contribution is to be MD-019, Radhika's new > > contribution to > > be MD-020. > > > > Please can Jaakko load these contributions (Nicolas' and all > > of Radhika's > > contributions),and Stephen Terrill's (MD-016) on to the ftp > > site, I also > > seem to have problems in loading onto the site. Thanks Jaakko. > > > > So the latest MDs for discussion are 11b, 16, 17, 18, 19 and 20. > > > > Paul > >

1 0

AW: H.450.x
by Horvath Ernst 12 Apr '00

12 Apr '00

Hi Wolfgang, H.450.x use H.225.0 call control messages for transport and the usual aliasAddress types in address fields. So there is no restriction imposed by H.450.x - what is possible for H.323 basic calls is also possible for H.450 supplementary services. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Wolfgang Bandow [mailto:wolfgang.bandow@DETEWE.DE] > Gesendet am: Mittwoch, 12. April 2000 13:41 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450.x > > Hello H.450-Experts, > > H.450.1 says "The generic functional protocol defined in this > Recommendation provides the means to exchange signalling > information for > the control of supplementary services over a LAN" (cf. chapter 5). > > Is my assumption right, that the terminals and Gatekeepers > being part of > a H.450-connection do not necessarily have to be connected to the same > LAN, but may be connected via several routers? > > Whould the following configuration be possible? > > terminal 1 gatekeeper > 1 terminal 2 > gatekeeper 2 terminal 3 > | > | > | | | > ----------------------------------LAN 1 LAN 2 > ----------------------------------------- > > | | > router > 1 router 2 > |------------- ip link > ------------| > > E.G. > terminal 3 calls terminal 1 which has activated a call diversion to > terminal 2. > The gatekeeper routed call model is used. > > Is this allowed? > What will happen? > > Thanks a lot in advance for your reply. > > Regards, > Wolfgang Bandow CT-B, Berlin >

1 0

H.450.x
by Wolfgang Bandow 12 Apr '00

12 Apr '00

Hello H.450-Experts, H.450.1 says "The generic functional protocol defined in this Recommendation provides the means to exchange signalling information for the control of supplementary services over a LAN" (cf. chapter 5). Is my assumption right, that the terminals and Gatekeepers being part of a H.450-connection do not necessarily have to be connected to the same LAN, but may be connected via several routers? Whould the following configuration be possible? terminal 1 gatekeeper 1 terminal 2 gatekeeper 2 terminal 3 | | | | | ----------------------------------LAN 1 LAN 2 ----------------------------------------- | | router 1 router 2 |------------- ip link ------------| E.G. terminal 3 calls terminal 1 which has activated a call diversion to terminal 2. The gatekeeper routed call model is used. Is this allowed? What will happen? Thanks a lot in advance for your reply. Regards, Wolfgang Bandow CT-B, Berlin

1 0

Re: Mob ad hoc contribution numbers
by Jaakko Sundquist 12 Apr '00

12 Apr '00

As Paul asked, I have uploaded MDs 16-19 to the ftp site, I will do the same for Radhika's contribution MD-020 when it arrives. -Jaakko > -----Original Message----- > From: EXT Guram Paul-LPG019 [mailto:lpg019@email.mot.com] > Sent: 11. April 2000 15:09 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Mob ad hoc contribution numbers > > > Hi mob group > > Nicholas Tran's contribution is to be MD-019, Radhika's new > contribution to > be MD-020. > > Please can Jaakko load these contributions (Nicolas' and all > of Radhika's > contributions),and Stephen Terrill's (MD-016) on to the ftp > site, I also > seem to have problems in loading onto the site. Thanks Jaakko. > > So the latest MDs for discussion are 11b, 16, 17, 18, 19 and 20. > > Paul >

1 0

Contribution for Uploading: MD-018
by Roy, Radhika R, ALARC 11 Apr '00

11 Apr '00

Hi, Paul: I am sending the contribution for uploading to the ITU-T SG16 Ad Hoc Mobility Web site: MD-018 - "H.323 Inter-Zone Mobility Management" Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com <<MD-018_H.323_Inter_Zone_Mobility.zip>>

1 0

Mob ad hoc contribution numbers
by Guram Paul-LPG019 11 Apr '00

11 Apr '00

Hi mob group Nicholas Tran's contribution is to be MD-019, Radhika's new contribution to be MD-020. Please can Jaakko load these contributions (Nicolas' and all of Radhika's contributions),and Stephen Terrill's (MD-016) on to the ftp site, I also seem to have problems in loading onto the site. Thanks Jaakko. So the latest MDs for discussion are 11b, 16, 17, 18, 19 and 20. Paul

1 0

[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

SupportedProtocol & SupportedPrefix in RAS
by 武井克明 09 Apr '00

09 Apr '00

Hi all, I am currently implementing a gatekeeper that supported only E.164 alias. H.323-ID is not supported in the current version. So I have a question. I don't enough understand the meaning of SupportedProtocol included the GatewayInfo in the EndpointType InformationElement. And the meaning of supportedPrefixes included VoiceCaps, T120OnlyCaps, H323Caps and so on. Please let me know, if anybody understand it. Regards, Katsuaki Takei $$$ Katsuaki Takei OKI Electric Industry Co., Ltd. 10-16, Shibaura 4-Chome, Minato-ku, Tokyo 108-0023, Japan Tel: +81-3-3454-2111 (EXT:46413) FAX: +81-3-3798-7684 E-mail: takei744(a)oki.co.jp $$$

2 1

Re: H.323 Mobility Contribution Numbers
by Guram Paul-LPG019 08 Apr '00

08 Apr '00

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

Re: H.323 Mobility - Annex I
by Roy, Radhika R, ALARC 07 Apr '00

07 Apr '00

Hi, Adam: It is a very good news. I would suggest to get an APC number from Mr. OKUBO. If you could upload it earlier, we would appreciate it. In fact, we have been looking for contribution for Annex I. I also draw the attention of Paul Guram related to this. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Adam Li [SMTP:adamli@ICSL.UCLA.EDU] > Sent: Thursday, April 06, 2000 10:19 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Mobility - Annex I > > Hi, there, > > We have a technical proposal for H.323 Mobility - Annex I error > resilience. We are anticipanting to present the scheme and > simulation result of it at the meeting next month in Japan. > > See you guys at Osaka. > > Adam Li > > ---------- > Adam H. Li > Image Communication Lab (310) 825-5178 > (Lab) > University of California, Los Angeles (310) 825-7928 > (Fax)

2 1

[Robustness] Use of SCTP and DDP
by Terry L Anderson 07 Apr '00

07 Apr '00

Following our discussion yesterday... If we decide to go with SCTP in our solution we might try the following: Robust-capable elements will use SCTP for all signaling (including H.225/RAS, call signaling, H.245 call control signaling, etc.) with other robust-capable elements if they decide to use robust procedures. This transport recovers from certain IP transport failures with no H.323-level procedures. Recovery from element failures requires secondary servers that can assume the lost role. Secondary servers can be designated for each element but the secondary server requires call state information. Sharing/synchronizing this information is outside the scope of the current version of the recommendation, but it is anticipated that mechanisms will be specified in future versions of the recommendation. One mechanism under consideration is DDP (which is an internet draft, but not an IETF standard at this time) and implementors of robust procedures might consider implementing DDP until a mechanism is specified. A mechanism like DDP addresses - sychronization of state information - reestablishment of application-layer connection to new server - reliable delivery of messages to one of the pool of servers *** this sort of forward reference to a non-standard permitted in an ITU recommendation? An alternative procedure for reestablishment of the connection is *** include a D-460-like description of reestablishing connections to elements that have shared state *** Sharing state information between the primary server and the secondary servers is outside the scope of the current version of this recommendation. *** the idea is to provide a solution ONLY for state-preserving server groups (ala RadVision's original proposal) rather than solve the more general case (as I previously urged) since DDP (or a solution like it) will make such server groups more practical to implement in the future. If we create our own application layer solution to the non-state perserving server now, we'll have to maintain it even after DDP is available. The above procedures allow for recovery for H.323 elements that require only packet network connections (all except endpoints, including gatekeeper, MCU, media gateway controllers, *** can H.248 be transported on SCTP? *** and border elements). *** is SCTP compatible with other packet networks or only IP. Does its use give us an IP-only solution? If so, is this acceptible in H.323? *** Most endpoints have connections that are not to packet-based networks (e.g, PSTN, terminal keyboard & screen, etc.). These connections cannot be recovered using STCP and DDP. These procedure do not support recovery if these connections are lost, but even with endpoints the procedures allow for recovery of packet-based connections, allowing the maintenance of the call unless the non-packet connection or local call state is lost. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

H.323 Mobility Contribution Numbers
by Roy, Radhika R, ALARC 07 Apr '00

07 Apr '00

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