May 2002 - sg16-avd - lists.packetizer.com

Re: document in incoming
by OKUBO Sakae 30 May '02

30 May '02

Dear Mr. Anderson, At 13:32 -0400 02/05/30, Terry L Anderson wrote: >I have uploaded >avc-site/Incoming/2-019r1_h248IG_before_Corrigendum.zip >a TD from the 0202 meeting, that some have expressed interest in. Could >you move it to the 0202_Gen directory? Thank you. Done as requested. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Qets/16 Meeting
by Folts, Harold 26 May '02

26 May '02

Greetings, During the meeting of the SG16 WP2/16 Experts meeting in Bruges, Belgium June 24-28, 2002, Swiss Telecom will be hosting a meeting on Qest/16 on June 25 at the Scandic Hotel. Attached is the information about the hotel and reservation request form. The agenda is as follows: Opening @ 9:30 a.m. Review and approval of agenda Review of liaison responses received Coffee break at 11:00 Continue discussions Lunch h @ 12:30 Resume @ 2:00 Develop revisions to Draft Question as necessary Afternoon Break @ 3 :30 Review other issues including applicability of Metadata Game plan for future work. Adjournment @ 5:30 This is a provisional agenda and is subject to further revision and refinement Please let me know directly if you plan to attend this session. I look forward to your\r support and participation in this important endeavour. Many thanks. Best regards, Hal Folts Rapporteur, proposed Qest/16 <<Qest Res.doc>> <<Folts, Hal.vcf>>

1 0

Re: H.450.1 ASN.1 interoperability issue
by frank.derks＠PHILIPS.COM 21 May '02

21 May '02

Hi, I recall having a discussion on this topic with Ernst Horvath when this clarification text was proposed. I thoroughly checked the ASN.1 back then and based on that I must add that both Sasha and Ernst are right. Again, in the Invoke, the invokeId is encoded as a constrained integer. In the ReturnResult and ReturnError, the invokeId is encoded as "a regular" integer. I do not see any concerns for interoperability, unless it is your intention to copy the encoded invokeId from the Invoke straight to the ReturnResult/ReturnError. There is no inconsistency, between the different APDUs, there just happens to be a different specification for the invokeId in the different APDUs. This specification is identical to the one used in X.880, on which H.450.1 is based. I don't quite understand what you mean with the "two ASN.1 versions" in the "does not gel in" section of your text. Coul you clarify this? Regards, Frank Hi I just want to rewrite the same to be sure we are in sync. 6.6.1.3 of the V4 implementors guide does not CHANGE/CONTRADICT ASN.1 of H.450.1 it EXPLAINS how to encode values correctly according to ASN.1 definitions of H.450.1 And this correct encoding is: (as written in 6.6.1.3) invoke.invokeId shall be encoded as INTEGER(0..65535) returnResult.invokeId and returnError.invokeId shall be encoded as INTEGER Sasha -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.COM] Sent: Monday, May 13, 2002 8:49 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: H.450.1 ASN.1 interoperability issue Mark, there was no intention to change any ASN.1 definition in H.450.1. The note was added just to make implementers aware that the InvokeID is encoded differently in the "invoke" APDU and in the "returnResult/returnError" APDUs: in the first case it is constrained by InvokeIdSet, in the second case it is not constrained. This is not an incosistency, just a consequence of the way Packed Encoding Rules were designed. Please also note that "InvokeIdSet" is used in two different meanings: in table 4 it is the name of a parameter of the parameterized structure ROS (i.e. a placeholder), whereas in table 3 it is an "actual" value-set of integers. The brackets in the new note (InvokeIdSet = 0..65535) are not an ASN.1 definition, just an indication what the effective constraint is, namely 0..65535. Table 3 is still the (unchanged) formal definition of the actual "InvokeIdSet". Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Mark Brown [mailto:Mark.Brown@ED.ACULAB.COM] > Gesendet am: Freitag, 10. Mai 2002 17:29 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: H.450.1 ASN.1 interoperability issue > > We've been experiencing some fairly serious interoperability problems > with some systems due to confusion over what exactly the ASN.1 for > H.450.1 is and were hoping someone could clarify things for us. The > problem stems from section 6.6.1.3 of the V4 implementors guide which > adds a note below table 4: > > In the Invoke APDU, the invokeID is an INTEGER constrained by a > PER-visible constraint (InvokeIdSet = 0..65535) and is therefore > encoded as a *constrained* INTEGER (16 bits, no length field). In > the ReturnResult and ReturnError APDUs, however, the invokeID is > encoded as an *unconstrained* integer (with explicit length field) > because the applicable constraint... is not PER-visible. > > However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: > > InvokeIdSet INTEGER ::= {InvokeIds,...} > InvokeIDs ::= INTEGER (0..65535) > > which does not gel with the text in the IG and causes interoperability > issues since the two versions of the ASN.1 for InvokeIdSet are not > encoded identically. This text appears to be unchanged from the > prepublished edition on Packetizer. > > Our understanding of the text added in the IG is that the > intent was to > emphasise that the encoding of the invokeID is not consistent between > the various APDUs and that the no change to the ASN.1 was intended. > This is particularly the case since the IG doesn't modify table 3 as > would be expected if it were correcting the ASN.1 there. Others read > things differently and are using the definition of > InvokeIdSet given in > the IG. > > What is the intention here? If the intention is to redefine the ASN.1 > then some clarification as to why this was done would be very much > appreciated. >

