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

Interoperability Problems due to Open Type encoding of Null types
by Paul, Manoj 17 Jan '01

17 Jan '01

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. 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. -Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Corrections to Mobile-UIM
by Reddy, Paul K 17 Jan '01

17 Jan '01

Paul, I agree with Mr.Ernst that word OPTIONAL shall be inserted for the tmsi parameter. thanks, Paul -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Wednesday, January 17, 2001 1:45 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: Corrections to Mobile-UIM Importance: High Paul, when changing GSM-UIM element tmsi you deleted the word OPTIONAL. This should be re-inserted because tmsi should certainly not become mandatory. Regards, Ernst > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@ACM.ORG] > Gesendet am: Mittwoch, 17. Jänner 2001 07:16 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Corrections to Mobile-UIM > > Folks, > > In the past week or so, the specifications of the mobile number > definitions-- particularly for GSM-UIM-- were discussed and > changes were > deemed necessary. > > I have made changes as recommended by the Annex H and Annex > E/H.246 editors. > > Please find the attached document with the list of > corrections for H.323v4 > and H.225.0v4. In particular, the first GSM-UIM type in > section 2.5 has > been modified since the last time I e-mailed this draft. > > Please review the changes and any other relevant ASN.1 changes. > > Thanks, > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

AW: Corrections to Mobile-UIM
by Horvath Ernst 17 Jan '01

17 Jan '01

Paul, when changing GSM-UIM element tmsi you deleted the word OPTIONAL. This should be re-inserted because tmsi should certainly not become mandatory. Regards, Ernst > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@ACM.ORG] > Gesendet am: Mittwoch, 17. Jänner 2001 07:16 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Corrections to Mobile-UIM > > Folks, > > In the past week or so, the specifications of the mobile number > definitions-- particularly for GSM-UIM-- were discussed and > changes were > deemed necessary. > > I have made changes as recommended by the Annex H and Annex > E/H.246 editors. > > Please find the attached document with the list of > corrections for H.323v4 > and H.225.0v4. In particular, the first GSM-UIM type in > section 2.5 has > been modified since the last time I e-mailed this draft. > > Please review the changes and any other relevant ASN.1 changes. > > Thanks, > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Status of "AAP" approved standards ?
by Sebestyen Istvan ICN M SR 3 17 Jan '01

17 Jan '01

No, unfortunately the interpretation is not correct. The introduction of AAP has been approved by the WTSA, but is just under implementation now. So, up to now no real AAP voting was sent out. I don't know when the actual start would be launched. Maybe in 4-6 more weeks? This is a guess only... Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M SR 3, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.icn.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/ ---------------------------------------------------------------------------- ---------------- > ---------- > From: Klaghofer Karl ICN EN HC SE 81 > Reply To: Klaghofer Karl ICN EN HC SE 81 > Sent: Wednesday, January 17, 2001 11:48 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Status of "AAP" approved standards ? > > Dear all, > > What is the status of the documents that had been approved in the November > SG16 Meeting in Geneva "based on consent", i.e. approved according to the > new Alternative Approval Process (AAP) - like e.g. H.450.10, H.450.11, > H.323 > Annex L,... > > Since AAP approval is now two months ago (and I did not see any > discussions/objections on those documents at least on this mailing list), > they should now be official ITU-T standards ? Can anyone (maybe the > Rapporteurs) confirm my interpretation ? > > Thanks, > Karl Klaghofer > Siemens AG > karl.klaghofer(a)icn.siemens.de > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

2 1

Status of "AAP" approved standards ?
by Klaghofer Karl ICN EN HC SE 81 17 Jan '01

17 Jan '01

Dear all, What is the status of the documents that had been approved in the November SG16 Meeting in Geneva "based on consent", i.e. approved according to the new Alternative Approval Process (AAP) - like e.g. H.450.10, H.450.11, H.323 Annex L,... Since AAP approval is now two months ago (and I did not see any discussions/objections on those documents at least on this mailing list), they should now be official ITU-T standards ? Can anyone (maybe the Rapporteurs) confirm my interpretation ? Thanks, Karl Klaghofer Siemens AG karl.klaghofer(a)icn.siemens.de ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Corrections to Mobile-UIM
by Paul E. Jones 17 Jan '01

17 Jan '01

Folks, In the past week or so, the specifications of the mobile number definitions-- particularly for GSM-UIM-- were discussed and changes were deemed necessary. I have made changes as recommended by the Annex H and Annex E/H.246 editors. Please find the attached document with the list of corrections for H.323v4 and H.225.0v4. In particular, the first GSM-UIM type in section 2.5 has been modified since the last time I e-mailed this draft. Please review the changes and any other relevant ASN.1 changes. Thanks, Paul

