February 2001 - sg16-avd - lists.packetizer.com

Usage Information Reporting in H.323 V4
by Paul, Manoj 07 Feb '01

07 Feb '01

Hi All, This is with reference to Section 7.2.7 in H.323 V4 Specification on Usage Information Reporting. I will appreciate if someone could clarify a couple of things here. 1) RasUsageSpecification (as returned by Gk to Gw) specifies what should a Gw return in RasUsageInformation. Gk defines the callStartingPoint as alerting/connect in callStartingPoint Sequence in RasUsageSpecification. This is an OPTIONAL sequence. Is there any default call starting point that Gw must assume if Gk does not fill callStartingPoint sequence and still wants startTime reporting (as indicated by filling startTime in RasUsageInfoTypes field in RasUsageSpecification). 2) When field in RasUsgageSpecification indicates to the Gw the time when it should send RasUsageInformation to Gk. One of the options is "start" of the call. What point of time in a call sequence does the "start" refer to. If it is reception/sending of Setup, there would be invalid timestamps in alertingTime and connectTime in RasUsageInformation. 3) One of the options in When field in RasUsageSpecification is inIrr. This instructs the Gw to send RasUsageInformation in solicited/unsolicited IRRs. Again if multiple IRRs get sent during the duration of the call, what additional information is Gw providing to Gk in terms of RasUsageInformation? I will appreciate any pointers for the above. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
by Paul, Manoj 06 Feb '01

06 Feb '01

Bancroft: Does your input to ITU-T ASN.1 Meeting defines outermost value as value of a type that is either directly nested in an open type or is a complete application message unto itself. Or does your input refers outermost value only to the value of the open type IE and not the IEs nested within it? We would appreciate if you could provide us with this information as the clarifications to above in ASN.1 meetings would only happen in due time. Thanks Manoj. On Fri, 2 Feb 2001, Paul E. Jones wrote: > Manoj, > > Given Bancroft's role in the development of ASN.1, I'd say that whatever he > says is probably true and most likely the intent if the text is not clear. I have inputted this to the ASN.1 meeting that was held at the ITU-T in Geneva January 22 - February 2, and this will be clarified in an upcoming corrigendum. > In any case, I would venture to guess that OSS is more widely used than any > other ASN.1 PER encoder/decoder on the market. While it may not be > appropriate to call their tools the "de facto" standard, they very much are > (no disrespect intended to anyone). I would suggest that the text be > clarified according to Bancroft's recommendation and that Implementers > follow his advise, as I believe it would result in the widest possible > interoperability. I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC ASN.1 Rapporteur, John Larmouth, in case they have anything to add. Bancroft ______________________________________________________ > > ----- Original Message ----- > From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Thursday, February 01, 2001 3:34 PM > Subject: Re: Interoperability Problems due to Open Type encoding of Null t > ypes (fwd) > > > > Hi All, > > > > I am resending this mail as there does not seem to be a consensus on > > the defintion of "outermost" value as defined in X.691 specification. > > Any additional information which would help solve this issue is > > appreciated. It will help to mitigate one of the important issues > > affecting the interoperability across H.323 implementations. > > thanks > > Manoj. > > > > -----Original Message----- > > From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] > > Sent: Friday, January 19, 2001 10:21 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Interoperability Problems due to Open Type encoding of Null > > t ypes (fwd) > > > > > > Hi Scott, > > > > We agree to your interpretation for case (1). However, for case (2) > > we believe that only Foo SEQUENCE should be considered the outermost > > value. And since it would not generate an empty bit string, no additional > > 0x00 octet should be added to the field-list. Why should v (NULL element) > > also considered as outermost value in this context since it appears > > within the extension root of Foo, isn't it? > > -Manoj > > > > -----Original Message----- > > From: Bancroft Scott [mailto:baos@OSS.COM] > > Sent: Wednesday, January 17, 2001 8:58 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Interoperability Problems due to Open Type encoding of Null > > types (fwd) > > > > > > On Wed, 17 Jan 2001, Manoj Paul wrote: > > > > > Experts, > > > > > > We have come across a specific problem which has been the root > > > cause of interoperability failures across different implementations > > > of H.323 stack. The problem is related to the > > > 1) Encoding and decoding of NULL data types when they appear as > > > extension IEs. > > > 2) Encoding and decoding of extension IEs which have NULL as the > > > outermost ASN type. > > > > > > There have been different interpretations of the PER rules that apply > > > to the above conditions causing interop failures at encode/decode level. > > > Although the implementations would encode/decode (1) and (2) according > > > to Open Type elements, some subtle differences come as mentioned below: > > > > > > In case of (1), some implementations would not encode an extra 0x00 > > > octet for NULL data type and would just encode the length of the open > type > > > element as 0x00. This idea probably stems from the fact that a NULL > > > data type has no encoding when they appear in the root of the ASN.1 > type. > > > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for > > > such a case would be 0x01 0x00, where 0x01 is the uncosntrained length > > > of the NULL data type encoding and 0x00 is the value of NULL data type > in > > > extension. > > > > Your understanding of the encoding is correct. > > > > > In case of (2), some implementations would encode the extension IE as > per > > > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for > > > the outermost NULL data type in it's encode tree. This would change the > > > value of length field to be appended to this open type. Whereas some > > > implementations do add 0x00 octet for the outermost NULL data type. > > > > > > There appears to be a confusion as to what is meant by the "outermost" > > > value in 10.1.3 of X.691. I would appreciate clarification on this > > > clause as it would save a lot of interop overhead at encode/decode > level. > > > > "outermost" value refers to a value of a type that is either directly > > nested in an open type or is a complete application message unto itself. > > For example, if you had: > > > > Foo ::= SEQUENCE { > > b BOOLEAN, > > v TYPE-IDENTIFIER.&Type, > > ..., > > i NULL > > } > > > > bar Foo ::= {b TRUE, v NULL : NULL, i NULL} > > > > The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) > > is encoded as an outermost value, so in this case since NULL encodes to 0 > > bits it is replaced with eight 0-bits, and this is prefixed with a length > > of 1. Similarly, the value of i is encoded as an outermost value, so the > > resulting encoding in this case will have a length of 1 followed by eight > > 0-bits. > > > > ------------------------------------------------------------------------- > > Bancroft Scott Toll Free :1-888-OSS-ASN1 > > OSS Nokalva International:1-732-302-0750 > > baos(a)oss.com Tech Support :1-732-302-9669 > > x-1 > > 1-732-302-9669 x-200 Fax :1-732-302-0023 > > http://www.oss.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Annex I
by Baese Gero 06 Feb '01