2 1

Re: SG16, Bruges meeting, doc registration
by OKUBO Sakae 20 May '02

20 May '02

Dear Mr. Whitehead, Thank you for your registration. This is the first except for liaison statements from other SGs. At 13:11 +0100 02/05/20, martin.j.whitehead(a)bt.com wrote: >I intend to submit the latest revision of: H.248.11 Media Gateway Overload >Control Package, at the Bruges SG16 meeting 24-28 June. AVD-2195 has been allocated to your contribution. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Liaison statements from SG15
by OKUBO Sakae 18 May '02

18 May '02

Dear SG16 experts, The following four liaison statements from SG15 have been uploaded to the ftp site: using browser http://standard.pictel.com/ftp/avc-site/0206_Bru/ using ftp tool ftp://standard.pictel.com/avc-site/0206_Bru/ AVD-2191 3 Clarification on Automatic Level Control vs. Gain Control SG15 AVD-2192 2, 3 Channel multiplexing protocol for IP-CME application - G.769/Y.1242 SG15 AVD-2193 D, F, 2, 3, 4, 5 Transport of IPv6 Jumbo Frames SG15 AVD-2194 All New versions of the Access Network Transport (ANT) Standardization Plan and Work Plan SG15 Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Rec. H.501 and "GEF" parameter repository
by Horvath Ernst 16 May '02

16 May '02

Dear experts, my H.501 final draft contained a placeholder "annex B" for collecting "generic data" (i.e. standardized GEF identifier values). Upon advice by TSB, this annex will be removed in the published version 1 of H.501 since it contained no useful text. The initial idea was to include here material from H.225.0 annex G as soon as version 2 of annex G is finished. But now I have some doubts whether H.501 is the right place for such a data register. A repository of generic data should at least include also values assigned in GEF standards (H.460.x). Wouldn't the H.460 series be a better place for this? At the top level we have assigned so far: - feature ID "0" for H.225.0 Annex G profiles - feature IDs "n" for H.460.n (is this the complete list?) Each top-level feature ID opens a local name space for EnumeratedParameter-IDs specified for that specific feature. Since these are defined locally there is no danger of collisions. At least the top-level IDs should be maintained at a central place to avoid collisions, especially if such IDs can be assigned outside H.460.n standards as well (is this generally the case, or is H.225.0 annex G the only exception?). Of course such a repository could also list the locally assigned EnumeratedParameter-IDs for each registered feature, to provide a quick reference. So the question is, do people see the need for a generic-data register, and if yes, in which form? H.460.x? Or in an IG? H.501 does not seem to be the proper place. Regards, Ernst Horvath Siemens AG

4 3

Re: Rec. H.501 and "GEF" parameter repository
by Campos, Simao 16 May '02

16 May '02

