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