[Robustness] Some Issues

[Terry L Anderson]

I got no one on the call today - perhaps because of the late notice.
Let's try addressing some issues by email.

Sec 8.4 discusses H.245 Connection Reestablishment.  I think there are a
few small issues.

1.  While multiple calls can be signaled over a single CallSig
connection, I do not believe that this is permitted on H.245 Call
Control Signaling channels.  So we do not have to be concerned with
multiple calls when H.245 fails, right?

2. Assume CallSig channel failed and we have a separate H.245 channel
which also failed (tunneled H.245 does NOT have this issue).  We say,
send "endSessionCommand" on the H.245 channel and then drop the
connection.  Then reestablish CallSig, send Facility with our h245addr.
The other end reestablishes H.245 channel to us.

issue 2a. If the endSessionCommand makes it through (we detected failure
but it wasn't completely dead?), won't the other end believe that the
call is over, hangup, send us ReleaseComplete, etc. so we won't be able
to recover?  Before these procedures, loss of H.245 ended the call.  Do
we need a flag in endSessionCommand to indicate that we are "replacing"
the channel rather than ending the call?  Or can we omit the
endSessionCommand - just drop the connection that we believe is dead.
The Facility command will tell the other end to re-establish, dropping
its end if necessary.

issue 2b. How do the two entities with the new h.245 channel know that
this is a replacement and NOT do to initialization procedures
(master/slave, capabilities exchange)?  The end sending Facility knows
and could remember this when the channel is established TO it from the
other end.  How does the end receiving Facility, distingish this from
case where a new channel is needed (transition from fastStart or
tunnelling)?  By the fact that it has or had a distinct h.245 channel
for that call already?  Is this good enough, or do we need a flag in
Facility or a Reason to indicate "RE-establishment"?

3. Assume that CallSig has NOT failed but separate H.245 has failed.
This case is not clearly covered by the current wording in the
paragraph, but I think the issues are the same.  We either send
endSessionCommand before dropping the "dead" connection or not as we
decided in issue 2a.  and then use Facility over the unfailed CallSig
channel to re-establish.  I will change the wording to clearly cover
this case as well.

Section 6.4.1.  We currently specify that if a CallSig connection fails
we re-establish to the BACKUP transport address.  There is some chance
that the failure does NOT prevent a new connection to the original
entity, e.g., failure of a socket listener process or a temporary
failure.  Recovering the call is easier in the original entity than in
the backup since the call state may still be locally available.  It
would be nice to have a way to try the original entity before trying the
backup.  But we do not want to wait for the timeout of a TCP connection
attempt.  Should we consider or at least permit (make optional) a
mechanism to probe the original entity with something like ping to test
for network connectivity and operating system being alive first and if
successful attempt re-establishing TCP to original entity BEFORE trying
backup?

Section 6.4.3 closing old tcp connections.
My notes imply that someone on a previous call may have had a problem
with this section, but I have lost who or what the problem was.  If
someone has a problem with it, repeat the issue.

Section 6.3 Editor's note at the end.
This describes a case that we discussed in a previous call.  The goal
was to reduce the number of KeepAlive messages for multiple calls
between the same two entities.  This is simple for the case where the
calls are signaled on a single multiplexed TCP connection (and we
discuss that).  The issue is to use a single KeepAlive even when there
is more than one TCP connection used.  The problem we have is to
identify all the calls that are truely between the same two entities.
Analysis of special cases lead us to conclude that this could NOT be
done without adding an additional globallyUniqueId to label the calls
that were "clustered" or related to one KeepAlive exchange.  The issue
was whether a solution requiring an additional id field is worth the
benefit.

Another solution that I do not believe we considered is for the
KeepAlive message to add a field that carries some id of the other
channels it applies to, but it is not clear in this case either, how to
designate the channels.  TransportAddress is not sufficiently unique,
nor is the IPAddr of the establishing end.  Since multiple calls may be
on the channel, one cannot use callId or CRV.  So we still have a
problem requiring some new globallyUniqueId (note that is must be
globally unique, since the connection may well be between two zones).

I'd like to hear from folks that think this is worth solving even if it
requires maintenance of a new Id or any new solution that might avoid
it.



--
------------------------------------------------------------
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/20001012/d1b3ef41/attachment-0003.vcf>