Paul/Ernst: Two questions for my clarification: - How frequently would such contents be updated? - Is the intent for such material to be normative or informative? Simao -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: jeudi, 16. mai 2002 05:52 To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Rec. H.501 and "GEF" parameter repository Ernst, I do agree that we need a single place to list these. In the past, the thinking was to list such things in the Implementers Guide, but I'm more inclined to argue that H.460.1, perhaps Annex A (non-existent) would be the right place. Paul ----- Original Message ----- From: Horvath Ernst <mailto:ernst.horvath@SIEMENS.COM> To: ITU-SG16(a)echo.jf.INTEL.COM <mailto:ITU-SG16@echo.jf.INTEL.COM> Sent: Wednesday, May 08, 2002 8:08 AM Subject: Rec. H.501 and "GEF" parameter repository Dear experts, my H.501 final draft contained a placeholder "annex B" for collecting "generic data" (i.e. standardized GEF identifier values). Upon advice by TSB, this annex will be removed in the published version 1 of H.501 since it contained no useful text. The initial idea was to include here material from H.225.0 annex G as soon as version 2 of annex G is finished. But now I have some doubts whether H.501 is the right place for such a data register. A repository of generic data should at least include also values assigned in GEF standards (H.460.x). Wouldn't the H.460 series be a better place for this? At the top level we have assigned so far: - feature ID "0" for H.225.0 Annex G profiles - feature IDs "n" for H.460.n (is this the complete list?) Each top-level feature ID opens a local name space for EnumeratedParameter-IDs specified for that specific feature. Since these are defined locally there is no danger of collisions. At least the top-level IDs should be maintained at a central place to avoid collisions, especially if such IDs can be assigned outside H.460.n standards as well (is this generally the case, or is H.225.0 annex G the only exception?). Of course such a repository could also list the locally assigned EnumeratedParameter-IDs for each registered feature, to provide a quick reference. So the question is, do people see the need for a generic-data register, and if yes, in which form? H.460.x? Or in an IG? H.501 does not seem to be the proper place. Regards, Ernst Horvath Siemens AG

2 1

Re: H.450.1 ASN.1 interoperability issue
by Sasha Ruditsky 15 May '02

15 May '02

Hi I just want to rewrite the same to be sure we are in sync. 6.6.1.3 of the V4 implementors guide does not CHANGE/CONTRADICT ASN.1 of H.450.1 it EXPLAINS how to encode values correctly according to ASN.1 definitions of H.450.1 And this correct encoding is: (as written in 6.6.1.3) invoke.invokeId shall be encoded as INTEGER(0..65535) returnResult.invokeId and returnError.invokeId shall be encoded as INTEGER Sasha -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.COM] Sent: Monday, May 13, 2002 8:49 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: H.450.1 ASN.1 interoperability issue Mark, there was no intention to change any ASN.1 definition in H.450.1. The note was added just to make implementers aware that the InvokeID is encoded differently in the "invoke" APDU and in the "returnResult/returnError" APDUs: in the first case it is constrained by InvokeIdSet, in the second case it is not constrained. This is not an incosistency, just a consequence of the way Packed Encoding Rules were designed. Please also note that "InvokeIdSet" is used in two different meanings: in table 4 it is the name of a parameter of the parameterized structure ROS (i.e. a placeholder), whereas in table 3 it is an "actual" value-set of integers. The brackets in the new note (InvokeIdSet = 0..65535) are not an ASN.1 definition, just an indication what the effective constraint is, namely 0..65535. Table 3 is still the (unchanged) formal definition of the actual "InvokeIdSet". Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Mark Brown [ mailto:Mark.Brown@ED.ACULAB.COM <mailto:Mark.Brown@ED.ACULAB.COM> ] > Gesendet am: Freitag, 10. Mai 2002 17:29 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: H.450.1 ASN.1 interoperability issue > > We've been experiencing some fairly serious interoperability problems > with some systems due to confusion over what exactly the ASN.1 for > H.450.1 is and were hoping someone could clarify things for us. The > problem stems from section 6.6.1.3 of the V4 implementors guide which > adds a note below table 4: > > In the Invoke APDU, the invokeID is an INTEGER constrained by a > PER-visible constraint (InvokeIdSet = 0..65535) and is therefore > encoded as a *constrained* INTEGER (16 bits, no length field). In > the ReturnResult and ReturnError APDUs, however, the invokeID is > encoded as an *unconstrained* integer (with explicit length field) > because the applicable constraint... is not PER-visible. > > However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: > > InvokeIdSet INTEGER ::= {InvokeIds,...} > InvokeIDs ::= INTEGER (0..65535) > > which does not gel with the text in the IG and causes interoperability > issues since the two versions of the ASN.1 for InvokeIdSet are not > encoded identically. This text appears to be unchanged from the > prepublished edition on Packetizer. > > Our understanding of the text added in the IG is that the > intent was to > emphasise that the encoding of the invokeID is not consistent between > the various APDUs and that the no change to the ASN.1 was intended. > This is particularly the case since the IG doesn't modify table 3 as > would be expected if it were correcting the ASN.1 there. Others read > things differently and are using the definition of > InvokeIdSet given in > the IG. > > What is the intention here? If the intention is to redefine the ASN.1 > then some clarification as to why this was done would be very much > appreciated. >

