Henri, I agree with you that H.225 is in error. The extension bit should be set according to encoding rules in Q.931. In adding the support for octet 3a I neglected to change the text for "Octet No. 3 Extension". This correction should be a candidate for the implementor's guide. The indicators in the ASN.1 were meant to cover the cases where the address is not a telephone number that could go into a calling party number IE (or connected party IE), for example any address of type AliasAddress. Glen henri.maenpaa@NOKIA.COM wrote:

All,

First, there seems to be some inconsistency about the use of 3a octet of Q931 CallingPartyNumber field in H.225.0. Hopefully this is just an editorial mistake.

Q931 (05/98) states the following (chapter 4.5.1 Coding Rules): c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit. The bit value "0" indicates that the octet continues through the next octet. The bit value "1" indicates that this octet is the last octet. If one octet (Nb) is present, also the preceding octets (N and Na) must be present.

Whereas H.225.0v3 (09/99) seems to do the opposite in Calling Party Number field by telling to set the octet 3 extension bit to 1, and use octet 3a as "encoded following the values and rules of table 4-9/Q931."

Second, I am also wondering why H.225.0 currently allows two methods for CLIP/CLIR indication: Octet 3a and the ASN.1 side presentationIndicator IE. OK, the standard states strictly that octet 3a overrides the other, and therefore there should not be insolvable conflicts at the receiving entity, but still why they were both included?

-Henri Mäenpää, Nokia

-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA