[Robustness] telecon -- April 6 9AM EST USA
The next robustness teleconference will be held on Thursday, April 6 at 9AM EST USA. Please send me e-mail at maureen.stillman@nokia.com if you plan to attend (some have sent e-mail already).
The number to call is: (613)688-2795 the passcode is 8689# You must enter the pound sign after the passcode.
The agenda is:
* Terry Anderson will provide H.225 and H.245 state machines for us to review. * Randy Stewart and Qiaobing Xie of Motorola will join us to discuss SCTP and DDP and answer questions. * Discuss the SDL for the robustness procedure produced by Sasha Ruditsky of Radvision (attached). This SDL is for the Geneva SG-16 document from the February 2000 meeting, document TD87 from WP2.
SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt)
DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt
-- maureen <<RobustnessSDL.ZIP>>
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@nokia.com www.nokia.com
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@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
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@LUCENT.COM To: ITU-SG16@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:
- see what data is present
- 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@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
participants (3)
-
Maureen Stillman -
Paul E. Jones -
Terry L Anderson