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