[Robustness] Some Open Issues for Geneva meeting

Maureen Stillman Maureen.Stillman at NOKIA.COM
Mon Jan 31 15:43:18 EST 2000


Based on the robustness group teleconferences, RadVision has submitted a
delayed contribution named: RV-Robustness.zip available at:
http://standard.pictel.com/ftp/avc-site/Incoming/RV-Robustness.zip

In addition to this submission, here is an incomplete list of open issues
for robustness.  Most of these have been discussed in teleconferences or on
the mailing list.  Please send any open issues to the mailing list and we
can discuss them further in Geneva.

Thank you.

Open Issues

        1)      How does robustness interact with billing?  There are
concerns about keeping a call alive that can't be billed for properly.

        2)      Does an endpoint need to reregister with the gatekeeper
after it crashes and comes back up?  When does it perform this process?
Suppose endpoint A and B are registered with the same gatekeeper.  After B
crashes and it comes back up should it initially try to recover a call that
is in progress?  Then, if no calls are in progress, should go ahead with
gatekeeper discovery or perform gatekeeper discovery immediately?   This
scenario raises security issues....

        3)      How does security interact with robustness?  For example,
does an endpoint need to re-authenticate when it (or a gatekeeper) crashes
and comes back up?   (answer should be "yes".)  How?  There are concerns
that the robustness mechanism will introduce security holes.

        4)      What identifier (CALL ID???) will be used when H.225 and/or
H.245 connections are reopened?  RadVision's submission suggests we use the
CALL ID.

        5)      How will the H.225 and H.245 connections be reopened?  (This
might belong in the implementers guide)

        6)      There has been considerable debate on whether or not we
allow the H.225 connection to be closed during a call.  Should we change the
standard to say that it can't be closed?

        7)      The standard states that if the H.245 connection is closed
then the call is terminated.  How does this fit in with robustness
procedures?  Should we change this requirement in the standard?

        8)      (from the mailing list) If an endpoint fails to find a
gatekeeper during gatekeeper discovery, it is permitted to assume that there
is no gatekeeper around, and that it may therefore make calls without using
a gatekeeper.  It might be considered "polite", however, for an endpoint
carrying on this way to periodically check up to see if there ARE any
gatekeepers around.  At least one well-known H.323 stack acts in this way if
asked to handle RAS for its application.  The question is what should it do
if it should find a gatekeeper at this later stage?

       9) Is support for robustness mechanisms in H.323v4 mandatory or
optional?



-- maureen

Maureen Stillman
Member of Scientific Staff             Voice: (607)273-0724 x62
Nokia IP Telephony                      Fax: (607)275-3610
127 W. State Street                     Mobile: (607)227-2933
Ithaca, NY 14850
e-mail: maureen.stillman at nokia.com
www.nokia.com



More information about the sg16-avd mailing list