1 0

RE: H.225- CRV
by Nehru, Archana 17 Jan '01

17 Jan '01

Paul, Since we agree that CRVs should be unique between two endpoints, what is the ideal behavior in the following case? Let us say there are two endpoints running on the same machine..which means that they have the same source IP address. Since the two endpoints are independent entities, they will generate CRVs independently. Now let us say both the endpoints make a call to another endpoint/GK with the same CRV. So at the receiver's side, we see two incoming calls with exactly the same CRV and exactly same "source" IP address. Is this a valid configuration? How is a receiver supposed to handle these incoming calls, particularly is there is no "callId"? Thanks -Archana >-----Original Message----- >From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] >Sent: Tuesday, January 16, 2001 12:40 PM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Re: H.225- CRV > > >Chris, > >Considering that V1 only allowed a single call over a single >TCP connection, >what would have been the point of a CRV in the Setup message? >If they could >all be the same, it makes them worthless. (Of course, I've >found CRVs in >packet-switched systems mostly worthless, but not entirely.) > >From H.323: >``One CRV is used to associate the call signalling messages. >This CRV shall >be used in all call signalling messages between two entities >(endpoint to >Gatekeeper, endpoint-to-endpoint, etc.) related to the same call.'' > >Note the text that says "between two entities". If the intent was that >these values were only unique "per connection", it would say >so. The CRVs >are unique between two entities. > >From H.225.0: >``Note that the CRV is only unique on a particular part of a call, e.g. >between two terminals, or between a terminal and a gatekeeper. >If a given >terminal has two calls in the same conference, each shall have the same >conference ID but different CRVs.'' > >The latter sentence is more important: when communicating between two >entities, it states clearly that there must be different CRVs. > Again, with >V1 those two calls would have been using different TCP >connections, yet the >text clearly says the CRVs must be different. > >Now, I may be wrong-- this is just my interpretation of the >text. I'd like >to hear other comments. > >Paul > >----- Original Message ----- >From: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk> >To: "Paul E. Jones" <paulej(a)packetizer.com> >Cc: <ITU-SG16(a)mailbag.cps.intel.com> >Sent: Tuesday, January 16, 2001 5:16 AM >Subject: Re: H.225- CRV > > >> Paul, >> >> I disagree. CRV is surely unique per connection. >> One may be well advised to keep it more unique than that, because in >> gatekeepered environments you're liable to end up with >problems if you're >not >> careful because of your note 1 - but if I receive Q.931 messages on >separate >> TCP connections giving the same CRV I shouldn't expect them >to refer to >the >> same call. I argue that this is rooted in the principal of >TransportAddress >> throughout the H.323 standards including the SAPI (IP port >number) as well >as >> actual address. >> >> Regards, >> Chris >> >> "Paul E. Jones" wrote: >> > >> > Archana, >> > >> > (a) is closer to the way things actually work. >> > >> > Essentially, you can use whatever values you wish so long >as you never >place >> > two calls to the same endpoint using the same CRV value. >So, whether >two >> > calls to an endpoint use the same TCP connection or different >connections, >> > the CRV must be unique. >> > >> > You should also consider the possibility that an endpoint >may have two >call >> > signaling addresses. How would you know if this were the >case? The >safest >> > thing to do is never have two calls with the same CRV at >the same time. >> > However, if you know that the destination endpoints are unique, you >could >> > re-use the CRV value.. at least when a Gatekeeper is not >being used. >> > >> > There are also so other properties of CRVs: >> > 1) The CRV sent in an ARQ to place a call shall be the >same as the >> > CRV in the resulting Setup message >> > 2) The CRV sent in an ARQ to accept a call should *not* be taken >> > from the incoming Setup message-- it should be >locally generated so >> > that it is a unique between the endpoint and the GK >> > >> > Paul >> > >> > ----- Original Message ----- >> > From: "Nehru, Archana" <archie(a)trillium.com> >> > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM> >> > Cc: <ITU-SG16(a)mailbag.cps.intel.com> >> > Sent: Monday, January 15, 2001 10:28 PM >> > Subject: H.225- CRV >> > >> > > hi all, >> > > >> > > I have a question about H.323 -CRV values. Q.931 specs >says that a CRV >> > value >> > > should be unique per D-channel layer 2 logical link. >> > > >> > > In H.225 context, does the above mean that: >> > > >> > > a) CRV values should be unique across all outgoing H.225 >calls that >have >> > the >> > > same "destination" IP address ? >> > > >> > > b) CRV value only needs to be unique across all H.225 connections >using >> > the >> > > same TCP connection? In other words, if an endpoint A makes two >> > simultaneous >> > > calls to endpoint B, then the same CRV can be used on >both the calls, >as >> > > long as they use different TCP connections? >> > > >> > > I would appreciate any help on this. >> > > >> > > Regards >> > > Archana >> > > >> > > >> > > >> > >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > For help on this mail list, send "HELP ITU-SG16" in a message to >> > listserv(a)mailbag.intel.com >> >> -- >> Dr Chris Purvis -- Development Manager >> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road >> Winkfield Row, Berkshire. RG42 6LY ENGLAND >> Phone: +44 1344 899 007 >> Fax: +44 1344 899 001 >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com >

