decodingTCAP message - dialoguePortion

Question

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

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.

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 )
        ...

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
           ...

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 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
}

It seems that my decoding is correct. But why wireshark decode it differently? [Online ASN1 decoder](https://holtstrom.com/michael/tools/asn1decoder.php) decode it the same as I do — Sergej Srepfler, Jun 30 '15 at 18:43

score 0 · Accepted Answer · answered Jul 09 '15 at 19:20

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.

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

score 0 · Answer 2 · answered Nov 11 '15 at 17:27

For your message, my very own decoder says:

    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

Now, wireshark's padding 7 and my spare bits=7 both refer to the the protocol-version field, defined in Q.773 as:

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 }

the BIT STRING definition, assigns name to just the leading bit (version1)... the rest (7 bits) are not given a name and wireshark consider them as padding

decodingTCAP message - dialoguePortion

2 Answers2

Linked