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