XRS RequestSeqNum can't be zero

[Ernst Horvath]

Dear Mr. Long,

A clean fix for the problem you discovered would be to allow 0 as a
special value in RequestSeqNum:

   RequestSeqNum ::= INTEGER (0|1..65535)
    -- 0 reserved for XRS if the received message could not be decoded

(A similar problem exists in ROSE where the InvokeID - an INTEGER - is
used to associate responses with requests; usually the response contains
the same InvokeID as the request, except when the request cannot be
decoded. In this case a Reject is sent with InvokeID ::= NULL. The same
approach could be used in H.225.0, but this would be a rather drastic
change totally incompatible with version 1).

Ernst Horvath
Siemens AG

Paul Long wrote:
> 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
>