Question

我正在为完整的M3UA-SCCP-TCAP-MAP堆栈（通过SCTP）编写模拟器（用于学习目的）。到目前为止M3UA + SCCP堆栈都可以。

M3UA Based on the RFC 4666 Sept 2006
SCCP Based on the ITU-T Q.711-Q716
TCAP Based on the ITU-T Q.771-Q775

但是在解码TCAP部分时，我在对话中丢失了。 TCAP是asn.1编码的，所以一切都是tag + len + data。 Wireshark解码方式与我的解码器不同。

消息是： 62434804102f00676b1e281c060700118605010101a011600f80020780a1090607040000010005036c1ba1190201010201163011800590896734f283010086059062859107

基本上，我的消息被BER解码为

Note: Format: hex(tag) + (BER splitted to CLS+PC+TAG in decimal) + hex(data)
 62 ( 64 32 2 )
     48 ( 64 0 8 ) 102f0067
     6b ( 64 32 11 )
         28 ( 0 32 8 )
             06 ( 0 0 6 ) 00118605010101    OID=0.0.17.773.1.1.1
             a0 ( 128 32 0 )
                 60 ( 64 32 0 )
                     80 ( 128 0 0 ) 0780
                     a1 ( 128 32 1 )
                         06 ( 0 0 6 ) 04000001000503    OID=0.4.0.0.1.0.5.3
     6c ( 64 32 12 )
        ...

所以我可以看到包含otid [8]，dialogPortion [11]和componentPortion [12]的begin [2]消息。 otid和ComponentPortion正确解码。但不是dialogPortion。 dialogPortion的ASN没有提到任何这些代码。更令人困惑的是，wireshark对它进行了不同的解码（oid-as-dialogue不在对话中，而是作为otid之后的字段，不是ITU-T文档中描述的 - 或者不是我理解它）< / p>

Wireshark decoded Transaction Capabilities Application Part
    begin
        Source Transaction ID
            otid: 102f0067
        oid: 0.0.17.773.1.1.1 (id-as-dialogue)
        dialogueRequest
            Padding: 7
            protocol-version: 80 (version1)
                1... .... = version1: True
            application-context-name: 0.4.0.0.1.0.5.3 (locationInfoRetrievalContext-v3)
        components: 1 item
           ...

我无法在dialogPDU ASN中找到Padding的任何参考。

有人能指出我正确的方向吗？我想知道如何正确解码此消息

在这种情况下，

DialoguePDU格式应该很简单：

dialogue-as-id OBJECT IDENTIFIER ::=  {itu-t recommendation q 773 as(1) dialogue-as(1) version1(1)}

DialoguePDU ::= CHOICE {
  dialogueRequest   AARQ-apdu,
  dialogueResponse  AARE-apdu,
  dialogueAbort     ABRT-apdu
}

AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE {
  protocol-version          [0] IMPLICIT BIT STRING {version1(0)} DEFAULT {version1},
  application-context-name  [1]  OBJECT IDENTIFIER,
  user-information          [30] IMPLICIT SEQUENCE OF EXTERNAL OPTIONAL
}

Answer 1

Wireshark还是错的:-)。但是......那就是展示。它正确显示值 - 仅在错误的部分显示。可能是因为更容易解码的原因。

我缺少的是EXTERNAL的定义[8]。 DialoguePortion被声明为EXTERNAL ...所以现在一切都有意义。

Answer 2

对于你的消息，我自己的解码器说：

    begin [APPLICATION 2] (x67) 
        otid [APPLICATION 8] (x4) =102f0067h
        dialoguePortion [APPLICATION 11] (x30) 
            EXTERNAL (x28) 
                direct-reference [OBJECT IDENTIFIER] (x7) =00118605010101h
                encoding:single-ASN1-type [0] (x17) 
                    dialogueRequest [APPLICATION 0] (x15) 
                        protocol-version [0] (x2) = 80 {version1 (0) } spare bits= 7
                        application-context-name [1] (x9) 
                            OBJECT IDENTIFIER (x7) =04000001000503h
        components [APPLICATION 12] (x27) 
            invoke [1] (x25) 
                invokeID [INTEGER] (x1) =1d (01h)
                operationCode [INTEGER] (x1) = (22) SendRoutingInfo
                parameter [SEQUENCE] (x17) 
                    msisdn [0] (x5) = 90896734f2h
                        Nature of Address: international number (1)
                        Numbering Plan Indicator: unknown (0)
                        signal= 9876432
                    interrogationType [3] (x1) = (0) basicCall
                    gmsc-Address [6] (x5) = 9062859107h
                        Nature of Address: international number (1)
                        Numbering Plan Indicator: unknown (0)
                        signal= 26581970

现在，wireshark的填充7和我的备用位= 7都是指协议版本字段，在Q.773中定义为：

AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE {
     protocol-version [0] IMPLICIT BIT STRING { version1 (0) }
     DEFAULT { version1 },
     application-context-name [1] OBJECT IDENTIFIER,
     user-information [30] IMPLICIT SEQUENCE OF EXTERNAL
     OPTIONAL }

BIT STRING定义，只为前导位（版本1）指定名称...其余（7位）没有给出名称，wireshark认为它们是 padding

decodeTCAP消息 - dialogPortion

2 个答案: