H.225-Annex G

Archana Nehru archie at TRILLIUM.COM
Fri Aug 4 14:29:14 EDT 2000


Aug 3 was our last Robustness call before Portland (I will be on
vacation until the Portland meeting).

Attending:
Terry Anderson - Lucent
Sasha Ruditsky - Radvision
Archana Nehru  - Trillium

Issues:
1) this was last call before portland.
2) 9.3.1.2 may not be needed
3) note 1 in 9.3.1.5 is no longer needed.
4) After detecting a TCP failure, can we find a way to probe the
original addr before establishing to backup.  There are some failures
esp on Shared Repository entities (e.g., port listener process fails but
can be restore, though keepalive timer may expire) where we might
recover and be able to reestablish to same entity.  This permits more
complete recovery, but TCP connection attempt times out too slowly to
use.  Can we probe with ping etc?
5) Parts of 9.3 should be moved to common in 8.
6) 10.3 note about race condition.  We can replace the race condition
handling by using the same logic used in H.245 channel establishment
(end with numerically smaller h245addr drop its connection).  This
handle both mux and non-mux cases.
7) item #7 in 12 isn't clear how it differ in Method A and Method B.
8) H.323 8.6 mods in 13.1.2 are for both Method A and B but how do we
handle this if H.323 is NOT changed.  Can we override this in Annex
without changing H.323 text here?
9) 8.6.1 addition is only for Method A and should move there.  If it
stays in Annex it needs to be merged with other text as there is
duplication.
10) if entity A supports only Method A and entity B has shared
repository, then it would be nice to have a specification that only B
sends keepalive and only B detects failure.  This allows recovery from
some errors (due to data in shared repository) without moving to
backup.  Effects text in several places.
11) What was our plan for backup GKs?  AltGK gives addr to RRQ and send
new ARQs to but how handle DRQs for continuing calls?  If part of
endpoint fails and recovers do we need to allow that the endpoint's
rasaddr may be different?  It can reRRQ to give the new rasaddr but how
indicate the use of new rasADDR for existing calls (IRQ, forced DRQ,
etc).  Do we need to supply backupRasAddr in RRQ or way to indicate in
RRQ that it is takeing over all calls to a previous rasAddr? Implied by
endpointId????

A new draft addressing some of these and with notes about the others was
submitted as APC-1878 and uploaded.

--
------------------------------------------------------------
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/20000804/9e3e5354/attachment-0006.vcf>


More information about the sg16-avd mailing list