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@mailbag.intel.com