This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

ISUP IAM Malformed?

0

Can someone please take a look at this IAM decode and give me your opinion if it is correct or malformed please?

What I am suspecting to be incorrect is the optional fields, specifically the Generic Name. When this call leaves the originating MSS it is leaving with calling, called and jip but it arrives with calling, called, AN II, Carrier ID and Generic Name... This is failing and any help I can get is greatly appreciated.

ISDN User Part
    CIC: 430
    Message type: Initial address (1)
    Nature of Connection Indicators: 0x0
        Mandatory Parameter: Nature of connection indicators (6)
        .... ..00 = Satellite Indicator: No Satellite circuit in connection (0x00)
        .... 00.. = Continuity Check Indicator: Continuity check not required (0x00)
        ...0 .... = Echo Control Device Indicator: Echo control device not included
    Forward Call Indicators: 0x6010
        Mandatory Parameter: Forward call indicators (7)
        .... ...0 .... .... = National/international call indicator: Call to be treated as national call
        .... .00. .... .... = End-to-end method indicator: No End-to-end method available (only link-by-link method available) (0x0000)
        .... 0... .... .... = Interworking indicator: no interworking encountered (No.7 signalling all the way)
        ...0 .... .... .... = End-to-end information indicator: no end-to-end information available
        ..1. .... .... .... = ISDN user part indicator: ISDN user part used all the way
        01.. .... .... .... = ISDN user part preference indicator: ISDN user part not required all the way (0x0001)
        .... .... .... ...0 = ISDN access indicator: originating access non-ISDN
        .... .... .... .00. = SCCP method indicator: No indication (0x0000)
        .... .... ...1 .... = Ported number translation indicator: number translated
        .... .... ..0. .... = Query on Release attempt indicator: no QoR routing attempt in progress
    Calling Party's category: 0xa (ordinary calling subscriber)
        Mandatory Parameter: Calling party's category (9)
        Calling Party's category: ordinary calling subscriber (0x0a)
    User service information, (3 bytes length)
        Mandatory Parameter: User service information (29)
        Pointer to Parameter: 3
        Parameter Length: 3
        User service information (-> Q.931 Bearer_capability): 9090a2
        1... .... = Extension indicator: last octet
        .00. .... = Coding standard: ITU-T standardized coding (0x00)
        ...1 0000 = Information transfer capability: 3.1 kHz audio (0x10)
        1... .... = Extension indicator: last octet
        .00. .... = Transfer mode: Circuit mode (0x00)
        ...1 0000 = Information transfer rate: 64 kbit/s (0x10)
        1... .... = Extension indicator: last octet
        .01. .... = Layer identification: Layer 1 identifier (0x01)
        ...0 0010 = User information layer 1 protocol: Recommendation G.711 u-law (0x02)
    Called Party Number: 2175041116
        Mandatory Parameter: Called party number (4)
        Pointer to Parameter: 6
        Parameter Length: 7
        0... .... = Odd/even indicator: even number of address signals
        .000 0011 = Nature of address indicator: national (significant) number (3)
        0... .... = INN indicator: routing to internal network number allowed 
        .001 .... = Numbering plan indicator: ISDN (Telephony) numbering plan (1)
        Called Party Number: 2175041116
            .... 0010 = Address signal digit: 2 (2)
            0001 .... = Address signal digit: 1 (1)
            .... 0111 = Address signal digit: 7 (7)
            0101 .... = Address signal digit: 5 (5)
            .... 0000 = Address signal digit: 0 (0)
            0100 .... = Address signal digit: 4 (4)
            .... 0001 = Address signal digit: 1 (1)
            0001 .... = Address signal digit: 1 (1)
            .... 0001 = Address signal digit: 1 (1)
            0110 .... = Address signal digit: 6 (6)
            E.164 Called party number digits: 2175041116
    Pointer to start of optional part: 13
    Calling Party Number: 2174972872
        Optional Parameter: Calling party number (10)
        Parameter Length: 7
        0... .... = Odd/even indicator: even number of address signals
        .000 0011 = Nature of address indicator: national (significant) number (3)
        0... .... = NI indicator: complete
        .001 .... = Numbering plan indicator: ISDN (Telephony) numbering plan (1)
        .... 00.. = Address presentation restricted indicator: presentation allowed (0)
        .... ..11 = Screening indicator: network provided (3)
        Calling Party Number: 2174972872
            .... 0010 = Address signal digit: 2 (2)
            0001 .... = Address signal digit: 1 (1)
            .... 0111 = Address signal digit: 7 (7)
            0100 .... = Address signal digit: 4 (4)
            .... 1001 = Address signal digit: 9 (9)
            0111 .... = Address signal digit: 7 (7)
            .... 0010 = Address signal digit: 2 (2)
            1000 .... = Address signal digit: 8 (8)
            .... 0111 = Address signal digit: 7 (7)
            0010 .... = Address signal digit: 2 (2)
            E.164 Calling party number digits: 2174972872
    Originating line info: 0 (ANI II if < 51, reserved otherwise)
        Optional Parameter: Originating line information (234)
        Parameter Length: 1
        Originating line info: 0
    Parameter Type unknown/reserved (3 Bytes)
        Optional Parameter: Carrier identification (197)
        Parameter Length: 3
    Generic name: 
        Optional Parameter: Generic name (199)
        Parameter Length: 1
        .... ..00 = Presentation indicator: presentation allowed (0)
        ...0 .... = Availability indicator: name available/unknown
        001. .... = Type indicator: calling name (1)
        Generic Name: 
    End of optional parameters (0)

