Help parsing OLC info in H225 messages

Discussion related to the ITU-T Recommendation H.323
Post Reply
Diana
Posts: 3
Joined: Fri Nov 06, 2009 5:53 pm

Help parsing OLC info in H225 messages

Post by Diana »

In the H225 messages Setup, Connect, ... the fastStart items are parsed as a sequence of octet streams. Each of these is actually an OLC but can't seem to parse those. The few formats that I have definitions for seem easy enough to parse but I'd like definitions for all of them.
The ones I found are in the implementation notes of this http://lists.packetizer.com/pipermail/i ... chment.doc
I need to extract all addresses and ports from the OLCs.
Does anybody have a thought/suggestion?
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Help parsing OLC info in H225 messages

Post by paulej »

You are correct that they're fairly easy to parse. The options you have are to just step through the OLC with hand-written code or to use an ASN.1 encoder/decoder. Parsing it by hand is doable, but one has to be careful to watch each bit to ensure that the proper address and port fields are identified.

Personally, I'd prefer to run it through an ASN.1 decoder and then re-encode them. For most ASN.1 decoders, this is nothing more than calling a decode function, dereferencing the C structure containing the address and port and changing it, then calling encode() to re-encode it.

Obviously, one can save clock cycles by parsing the PER message by hand, but is it worth it? That's hard to say. But, if you want to understand more about the intricacies of ASN.1 PER encoding, there are folks on the board with this skill (or I'll invite them over for a discussion) and/or you could post questions to the ASN.1 mailing list: http://www.asn1.org/discuss/mailing/index.htm

Paul
Diana
Posts: 3
Joined: Fri Nov 06, 2009 5:53 pm

Re: Help parsing OLC info in H225 messages

Post by Diana »

I agree decoding/reencoding is a better way to go but I'm somewhat constrained by the tools at hand.
Regardless I did figure out a change to the h225 asn file that when compiled would generate a .c and .h file that allowed me to decode the fastStart elements:

< fastStart SEQUENCE OF OCTET STRING OPTIONAL,
---
> fastStart SEQUENCE OF TYPE-IDENTIFIER.&Type(OpenLogicalChannel) OPTIONAL,

Once I decode each element I can access/modify the fields of the element without stepping through the bytes.

Wonder why the h225 asn files still have it defined as in my original.

Oh well problem solved. Now on to the real problem at hand - setting up proper tcp/udp sockets for a fastStart call.

Thanks.
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Help parsing OLC info in H225 messages

Post by paulej »

I am sure there is a reason why it was defined that way at the beginning, but I can't say why now. Perhaps it was just to avoid importing types from H.245. Indeed, we did not import types from H.245 until H.323v3.

The change you made I suppose tricks the compiler into thinking the type is a different type, but I've never found that to be necessary with the tools I used. I would decode the message and then pass a pointer to the buffer to the decode() routine. As a parameter to the deocde() function, I could explicitly tell it that it was an OpenLogicalChannel type. All ASN.1 decoders must do that, since it must be told what kind of PDU it is decoding. I've never found it necessary to modify the ASN.1 to accomplish what you want to do.

Paul
Diana
Posts: 3
Joined: Fri Nov 06, 2009 5:53 pm

Re: Help parsing OLC info in H225 messages

Post by Diana »

Yes the change I made does apparently trick the compiler into thinking it is a different type. When I decode a message with debug printing enabled it calls it an OpenType and then I can decode that as an OpenLogicalChannel_PDU. Without that change it just considers it a sequence of octet stream but then I can't decode it because I have no way of decoding OpenLogicalChannel types. There are a very small (14) number of messages types that are defined as decodable PDUs and that is not one of them. Once it is defined as a new type my compiler also adds the ability to decode OpenLogicalChannel_PDU types.
Again, I'm constrained by the tools we currently use and have to rely on what the compiler will generate from the asn files and then subsequently what it deems as decodable types. I'm not in a position at this time to upgrade our tools although as time goes on that may become necessary.
If this does the trick for now (which it appears it will) I'll probably just got with it. BTW I found that little change to the asn somewhere in my random downloads trying to get around this issue so somebody else must have been having a similar issue. There was another change having to do with h245 tunneling that I didn't grab but may need ultimately.

Diana
Post Reply