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

[Terry L Anderson]

Maureen Stillman wrote:

> Terry, thanks for compiling on this important state information for H-323.
>
> For those of us who are nit-picking could you give us a definition for the
> elements in the table?
>
> x
> o
> t
> new(???)
> n/a
> (blank), etc.

Sorry.  I should have put more description with it.
x= network element possesses the indicated data
o= network element possesses the indicated data, but it is an origination
zone-only value
t= network element possesses the indicated data, but it is a termination
zone-only value
na= not applicable, eg. for callSignalingAddress of peer toward origin has no
meaning for the originating endpoint
new=these are data that might be present using IEs just introduced in Geneva
(eg, Billing in RAS).
blank= network element does NOT possess the indicated data.

> I'm not really sure what they mean.  The labels at the top of the table, why
> they are there also need some definition, although I think I know what they
> mean.  A paragraph on the scope of the table would also clarify, for
> example, are conference calls included?

Columns indicate a network element.  There are separate columns for gatekeepers
implementing GK-routed and Direct Call Signaling because the data known to the
gatekeeper is quite different.

Note I have not yet tried to include an MCU and there are undoubtedly additional
data in MCU relating to multiparty conference state.

The current table also may be missing some H.245 state, but I think it has the
relevant H.245 state for a "stable call", which was our first goal to recover.

> Also, if you could take us thru one scenario in the table that has different
> elements in it, that would be helpful.  I want to make sure I have the right
> interpretation of the table before we talk about it on Thursday at the
> teleconference.

Not sure I know what you mean by "scenario in the table".  What I intended to
use the table for (as suggested in my original mail), was to annotate it with
indications of which data elements must be restored to "recover" the call at
various levels of recovery.   For example, if an Originating Direct Call
Signaling GK is lost and a secondary GK takes over for an existing call, what
data elements must it get from originating endpoint to function.

Once we know that we can determine whether we need new RAS or Call Signaling
messages and IEs to support this restoration of state data.

So I guess the next step is to see if the data element list is complete and
accurate and then begin discussing which elements, if not recovered, prevent the
call from continuing successfully.

> Thanks.
>
> -- maureen
>
> -----Original Message-----
> From: EXT Terry L Anderson [mailto:tla at LUCENT.COM]
> Sent: Friday, March 31, 2000 5:14 PM
> To: ITU-SG16 at mailbag.cps.intel.com
> 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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 548 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000403/73dea589/attachment-0006.vcf>