asked 22 Jul '16, 13:08

Michael%20Pierotti's gravatar image

Michael Pier...
6335
accept rate: 0%

edited 22 Jul '16, 14:29

Jaap's gravatar image

Jaap ♦
11.7k16101

Without seeing the original message bytes it is hard to tell whether the message has actually been malformed in transit or whether the Wireshark dissector has just chosen to interpret the i.e. "name" value as Originating Line Info Parameter instead of Jurisdiction Identification Parameter (causing the other bytes of the JIP to be misinterpreted). So can you please post the hex dump of the complete message? To do so, you have to choose the message in the packet list, right-click the first line (Frame n: ...), choose Copy -> ...as Hex Dump from the drop-down menu, and paste the result into the text of your Question after clicking "edit" below the Question? Then, click open the Frame subtree and state the Encapsulation type: value (such as Ethernet (1)).

For a single message this may be less annoying than exporting a single message into a new capture file, uploading that file to a login-free file sharing service, and editing the Question with a link to it. But you may think otherwise, so feel free to do it this way. Cloudshark would be the best place for the file in such case.

As I'm not based in the North American region, I'd also like to have the i.e. "names" (codes identifying the information element) specified for JIP and OLIP in the Telcordia GR-317-CORE.

If you cannot find these codes either, please state at least the expected JIP contents (which should be a 6-character ASCII string or 6 digits encoded into three bytes according to different sources).

Another question is where you have taken the capture. Is there any ISUP-aware equipment (like another voice exchange or an STP) between the originating MSS and the capturing point, or is it just transport equipment which is not supposed to tamper with the message contents?

