Hi Augustin,
The encoding is not the same. The TYPE-IDENTIFIER.&Type specification
forces the enclosed type to be encoded as an Open Type thus ensuring
that an extra length wrapper will be added. Normally this is done so
that a complete packet can be handled at a different level in the
stack. In this case, I just think they wanted the length wrapper.
Regards,
Ed Day
Principal Engineer
Objective Systems, Inc.
[EMAIL PROTECTED]
(610) 608-4930 (voice)
(610) 321-0361 (fax)
(877) 820-4164 (toll-free voicemail & fax)
Augustin.Chevalier wrote:
>
> Hello,
>
> I don't really understand why using TYPE-IDENTIFIER.&Type(IFPPacket) instead
> of IFPPacket itself in the syntax (extracted from T38) below! If I'm not
> mistaken the result should be the same : only the values of the IFPPacket
> type are expected here.
> Have someone an explanantion.
>
> IFPPacket::=SEQUENCE
> {
> type-of-msg Type-of-msg,
> data-field Data-field OPTIONAL
>
> }
> UDPTLPacket::=SEQUENCE
> {
> seq-number INTEGER(0..65535),
> primary-ifp-packet TYPE-IDENTIFIER.&Type (IFPPacket),
> error-recovery CHOICE
> {
> secondary-ifp-packets SEQUENCE OF TYPE-IDENTIFIER.&Type(IFPPacket),
> fec-info SEQUENCE
> {
> fec-npackets INTEGER,
> fec-data SEQUENCE OF OCTET STRING
> }
> }
> }
>
> many thanks
>
> Augustin Chevalier
