Wireshark · Wireshark-dev: Re: [Wireshark-dev] Help on understanding Application contextinTCAPto be used by GSM MAP

["DROUIN FLORENT" <Florent.Drouin@xxxxxxxxxxxxxxxxx>]

    Hi,

 

In fact, the message should be decoded as MAP v2 with this ASN1 definition

 

<<

SM-DeliveryFailureCause ::= CHOICE {
  sm-DeliveryFailureCauseWithDiagnostic
  SM-DeliveryFailureCauseWithDiagnostic,
  -- NU1 sm-DeliveryFailureCauseWithDiagnostic must not be used in
  -- version 1
  sm-EnumeratedDeliveryFailureCause 
  SM-EnumeratedDeliveryFailureCause}
  -- NU>1 sm-EnumeratedDeliveryFailureCause must not be used in version
  -- greater 1

 

SM-EnumeratedDeliveryFailureCause ::= ENUMERATED {
  memoryCapacityExceeded  (0),
  equipmentProtocolError  (1),
  equipmentNotSM-Equipped  (2),
  unknownServiceCentre  (3),
  sc-Congestion  (4),
  invalidSME-Address  (5),
  subscriberNotSC-Subscriber  (6)}

 

SM-DeliveryFailureCauseWithDiagnostic ::= SEQUENCE {
  sm-EnumeratedDeliveryFailureCause    SM-EnumeratedDeliveryFailureCause,
  diagnosticInfo        SignalInfo      OPTIONAL,
  ...}

 

END

>>

 

And not with the more recent ASN1 definition.

But, as said in the previous mail, for a defined application context, you can not choose which version of the protocol you should use.

 

<<

SM-DeliveryFailureCause ::= SEQUENCE {
  sm-EnumeratedDeliveryFailureCause     SM-EnumeratedDeliveryFailureCause,
  diagnosticInfo        SignalInfo      OPTIONAL,
  extensionContainer    ExtensionContainer      OPTIONAL,
  ...}
>>

 

So, you should have:

<<

Frame 2 (98 bytes on wire, 98 bytes captured)
Message Transfer Part Level 2
Message Transfer Part Level 3
Signalling Connection Control Part
Transaction Capabilities Application Part
    end
        Destination Transaction ID
        oid: 0.0.17.773.1.1.1 (dialogue-as-id)
        dialogueResponse
            application-context-name: 0.4.0.0.1.0.25.3 (shortMsgMT_RelayContext_v3)
            result: accepted (0)
            result-source-diagnostic: dialogue-service-user (1)
        components: 1 item
GSM Mobile Application
    GSM Mobile Application Phase 2 3GPP 0902-4j1
        returnError
            invokeId: present (0)
            errcode: local (0)
            SM-DeliveryFailureCause: sm-EnumeratedDeliveryFailureCause (1)
                sm-EnumeratedDeliveryFailureCause: equipmentProtocolError (1)

>>

 

Regards

Florent

---

De : wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] De la part de Anders Broman
Envoyé : jeudi 8 janvier 2009 10:28
À : Developer support list for Wireshark
Objet : Re: [Wireshark-dev] Help on understanding Application contextinTCAPto be used by GSM MAP

Hi,

The ASN1 looks like:

SM-DeliveryFailureCause ::= SEQUENCE {

sm-EnumeratedDeliveryFailureCause SM-EnumeratedDeliveryFailureCause,

diagnosticInfo SignalInfo OPTIONAL,

extensionContainer ExtensionContainer OPTIONAL,

...}

GSM Mobile Application
    10.. .... = Class: CONTEXT (2)
    ..1. .... = P/C: Constructed Encoding
    ...0 0011 = Tag: 3
    Length: 9
    Component: returnError (3)
        returnError
            00.. .... = Class: UNIVERSAL (0)
            ..0. .... = P/C: Primitive Encoding
            ...0 0010 = Tag: INTEGER (2)
            Length: 1
            invokeID: 0
            errorCode: localValue (0)
                00.. .... = Class: UNIVERSAL (0)
                ..0. .... = P/C: Primitive Encoding
                ...0 0010 = Tag: INTEGER (2)
                Length: 1
                localValue: sm-DeliveryFailure (32)
            00.. .... = Class: UNIVERSAL (0)
            ..0. .... = P/C: Primitive Encoding
            ...0 1010 = Tag: ENUMERATED (10)
            Length: 1
            BER Error: Sequence expected but class:UNIVERSAL(0) primitive tag:10 was unexpected