(23 Jul '16, 04:00) sindy

Just an afterthought, the ISUP dissector, like some others, does not show in the dissection pane the contents of parameters it does not know. So the lines

Parameter Type unknown/reserved (3 Bytes)
    Optional Parameter: Carrier identification (197)
    Parameter Length: 3

in your dissection may actually represent a non-dissected JIP. The variant setting in Wireshark's ISUP preferences does not offer ANSI ISUP (at least in 2.0.4), so the 197 which represents Carrier identification in the ITU variant may represent the ANSI-specific JIP, and that would explain the whole mystery.

If you left-click at the first line (Parameter Type unknown/reserved (3 Bytes)), you should see five bytes highlighted in the lower, "packet bytes" pane. The first two should be c5 03, the remaining three would be the JIP value in 6 BCD format (4 bits/digit), probably with swapped order of digits - in ISUP and SS7 in general, the lower nibble has to be read first. So bytes 32 54 76 would represent a JIP value of 234-567.

(23 Jul '16, 05:25) sindy

And an afterthought No. 2: thanks to Dialogic's WebHelp, I've discovered that the JIP parameter code is 196, not 197, and that Wireshark's ISUP dissector can recognize it properly. So it decodes a c4 03 32 54 76 byte sequence like this:

Jurisdiction: 234567
    Optional Parameter: Jurisdiction (196)
    Parameter Length: 3
    Jurisdiction: 234567
        .... 0010 = Address signal digit: 2 (2)
        0011 .... = Address signal digit: 3 (3)
        .... 0100 = Address signal digit: 4 (4)
        0101 .... = Address signal digit: 5 (5)
        .... 0110 = Address signal digit: 6 (6)
        0111 .... = Address signal digit: 7 (7)

Now it is up to you to check whether the mistake is at the sending MSS side or somewhere else (I assume that guys at Dialogic would not publish rubbish).

(23 Jul '16, 06:05) sindy

000000 00 0c 00 04 6d 33 75 61 00 14 00 04 c0 a8 7d 44 000010 00 15 00 04 c0 a8 7b 24 00 18 00 04 00 00 00 01 000020 00 19 00 04 00 00 6e 29 00 1a 00 04 00 00 0b 5a 000030 00 1e 00 04 00 00 4d 81 00 00 00 00 01 00 01 01 000040 00 00 00 4c 02 00 00 08 00 00 00 08 02 10 00 3b 000050 00 fa 84 01 00 05 5c 2e 05 02 00 0b 92 01 01 00 000060 60 10 0a 03 06 0d 03 90 90 a2 07 03 10 12 57 40 000070 01 86 0a 07 03 13 12 47 79 82 27 ea 01 00 c5 03 000080 22 40 23 c7 01 20 00 00

Encapsulation type: Wireshark upper PDU export

(25 Jul '16, 06:23) Michael Pier...
(25 Jul '16, 06:43) Michael Pier...

Yes, this worked, asking nothing at all :-)

(25 Jul '16, 06:46) sindy

Ohhh forgot about this. This is a snip from the outgoing MSS. They sent me a word doc text decode and not the hex, but you can see if is going out C4 (196)

139       | 1100 0100 | Jurisdiction Information Identifier: c4                                 
140       | 0000 0011 |   Length: 3 octet(s)                                                    
141       | 0001 0010 |   Address Signal: 217497                                                
142       | 0100 0111 |   Address Signal:                                                       
143       | 0111 1001 |   Address Signal:                                                       
144       | 0000 0000 | End of Optional Parameters: 0                                           
          |           | IETF.M3UA                                                               
145       | 0000 0000 |   Padding: 0000(hex)                                                    
146       | 0000 0000 |   Padding:
(25 Jul '16, 06:47) Michael Pier...

OK, so if the Jurisdiction ID is actually 220432, then some equipment along the path malforms the parameter name from c4 to c5 and that's it.

As c5 is not a standardized name of any ISUP parameter (well, at least according to the friend at Dialogic, maybe something in GR-317-CORE has changed since they've published that list?), I would suspect the last exchange in the chain to be guilty, as a non-standard parameter should normally be accompanied by a PCI parameter so if it has been malformed by some machine mid-stream, the sender of the IAM should have got at least an upstream CFN by the first recipient of the malformed version.

(25 Jul '16, 06:55) sindy

Actually I think we may already know who the culprit is, as this wouldn't be the first time they have screwed up something for us. Last time it was they were not sending the GAP for a LNP

(25 Jul '16, 06:57) Michael Pier...

We were writing against each other (simultaneously) :-)

I assume the text from the originator is from another call? Because your IAM at CIC 402 says 220432 (as c5), while their text says 217497... If it is the same call, the evil ghost does much more damage.

(25 Jul '16, 07:00) sindy

I will know better here shortly as I have some end to end testing scheduled.

(25 Jul '16, 07:01) Michael Pier...

Just added a new file. Outgoing_IAM.txt where you can see the outgoing JIP is 217304, and a wireshark cap where there is no JIP that I can find.

(25 Jul '16, 10:02) Michael Pier...

Weird enough, I can see only iam_issue.pcapng (plus the original isup_cap.pcapng) in the Google drive directory, but no text file.

But that's not important, I guess you are sure enough that the four IAMs which have arrived are reincarnations of the one the calling MSS has sent.

And as there is a JIP in the source IAM, with a value of 217304, and what arrives through the jungle is an IAM with a c5 parameter of same length but different contents (220432 in all 4 IAMs in your capture), you may be sure that "something" in the chain affects the IAM contents.

As you get this c5 03 22 40 23 in all 4 IAMs, one more question - was there just a single call attempt at the calling side? If yes, I'd expect that

  • either the c5 03 22 40 23 has been put to the IAM before the exchanges which attempted to deliver the IAM to you using several distinct routes,

  • or it has been put there between the point where these routes join again and the place where you capture.

As nothing has survived from the original value, we cannot exclude that one exchange has erased the JIP and another one has inserted the c5 03 22 40 23.

As for the 199 (0xc7), I could imagine some exchanges to insert an empty Generic Name parameter to an egress IAM if none was available at ingress. Same case for the empty Originating Line Information.

Are you sure that the whole call path passes through North American operators?

(25 Jul '16, 10:26) sindy

Yes this is a single call. Because our MSS doesn't like this IAM it is not sending an ACM so the Tandem tries it on a different CIC. And yes it is a call originating in US and terminating in US. I filtered on a few other calls for the Generic Name parameter and I do see calls which are successful IF the Generic Name actually has something included.

(25 Jul '16, 10:36) Michael Pier...

I uploaded generic_name.pcapng where there is actually information in there.

(25 Jul '16, 10:39) Michael Pier...

Wow... in the Dialogic document in which you've found the 199, there is also 197 = 0xc5, called "Carrier Identification". So maybe it has been added to the specification since the Dialogic document I was referring to was published? In any case, the Wireshark dissector does not like something about its contents (because it states the proper name and because the size of the parameter value is correct, 3 octets), or there is a bug in the dissector. Can you check T1.113 Section 3.8A to find out whether the 22 40 23 is a legal contents of this parameter? If it is, it would be best to file a bug at Wireshark bugzilla, attaching the full relevant description from T1.113.

But in any case, as the Carrier Identification legally exists, I would dare to conclude that its addition to the IAM and the disappearance of the JIP from it are not related to each other.

As for the call path, I understand that the origin and destination are in the US, I was asking whether you can be sure it doesn't run via e.g. LatAm which uses the ETSI ISUP flavors, so the JIP may not be supported there.

Does your receiving switch complain about something about the IAM to its logs, if any?

(25 Jul '16, 10:53) sindy

3.20C Generic Name Parameter
The format of the generic name parameter field shall be as shown in Figure 18C/T1.113.3.
The following codes are used in the subfields of the generic name parameter field:

(1) Presentation (Pres.)
0 0 presentation allowed
0 1 presentation restricted
1 0 blocking toggle
1 1 no indication
(2) Availability (Avail.)
0 name available/unknown
1 name not available
(3) Type of name
0 0 0 spare
0 0 1 calling name
0 1 0 original called name
0 1 1 redirecting name
1 0 0 connected name
1 0 1 }
   to } spare
1 1 1 }

Up to 15 characters of name information are coded in IA5 format.

(25 Jul '16, 12:30) Michael Pier...

That didn't paste right so I added some new text files to that shared folder.

(25 Jul '16, 12:38) Michael Pier...

Seems we are slightly mistuned :-)

  • I wanted a description of the Carrier Identfication parameter (197 = 0xc5), but in the meantime I've discovered that T1.113 can be downloaded from the 3GPP archive. Using the description from there, I conclude that the Carrier Identifier data in your IAMs have a proper contents, so there is a bug in Wireshark dissector which can be filed.

  • you have instead provided a description of Generic Name (199 = 0xc7) which Wireshark dissects properly; as the whole parameter wasn't available in the original IAM, it seems fine to me that one of the exchanges along the path has added that parameter with zero size and "presentation alowed, name available or unknown, calling name" properties.

Off topic: once you are through with this issue, please have a look at the formatting possibilities of this site. They can be used not only for Questions and Answers but also for Comments. Hint: use the form field intended for writing an Answer so that you would see the result in the preview, then cut the text from there and paste it to the form field which opens after you press the Comment button.

(25 Jul '16, 12:55) sindy
showing 5 of 20 show 15 more comments

One Answer:

0

So to wrap the chain of comments up into a proper Answer to the original Question:

(1) from the protocol point of view, the IAM in the example is not malformed - all parameters it contains are properly formatted, although their values may be unusual.

(2) from the service point of view, the contents of the IAM has changed in transit to an extent which may cause interworking or even legal issues, although from the protocol point of view alone, all the affected parameters are optional:

  • some parameters from the original IAM have been lost in transit (in particular, the Jurisdiction Information),

  • others have been added (the Generic Name, the Carrier Identification),

  • the contents of some others has changed in transit (the Originating Line Info which was 63 at the source but 00 at the point of capture).

(3) from Wireshark point of view, the ISUP dissector doesn't handle the Carrier Identification parameter properly. An enhancement bug has been filed on that.

answered 27 Jul '16, 05:43

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 27 Jul '16, 05:45

Sorry it took me so long to get back on this. Yes I would say that you are accurate and I appreciate the assistance. On a side note the issue was resolved by a LEC routing change

(28 Jul '16, 08:12) Michael Pier...