Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Decoding H.225.0 nonStandard data component

Hi there,

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:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xa/122xa_2/pulh323.htm#1019732

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?

cheers,

Matthew.

2 REPLIES

Re: Decoding H.225.0 nonStandard data component

Hello, Matthew.

Try Capture this flow with Ethereal, and then

press follow tcp stream.

Vary often nonstandart fields transported via GTD.

Ethereal understand this.

WBR

Konstantin

New Member

Re: Decoding H.225.0 nonStandard data component

Hi there Konstantin,

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.

thanks,

Matthew.

214
Views
0
Helpful
2
Replies