TD-50/Osaka - Changes to the conferenceGoal field

[Rich Bowen]

Robustness folks,

A couple of comments on TD-42/Osaka -

1) While adding the ASN.1 from TD-42 to the draft H.225.0 v4, I noticed
the following paragraph about using StatusInquiry as a keepalive
mechanism:

"The element closer to the called party shall send StatusInquiry
periodically (this is the direction of least traffic during established
calls).  The period should be configurable.  Two seconds is the
recommended default, in order to allow detection of failure before other
messages timeout.  The selected value must be added to StatusInquiry so
that the recipient can also monitor failure without an additional
StatusInquiry/Status exchange in the opposite direction.  The recipient
system needs only to maintain a timer using the indicated value as a
timeout."

This clause indicates that the period at which StatusInquiry is sent is
also the amount of time that the receiving system should use as a
timeToLive timer.  This arrangement would result in a race condition
since the next StatusInquiry would be expected at the exact moment that
the timeToLive timer was due to expire.

IMHO, the StatusInquiry period and the timeToLive should be separately
configurable, both having default values defined in Annex R, with the
obvious restriction that timeToLive shall be greater than the
StatusInquiry period.

2) Has consideration been given to adding the ability for the endpoint
to indicate to the GK via the ARQ that a particular call requires
robustness, or to allowing the GK to indicate to the EP that the EP must
use the robustness procedure for a particular call?  Several other
features added in v4 use this model and it seems to be a useful
framework.

- Rich

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com