2 1

Please Review corrections for H.225.0v4 and H.323v4
by Paul E. Jones 16 Jan '01

16 Jan '01

Experts, As you know, I have posted a document to this list a number of times seeking comments on corrections that need to be applied to H.323v4 and H.225.0v4. I was given permission by the TSB to make these changes, but before such changes are made, I want to give you one last opportunity to comment. To this date, every comment that I have received has been one of agreement-- I have heard no objections. The ASN.1 found in this document is the same as that which has been posted to the Packetizer web-site and I know that several companies have already grabbed that ASN.1 for implementation purposes. I don't believe there should be any contentious issues in this document, but I wanted to give you one last opportunity to review and comment. Please send comments directly to me and/or post them to this list. If I hear no objections, I will forward this document to the TSB for inclusion in the final published H.225.0v4 and H.323v4. Thanks, Paul

2 2

Re: Final Revision of Changes for H.225.0v4 and H.323v4
by Paul E. Jones 16 Jan '01

16 Jan '01

Krish, I believe Pete may be the better person to answer this question. Essentially, if the Gatekeeper provides the needed feature-- that's great. If it does not, it needs to ensure that the LRQ contains the needed feature information so that the destination Gatekeeper can locate an entity that can provide the features. I believe this logic applies regardless of whether the call is routed or not. Paul ----- Original Message ----- From: "Sudharsana krishnan P" <pskrish(a)miel.mot.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; "'H323implementors(a)Imtc.Org' (E-mail)" <h323implementors(a)imtc.org> Cc: <pskrish(a)miel.mot.com> Sent: Monday, January 15, 2001 11:36 PM Subject: RE: Final Revision of Changes for H.225.0v4 and H.323v4 > Hello Paul > I was reviewing this document and had a slight doubt related to the following > Section 1.6 > ------------ > If the responding entity is a Gatekeeper that sends an LRQ in response to receiving an ARQ, the Gatekeeper shall copy any features that are not provided by the Gatekeeper into the LRQ. In trying to determine whether the necessary set of features are supported, the Gatekeeper shall examine the supported features of the endpoint to which the ARQ may resolve, either locally or in response to an LCF, and the features supported by the Gatekeeper. > ------------------- > > Case 1: GK routed model should read. > > If the responding entity is a Gatekeeper that sends an LRQ in response to receiving an ARQ, the Gatekeeper shall NOT copy any features that are not provided by the Gatekeeper into the LRQ. In trying to determine whether the necessary set of features are supported, the Gatekeeper shall examine the supported features of the endpoint to which the ARQ may resolve, either locally or in response to an LCF, and the features supported by the Gatekeeper. > > Case 2: Direct routed model should read. > > If the responding entity is a Gatekeeper that sends an LRQ in response to receiving an ARQ, the Gatekeeper SHALL copy any features EVEN IF NOT provided by the Gatekeeper into the LRQ. In trying to determine whether the necessary set of features are supported, the Gatekeeper shall examine the supported features of the endpoint to which the ARQ may resolve, either locally or in response to an LCF. > > Did I miss something here > ------------------- > > Regards > krish > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Paul E. Jones > Sent: Monday, January 15, 2001 8:27 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Final Revision of Changes for H.225.0v4 and H.323v4 > > > Folks, > > I have attached what I hope is the final revision of the changes to > H.225.0v4 and H.323v4. The additional changes are in response to e-mails I > have received. > > The changes from the last revision include new sections 1.5, 1.9, and 2.2. > There are no additional ASN.1 changes. > > These changes were necessary in order to align the text between H.323v4 and > H.225.0v4. > > Please give me any comments by the end of the business day Tuesday. > > Thanks, > Paul E. Jones > Q.2/16 Rapporteur > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[Fwd: Maximum and Current Call Capacities ASN.1 in H225.0v4]
by Logan Modahala 12 Jan '01

12 Jan '01

Resending to get the attention of interested parties. - Logan

1 0