0000  e8 e8 3f 83 0a 40 88 70 09 00 03 0e 18 0b 12 08   ..?..@.p........
0010  00 12 04 79 51 05 39 00 11 0a 12 08 00 12 04 79   ...yQ.9........y
0020  54 85 99 04 3d 64 3b 49 04 b5 07 f1 5a 6b 26 28   T...=d;I....Zk&(
0030  24 06 07 00 11 86 05 01 01 01 a0 19 61 17 a1 09   $...........a...
0040  06 07 04 00 00 01 00 19 03 a2 03 02 01 00 a3 05   ................
0050  a1 03 02 01 00 6c 0b a3 09 02 01 00 02 01 20 0a   .....l........ .
0060  01 01                                             ..

Shouldn't there be SEQUENCE before the ENUMERATED tag?

Regards

Anders

---

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of DROUIN FLORENT
Sent: den 7 januari 2009 18:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Help on understanding Application context inTCAPto be used by GSM MAP

    Hello,

 

Wireshark manage only one version of the GSM MAP, this version is defined within the ASN files in the gsm map sources.

In the current application, one of the latest GSM MAP ASN definition is used, and additional messages related to previous version have been included.

This means, for a given application context, only one version of the MAP protocol is implemented.

So, you can not ask to decode a message with 3GPP TS 29.002 :v5.10.0 or 3GPP TS 29.002 :v6.8.0.

 

For your second question, you can have several equipment (so different Point Code) using the same TCAP transaction ID, so if you don't check the PC, you will mix several session.

 

For frame 2, I need to check with the ASN1 definition of the message to know if this is a bad decoding.

 

Regards

Florent

---

De : wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] De la part de tulip neo
Envoyé : mercredi 7 janvier 2009 15:31
À : wireshark-dev@xxxxxxxxxxxxx
Objet : [Wireshark-dev] Help on understanding Application context in TCAPto be used by GSM MAP

Hi List,
Good Evening.
I have a problem with  GSM MAP Decoding.So according to the  implimentaion map
rel version should be determined dynamically based on application context.
I undesrstand it this way.Application conext is used if its recieved by traffic.
if its recived and the call alreday exist than we may fall back with mismatch.
My question is How do i know which version of GSM map wireshark uses
internally for a specific message.(Well need to debug is there any other way).
There seem to be no version checking except some checking with application context value 1,2
and 3.Wireshark checks only application_context_version ==3 nd in some cases
<3 .I m intrested to know is it only handled this way or some other way out.
I Know that the following version release are possible in case of GSM MAP.

GSM 09.02 Ph 1 :v3.11.0
GSM 09.02 Ph 2 :v4.19.1
3GPP TS 29.002 :v3.12.0
3GPP TS 29.002 :v4.13.0
3GPP TS 29.002 :v5.7.0
3GPP TS 29.002 :v5.10.0
3GPP TS 29.002 :v6.8.0
3GPP TS 29.002 :v6.14.0
3GPP TS 29.002 :v7.8.0

Which version wireshark currently supports.
I see only the following from sources:
ETSI TS 129 002
ETSI TS 129 002 V7.5.0 (3GPP TS 29.002 V7.5.0 (2006-09) Release 7)
ETSI TS 129 002 V8.4.0 (3GPP TS 29.002 V8.1.0 (2007-06) Release 8)
3GPP TS 24.080

secondly i saw from sources that it is using MTP3 PC to match a call.I understand
it this way when we have a message,we check for OID(Source/destnination).continue
can have both while begin has source and abort/end have destination.so comparing
previously recived message with recently recived message we can find the matching
call but i m wondering why MTP3 PC is used.

I have attached a smaple trace where frame 1 and 3 belong to same transaction.
frame 1 is begin and frame 3 is end.begin message at frame 1 source transaction
id C746F173 is same as end messae at frame 3(dest trans id C746F173).both have
application-context-name: 0.4.0.0.1.0.24.2 (mwdMngtContext-v2).
so in this case v2 is used.if with end message there would not have been any
application-context-name than it would have used begin's Application context name.
on the other hand in frame 2 it gives some decoding error.is it the case that wireshark
has a bug or some thing else.

Any help/pointer on this would help me really to understand the transaction management in TCAP.

Br
tulip

 

---

Add more friends to your messenger and enjoy! Invite 
them now.