解码 TCAP 消息 - dialoguePortion
decodingTCAP message - dialoguePortion
我正在为完整的 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 部分时,我在 dialoguePortion 上迷路了。
TCAP是asn.1编码的,所以一切都是tag+len+data。
Wireshark 解码它的方式与我的解码器不同。
消息是:
62434804102f00676b1e281c060700118605010101a011600f80020780a1090607040000010005036c1ba1190201010201163011800590896734f2830=519106780[
基本上,我的消息被 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 的 ASN 没有提及任何这些代码。
更令人困惑的是,wireshark 对其进行了不同的解码(oid-as-dialogue 不在 dialoguePortion 中,而是作为 otid 之后的一个字段,这与 ITU-T 文档中描述的不同——或者不像我理解的那样)
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
...
我在 dialoguePDU ASN 中找不到任何关于填充的参考。
有人能指出我正确的方向吗?
我想知道如何正确解码此消息
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
}
Wireshark 仍然是错误的:-)。但是……那就是展示。它正确显示值 - 仅在错误的部分。可能是由于更容易解码的原因。
我缺少的是 EXTERNAL[8] 的定义。 DialoguePortion 被声明为外部......所以现在一切都有意义了。
对于你的消息,我自己的解码器说:
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 的 padding 7 和我的 spare bits=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 将它们视为 填充
我正在为完整的 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 部分时,我在 dialoguePortion 上迷路了。 TCAP是asn.1编码的,所以一切都是tag+len+data。 Wireshark 解码它的方式与我的解码器不同。
消息是: 62434804102f00676b1e281c060700118605010101a011600f80020780a1090607040000010005036c1ba1190201010201163011800590896734f2830=519106780[
基本上,我的消息被 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 的 ASN 没有提及任何这些代码。 更令人困惑的是,wireshark 对其进行了不同的解码(oid-as-dialogue 不在 dialoguePortion 中,而是作为 otid 之后的一个字段,这与 ITU-T 文档中描述的不同——或者不像我理解的那样)
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 ...
我在 dialoguePDU ASN 中找不到任何关于填充的参考。
有人能指出我正确的方向吗? 我想知道如何正确解码此消息
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
}
Wireshark 仍然是错误的:-)。但是……那就是展示。它正确显示值 - 仅在错误的部分。可能是由于更容易解码的原因。
我缺少的是 EXTERNAL[8] 的定义。 DialoguePortion 被声明为外部......所以现在一切都有意义了。
对于你的消息,我自己的解码器说:
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 的 padding 7 和我的 spare bits=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 将它们视为 填充