XRS RequestSeqNum can't be zero

[Paul Long]

Annex H/H.225.0v2 states that "RequestSeqNum ::= INTEGER (1..65535),"
but 7.17/H.225.0v2 says that requestSeqNum in XRS "shall be the
requestSeqNum of the unknown message, if it can be decoded, and zero
otherwise."

Two problems:

1. It can't be set to zero because that value would be out of range, so
H.225.0 contradicts itself here.

2. If the requestSeqNum of the unknown message cannot be decoded, there
is no way to indicate this in the XRS.

The receiver of XRS doesn't know whether the value, let's say 1,
reflects the value of the decoded requestSeqNum of the unknown message
or is a dummy value used in place of an undecodable requestSeqNum. IOW,
to the receiver of the XRS message, the value of the requestSeqNum field
may _or may not_ refer to a message it sent, and therefore the value
cannot be trusted. I don't know of any way to fix this. Maybe we can
just always assume that the value is valid--it was successfully decoded
from the unknown message--and don't worry about the small chance of it
being wrong.


Apart from these problems, the passage quoted, above, from
7.17/H.225.0v2 implies that RequestSeqNum is unique across all outgoing
RAS messages; otherwise, what is the point of providing it in XRS--how
could the receiver of an XRS identify which message was not understood
if it uses a separate requestSeqNum variable for each xRQ? I know that
the scope of RequestSeqNum was discussed several months ago, and I agree
with the consensus that a receiver of an xRQ should not make any
assumptions about the scope. I just wanted to point out that a receiver
of XRS can only reliably use the requestSeqNum field if it uses a global
RequestSeqNum in outgoing xRQs.

Paul Long
Smith Micro