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 Pier...
6●3●3●5
accept rate: 0%
edited 22 Jul '16, 14:29
Jaap ♦
11.7k●16●101
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: ...), chooseCopy -> ...as Hex Dumpfrom 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 theEncapsulation type:value (such asEthernet (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?
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
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 bec5 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 bytes32 54 76would represent a JIP value of234-567.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 76byte sequence like this: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).
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 00Encapsulation type:
Wireshark upper PDU exporthttps://drive.google.com/open?id=0BxQ87I-IfPX3TVRfT2dRQmVBTHc
This work ?
Yes, this worked, asking nothing at all :-)
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)
OK, so if the Jurisdiction ID is actually
220432, then some equipment along the path malforms the parameter name fromc4toc5and that's it.As
c5is 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 theIAMshould have got at least an upstreamCFNby the first recipient of the malformed version.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
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(asc5), while their text says217497... If it is the same call, the evil ghost does much more damage.I will know better here shortly as I have some end to end testing scheduled.
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.
https://www.dialogic.com/~/media/manuals/ss7/cd/GenericInfo/ProtocolDocumentation/U04SSS-ISUP-PM.pdf
Found the 199 in this
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
c5parameter 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 23in all 4 IAMs, one more question - was there just a single call attempt at the calling side? If yes, I'd expect thateither the
c5 03 22 40 23has 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?
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.
I uploaded generic_name.pcapng where there is actually information in there.
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 23is 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?
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:
Up to 15 characters of name information are coded in IA5 format.
That didn't paste right so I added some new text files to that shared folder.
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.