解码TCAP消息-对话部分 [英] decodingTCAP message - dialoguePortion

问题描述

我正在为整个M3UA-SCCP-TCAP-MAP堆栈(通过SCTP)编写模拟器(出于学习目的).到目前为止，M3UA + SCCP堆栈还可以.

I'm writing an simulator (for learning purposes) for complete M3UA-SCCP-TCAP-MAP stack (over SCTP). So far M3UA+SCCP stacks are OK.

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部分时，我迷失在dialogPortion上.TCAP是asn.1编码的，因此所有内容都是tag + len + data.Wireshark对它的解码方式与我的解码器不同.

But upon decoding TCAP part I got lost on dialoguePortion. TCAP is asn.1 encoded, so everything is tag+len+data. Wireshark decode it differently than my decoder.

消息是:62434804102f00676b1e281c060700118605010101a011600f80020780a1090607040000010005036c1ba1190201010201163011800590896734f283010086086059062859107

Message is: 62434804102f00676b1e281c060700118605010101a011600f80020780a1090607040000010005036c1ba1190201010201163011800590896734f283010086059062859107

基本上，我的邮件被误码为

Basically, my message is BER-decoded as

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-dialog不是在dialogPortion中，而是在otid之后的字段，这不是ITU-T文档中描述的-或不是我所理解的)

So I can see begin[2] message containing otid[8], dialogPortion[11] and componentPortion[12]. otid and ComponentPortion are decoded correctly. But not dialogPortion. ASN for dialogPortion does not mention any of these codes. Even more confusing, wireshark decode it differently (oid-as-dialogue is NOT in the dialoguePortion, but as a field after otid, which is NOT as described in ITU-T documentation - or not as I'm understanding it)

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中找不到任何有关填充的参考.

I can't find any reference for Padding in dialoguePDU ASN.

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

Can someone point me in the right direction? I would like to know how to properly decode this message

在这种情况下，DialoguePDU格式应该很简单:

DialoguePDU format should be simple in this case:

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仍然是错误的:-).但是，那是显示.它正确显示值-仅在错误的部分显示.可能是由于更容易解码造成的.

Wireshark is still wrong :-). But then... that is display. It displays values correctly - only in the wrong section. Probably some reason due to easier decoding.

我所缺少的是EXTERNAL [8]的定义.DialoguePortion被声明为EXTERNAL ...所以现在一切都变得合理了.

What I was missing was definition of EXTERNAL[8]. DialoguePortion is declared as EXTERNAL...so now everything makes sense.

这篇关于解码TCAP消息-对话部分的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！