06 Feb '01

Dear Mr. Li, experts, it is quite discouraging that our questions remaining unanswered and the positive signs we were sending are ignored still. We repeated our technical concerns for the UCLA proposal several times. Please be so kind to let everybody know what is needed to implement the proposal. So far provided documents are not sufficient. The simulation scenario document exists for three months now. We were asking you several times to raise your objections for the provided simulation conditions. We were incorporating your favorite test values in the document. What are the reasons to defer the start of the tests still ? The next meeting is approaching and results are needed as basis for the decision. For both of us it would be harmful to fight for details in front of the group again. We are soliciting you to co-operate - it is of mutual interest and the best for the standard. Best Wishes Gero Bäse ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
by Paul, Manoj 04 Feb '01

04 Feb '01

Hi All, I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj. -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd) Hi Scott, We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj -----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd) On Wed, 17 Jan 2001, Manoj Paul wrote: > Experts, > > We have come across a specific problem which has been the root > cause of interoperability failures across different implementations > of H.323 stack. The problem is related to the > 1) Encoding and decoding of NULL data types when they appear as > extension IEs. > 2) Encoding and decoding of extension IEs which have NULL as the > outermost ASN type. > > There have been different interpretations of the PER rules that apply > to the above conditions causing interop failures at encode/decode level. > Although the implementations would encode/decode (1) and (2) according > to Open Type elements, some subtle differences come as mentioned below: > > In case of (1), some implementations would not encode an extra 0x00 > octet for NULL data type and would just encode the length of the open type > element as 0x00. This idea probably stems from the fact that a NULL > data type has no encoding when they appear in the root of the ASN.1 type. > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for > such a case would be 0x01 0x00, where 0x01 is the uncosntrained length > of the NULL data type encoding and 0x00 is the value of NULL data type in > extension. Your understanding of the encoding is correct. > In case of (2), some implementations would encode the extension IE as per > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for > the outermost NULL data type in it's encode tree. This would change the > value of length field to be appended to this open type. Whereas some > implementations do add 0x00 octet for the outermost NULL data type. > > There appears to be a confusion as to what is meant by the "outermost" > value in 10.1.3 of X.691. I would appreciate clarification on this > clause as it would save a lot of interop overhead at encode/decode level. "outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had: Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL} The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits. ------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos(a)oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

5 4

Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
by Paul, Manoj 02 Feb '01

02 Feb '01

