we are currently trying to decode an H.225.0 Setup message. In the extended part of the H323PDU, there is a parameter nonStandardData, which has a further sub-parameter called Data. It is encoded as an octet string and Cisco says it is encoded based on the following reference:
in the section "Tunneling of Redirecting Number Information Element". It refers to a tunneled QSIG message. We are struggling to decode all of the message, which is required as we need to original calling number and redirecting number. We can see both these numbers and decode most of the message, but not the part at the beginning. Without knowing the format at the beginning the mesage could change and the parsing will become faulty. Here is the relevant part of the message:
01 40 b5 00 00 12 81 49 f0 01 01 00 01 a1 81 29
a1 04 03 90 90 a3 18 03 a1 83 81 1e 02 82 81 29
05 04 01 1f 0b 1a 34 01 40 6c 0a 21 83 34 34 38
31 32 37 38 39 70 04 80 32 39 37 74 0b 21 00 81
34 34 38 31 31 39 38 30 74 0b 21 00 80 34 34 38
31 31 39 38 30 1c e2 9e 01
The 17th octet is the bearer capability, followed by the length, followed by the BC encoding '90 90 a3'. Several other Q.931 information elements follow, however we are interested in the first part, after
the "b5 00 00 12",which is the H221NonStandard sequence encoding (t35countrycode, t35extension, etc). So starting with 81 49 f0, we believe that the nonStandardParameter data part has a length encoding (as it is type OCTET STRING), followed by the encoding, so 81 49 = 329 octets, leaving out the first bit. What we don't know how to decode is the remaining 9 octets: f0 01 ....... 29 a1. We think it may be to do with QSIG, or a tunneled message but we've checked the QSIG standard (ECMA-143) and nothing appears to help. We've even check QPKT but that doesn't help either.Can anyone help?
thankyou for your suggestion. We captured the message with Ethereal. I tried "follow tcp stream" but it did not decode the nonStandardData. The second part of the nonStandardData is GTD, but the first part is not - the part we have shown above.
I saw in the TCP handshake that our Cisco GW's MSS is set to 240 bytes. I have been experimenting on the GW to change this but so far have not been succesful. I think (possibly) Ethereal may not be able to decode as the message is split over two segments. We have found an option in Ethereal to decode if the message is split over two segments, but activating this does not appear to do anything.
I will continue to change the MSS, but do you have any other suggestions (with Ethereal or other)? Alternatively, I can forward the Ethereal file to you.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...