[Robustness] H.225 & H.245 state info

[Paul E. Jones]

Terry,

This looks good.

You raised the issue that Release Complete may not be acknowledged and asked
what to do.

I'd like to take this opportunity (again) to raise a few points:
  1) There is a lot of call state information that should not be lost
     (You had a nice long list.)
  2) In addition to your list, in order to support robustness in a
     multipoint call, there are several more elements.
  3) I don't want to complicate the whole system with robustness.
     Robustness should be a natural extension and not burden to
     implement.
  4) Since we are doing this within the scope of V4 and higher,
     we have an opportunity to add some constraints to resolve
     issues such as "release complete".  In particular, I think
     we should consider requiring that robustness only work
     when using a "connectionless" protocol and that H.245
     shall be tunneled with the call signaling channel.  The
     connectionless protocol can guarantee delivery of the
     "release complete" message end to end.

Paul

----- Original Message -----
From: "Terry L Anderson" <tla at LUCENT.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Friday, March 31, 2000 5:13 PM
Subject: [Robustness] H.225 & H.245 state info


> I have been working on collecting the call state information present in
various
> H.323 network elements.  The goal is to:
> 1. see what data is present
> 2. suggest what data must be re-established if a new element takes over
(or an
> element recovers but has lost call state data) in order to allow the call
to
> continue at various specified levels of recovery:
>     - call can continue but billing data lost
>     - call can continue with full billing data
>     - etc.
>
> I have certainly not completed this study, but have collected a fairly
complete set
> of call state data items and put them into a table indicating which
element(s) they
> reside in.  The plan is to choose a notation to indicate how vital each
element is
> for various levels of recovery and which other element has the data that
can be used
> to restore it in the new element.
>
> I will share this much at this time and perhaps we can begin a discussion
about
>     - completeness (what I have missed)
>     - presentation (is there another format that could make the
information more
> understandable)
>
> I am attaching it as a word document.
>
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:tla at lucent.com
> Tel:908.582.7013   Fax:908.582.6729
> Pager:800.759.8352 pin 1704572   1704572 at 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
>
>