2 1

Meeting Announcement: June 24-28, Bruges
by Paul E. Jones 15 May '02

15 May '02

Dear Experts, At the Kind invitation of Belgacom, we have been invited to Belgium to hold a Rapporteur's meeting the week of June 24 in Bruges, Belgium. This meeting will be held at the same location as the ETSI TIPHON meeting and on the first day, we will have a special meeting with TIPHON called the "TIPHON-NGN Summit". Attached to this e-mail, please find the meeting announcement (the TXT file) and the invitation letter from Belgacom (DOC file). Both contain important information on reserving your hotel room, registering for the meeting, and submitting documents, but each also has unique information, so please read both. I am serving as meeting manager for this meeting, so if you have any questions for clarification, please feel free to ask and, if you feel your question is of general interest, please also address the mailing list so others can benefit from the answer. One outstanding question I have right now is the deadline for the hotel reservations. I will try to get that information and post it to the reflector as soon as possible. However, the best advise is "don't delay". On behalf of all of the Rapporteurs, we look forward to seeing you in Bruges! Best Regards, Paul E. Jones Rapporteur, ITU-T Q2/16 Cisco Systems, Inc.

2 1

AW: H.450.1 ASN.1 interoperability issue
by Horvath Ernst 13 May '02

13 May '02

Mark, there was no intention to change any ASN.1 definition in H.450.1. The note was added just to make implementers aware that the InvokeID is encoded differently in the "invoke" APDU and in the "returnResult/returnError" APDUs: in the first case it is constrained by InvokeIdSet, in the second case it is not constrained. This is not an incosistency, just a consequence of the way Packed Encoding Rules were designed. Please also note that "InvokeIdSet" is used in two different meanings: in table 4 it is the name of a parameter of the parameterized structure ROS (i.e. a placeholder), whereas in table 3 it is an "actual" value-set of integers. The brackets in the new note (InvokeIdSet = 0..65535) are not an ASN.1 definition, just an indication what the effective constraint is, namely 0..65535. Table 3 is still the (unchanged) formal definition of the actual "InvokeIdSet". Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Mark Brown [mailto:Mark.Brown@ED.ACULAB.COM] > Gesendet am: Freitag, 10. Mai 2002 17:29 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: H.450.1 ASN.1 interoperability issue > > We've been experiencing some fairly serious interoperability problems > with some systems due to confusion over what exactly the ASN.1 for > H.450.1 is and were hoping someone could clarify things for us. The > problem stems from section 6.6.1.3 of the V4 implementors guide which > adds a note below table 4: > > In the Invoke APDU, the invokeID is an INTEGER constrained by a > PER-visible constraint (InvokeIdSet = 0..65535) and is therefore > encoded as a *constrained* INTEGER (16 bits, no length field). In > the ReturnResult and ReturnError APDUs, however, the invokeID is > encoded as an *unconstrained* integer (with explicit length field) > because the applicable constraint... is not PER-visible. > > However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: > > InvokeIdSet INTEGER ::= {InvokeIds,...} > InvokeIDs ::= INTEGER (0..65535) > > which does not gel with the text in the IG and causes interoperability > issues since the two versions of the ASN.1 for InvokeIdSet are not > encoded identically. This text appears to be unchanged from the > prepublished edition on Packetizer. > > Our understanding of the text added in the IG is that the > intent was to > emphasise that the encoding of the invokeID is not consistent between > the various APDUs and that the no change to the ASN.1 was intended. > This is particularly the case since the IG doesn't modify table 3 as > would be expected if it were correcting the ASN.1 there. Others read > things differently and are using the definition of > InvokeIdSet given in > the IG. > > What is the intention here? If the intention is to redefine the ASN.1 > then some clarification as to why this was done would be very much > appreciated. >

1 0