Bancroft: Does your input to ITU-T ASN.1 Meeting defines outermost value as value of a type that is either directly nested in an open type or is a complete application message unto itself. Or does your input refers outermost value only to the value of the open type IE and not the IEs nested within it? Thanks Manoj. On Fri, 2 Feb 2001, Paul E. Jones wrote: > Manoj, > > Given Bancroft's role in the development of ASN.1, I'd say that whatever he > says is probably true and most likely the intent if the text is not clear. I have inputted this to the ASN.1 meeting that was held at the ITU-T in Geneva January 22 - February 2, and this will be clarified in an upcoming corrigendum. > In any case, I would venture to guess that OSS is more widely used than any > other ASN.1 PER encoder/decoder on the market. While it may not be > appropriate to call their tools the "de facto" standard, they very much are > (no disrespect intended to anyone). I would suggest that the text be > clarified according to Bancroft's recommendation and that Implementers > follow his advise, as I believe it would result in the widest possible > interoperability. I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC ASN.1 Rapporteur, John Larmouth, in case they have anything to add. Bancroft ______________________________________________________ > > ----- Original Message ----- > From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Thursday, February 01, 2001 3:34 PM > Subject: Re: Interoperability Problems due to Open Type encoding of Null t > ypes (fwd) > > > > Hi All, > > > > I am resending this mail as there does not seem to be a consensus on > > the defintion of "outermost" value as defined in X.691 specification. > > Any additional information which would help solve this issue is > > appreciated. It will help to mitigate one of the important issues > > affecting the interoperability across H.323 implementations. > > thanks > > Manoj. > > > > -----Original Message----- > > From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] > > Sent: Friday, January 19, 2001 10:21 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Interoperability Problems due to Open Type encoding of Null > > t ypes (fwd) > > > > > > Hi Scott, > > > > We agree to your interpretation for case (1). However, for case (2) > > we believe that only Foo SEQUENCE should be considered the outermost > > value. And since it would not generate an empty bit string, no additional > > 0x00 octet should be added to the field-list. Why should v (NULL element) > > also considered as outermost value in this context since it appears > > within the extension root of Foo, isn't it? > > -Manoj > > > > -----Original Message----- > > From: Bancroft Scott [mailto:baos@OSS.COM] > > Sent: Wednesday, January 17, 2001 8:58 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Interoperability Problems due to Open Type encoding of Null > > types (fwd) > > > > > > On Wed, 17 Jan 2001, Manoj Paul wrote: > > > > > Experts, > > > > > > We have come across a specific problem which has been the root > > > cause of interoperability failures across different implementations > > > of H.323 stack. The problem is related to the > > > 1) Encoding and decoding of NULL data types when they appear as > > > extension IEs. > > > 2) Encoding and decoding of extension IEs which have NULL as the > > > outermost ASN type. > > > > > > There have been different interpretations of the PER rules that apply > > > to the above conditions causing interop failures at encode/decode level. > > > Although the implementations would encode/decode (1) and (2) according > > > to Open Type elements, some subtle differences come as mentioned below: > > > > > > In case of (1), some implementations would not encode an extra 0x00 > > > octet for NULL data type and would just encode the length of the open > type > > > element as 0x00. This idea probably stems from the fact that a NULL > > > data type has no encoding when they appear in the root of the ASN.1 > type. > > > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for > > > such a case would be 0x01 0x00, where 0x01 is the uncosntrained length > > > of the NULL data type encoding and 0x00 is the value of NULL data type > in > > > extension. > > > > Your understanding of the encoding is correct. > > > > > In case of (2), some implementations would encode the extension IE as > per > > > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for > > > the outermost NULL data type in it's encode tree. This would change the > > > value of length field to be appended to this open type. Whereas some > > > implementations do add 0x00 octet for the outermost NULL data type. > > > > > > There appears to be a confusion as to what is meant by the "outermost" > > > value in 10.1.3 of X.691. I would appreciate clarification on this > > > clause as it would save a lot of interop overhead at encode/decode > level. > > > > "outermost" value refers to a value of a type that is either directly > > nested in an open type or is a complete application message unto itself. > > For example, if you had: > > > > Foo ::= SEQUENCE { > > b BOOLEAN, > > v TYPE-IDENTIFIER.&Type, > > ..., > > i NULL > > } > > > > bar Foo ::= {b TRUE, v NULL : NULL, i NULL} > > > > The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) > > is encoded as an outermost value, so in this case since NULL encodes to 0 > > bits it is replaced with eight 0-bits, and this is prefixed with a length > > of 1. Similarly, the value of i is encoded as an outermost value, so the > > resulting encoding in this case will have a length of 1 followed by eight > > 0-bits. > > > > ------------------------------------------------------------------------- > > Bancroft Scott Toll Free :1-888-OSS-ASN1 > > OSS Nokalva International:1-732-302-0750 > > baos(a)oss.com Tech Support :1-732-302-9669 > > x-1 > > 1-732-302-9669 x-200 Fax :1-732-302-0023 > > http://www.oss.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ARQ/ACF/ARJ between Gatekeepers?
by Frank Derks 02 Feb '01

02 Feb '01

Dear all, since the first version of H.323, the call signalling procedures have been explained through a series of examples. Although examples do help to get the idea on how things should work, they remain examples and are therefore (usually) incomplete. Take the example from Figure2/H.323v2 (or Figure 40/H.323v4): GK1 sends the SETUP message without first initiating the admission control procedure. If GK2 expects the admission control procedure to take place prior to the call setup, then this will fail unless GK2 makes an exception for certain "EPs" (GK1 in this case) to place calls without an admission control procedure. Are there any visions on this scenario? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: ARQ/ACF/ARJ between Gatekeepers?
by Nagesh Kumar 02 Feb '01

02 Feb '01

Hi! I guess the receiving GK should have a policy to accept calls from other GKs. May be it can have a list of GKs from where it will accept calls. GK will not do ARQ/ACF while contacting the other GK as it may not know that it actaully talking to another GK or to an EP. regards, Nagesh. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Best New Trade Show Display by Opera Portables, Inc. adv
by opera＠localhost.net 02 Feb '01

02 Feb '01

1 0

Work From Home! Guaranteed monthly INCOME
by ccbat＠GTE.NET 01 Feb '01

01 Feb '01

2 1