Frank,

The way I understand it, the redundant ABNF/BER encoding scheme was a compromise between the text and binary people. I don't know about H.323 Annex L, but in H.248, MGCs must support both encodings, but MGs only have to support one. As it happens, very few MGs support BER. I believe it's too late now to specify PER instead of or in addition to BER.

I agree with your observation concerning BER, though. I asked the same question awhile back among the Megaco crowd. The answer I got was simply, "Some people wanted a binary encoding, and the H.323 folks said to use BER because PER is too hard." That's it. I thought the H.323 folks had long since recovered from the mind-numbing complexity of ASN.1 PER ;-), and that this was now a non-issue with them. Moreover, it was mentioned long ago on the ASN.1 reflector (by Bancroft Scott, I believe) that BER was really a bad choice nowadays and that if one was considering BER, one should always use DER instead. Go figure.

Paul Long ipDialog, Inc.

-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Frank Derks Sent: Thursday, May 10, 2001 8:08 AM To: ITU-SG16@mailbag.cps.INTEL.COM Subject: Encoding of H.248 in H.323

H.248 specifies both a binary (using the BER) and a text format for the encoding of its messages. 7.2.2.28/H.225.0 states that either of these formats can be used for H.323 Annex L.

Are there reasons, other than the fact that the BER and text are specified in H.248, to dissallow encoding using the PER? It would seem that having to use two different encoding schemes (PER+BER or PER+text) makes things unnecessarily complex.

Regards,

Frank

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com