July 2000 - sg16-avd - lists.packetizer.com

Calling Party Number
by Klaghofer Karl ICN EN HC SE 81 06 Jul '00

06 Jul '00

Francois, Some further thoughts on this issue, A calling party may provide both E.164 number and PNP number within H.323 (applies also in case of calling party being in SCN (e.g. PBX). I agree, the E.164 address should be in H.225.0 Calling Party Number IE; the PNP address should be within the Setup-UUIE.sourceAddress.partyNumber.privateNumber field. A second E.164 number - if received from the SCN - may be sent further by an ingress GWY within a second H.225.0 Calling Party Number IE if the two calling party number option is supported. The alternative to map this second E.164 number received into Setup-UUIE.sourceAddress.partyNumber.publicNumber field is not recommended, since we currently in H.225.0 have the problem that the SetupUUIE.presentatioIndicator and SetupUUIE.screeningIndicatir always apply to all alias addresses in Setup-UUIE (PNP, E.164, etc) which might be a problem. Furthermore, you may want to provide any kind of modified/prefixed calling party number (e.g. by GWY or GK). This should then be placed within Setup-UUIE.sourceAddress.dialledDigits field. Regards, Karl -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet am: Donnerstag, 6. Juli 2000 19:38 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Reference which version of Q.931, etc.? Francois, I do not know of any impact directly. However, it will be necessary to verify what the impact might be, if any. As an additional though, Q.931 supports two Calling Party IEs. Do we need two calling party structures in ASN.1 for equivalent support? I am not sure. I tought the 2 Calling Party IEs are only use when one is public-network-provided (i.e., verified by Ma Bell) and the other is "user" or "private-network" provided. In that case, it might be sufficient to only use the information element (the 2 of them) since it will always be E.164 numbers (at least for the E.164 number). I could see 2 IEs (one with the verified E.164 number, the other with the un-verified user-provided number), or 1 IE (with the verified number) and 1 ASN.1 with the private number. What do you think? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Reference which version of Q.931, etc.?
by Francois Audet 06 Jul '00

06 Jul '00

I would agree that it should be the 1998 version (not that it matters since we are not using Q.931 in the first place, but our own "interpretation" of it). Are we even allowed to refer to "superceded" versions of a Recommendation? > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Thursday, July 06, 2000 5:11 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Reference which version of Q.931, etc.? > > > Rich, > > I guess that I misunderstood what you were saying. I agree that your > proposed solution is the only practical one at this time. > > As to Q.932, etc. I think that it would be best to keep all > references to > the versions in v2 for the same reason as for Q.931. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ >>

1 0

Re: Reference which version of Q.931, etc.?
by Francois Audet 06 Jul '00

06 Jul '00

Francois, I do not know of any impact directly. However, it will be necessary to verify what the impact might be, if any. As an additional though, Q.931 supports two Calling Party IEs. Do we need two calling party structures in ASN.1 for equivalent support? I am not sure. I tought the 2 Calling Party IEs are only use when one is public-network-provided (i.e., verified by Ma Bell) and the other is "user" or "private-network" provided. In that case, it might be sufficient to only use the information element (the 2 of them) since it will always be E.164 numbers (at least for the E.164 number). I could see 2 IEs (one with the verified E.164 number, the other with the un-verified user-provided number), or 1 IE (with the verified number) and 1 ASN.1 with the private number. What do you think?

1 0

Re: Reference which version of Q.931, etc.?
by Callaghan, Robert 06 Jul '00

06 Jul '00

Paul, I think that consistence of references between H.323 and H.225.0 would be a good thing. It would not be good to gain a feature or code point in H.323 that is not supported by H.225.0. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Thursday, July 06, 2000 12:12 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Reference which version of Q.931, etc.? Rich, Hmmm... editors in disagreement? Perhaps I should read before I post :-). OK, if Rich is willing to make this change, I suppose I can do the same for H.323, though I would guess it is much less work. I took a quick scan and there do not appear to be any issues in H.323, per se, that require attention in order to make this change. Is anyone aware of any issues? Paul ----- Original Message ----- From: "Rich Bowen" <rkbowen(a)CISCO.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Wednesday, July 05, 2000 11:07 PM Subject: Re: Reference which version of Q.931, etc.? > Hi Bob, > > I just want to remind everyone that we agreed in Osaka not to update the > Q.931 cross-references, but instead to revert the parent reference to > Q.931 (1993) so we (I) wouldn't have to update and verify all of the > table references, etc. > > However, when I was about to make that change, I noticed that there were > references to 1998 versions of other standards (Q.932, Q.850) also, and > I was concerned that these other standards might reference the 1998 > version of Q.931, so we would have a synchronization problem of another > kind. That's why I didn't make the change, and noted this as an open > issue. > > I also have some concern about referencing a standard that is no longer > published. > > My preference would be to leave the parent reference as Q.931 (1998) and > update the semi-infinite number of cross-references. > > I agree the inconsistency has to be corrected. BTW, this also existed > in v2. > > - Rich > > "Callaghan, Robert" wrote: > > > > On of the open issues is the correct version of Q.931 should be referenced > > in H.225.0 and H.323. When v3 was decided, they was updated to reference > > Q.931(1998) instead of Q.931(1993). This is a discussion of the impact of > > this change and how to resolve the problems. > > > > - H.225.0 and Q.931 include a semi-infinite number of references to table, > > figures and sections of Q.931. V3 still references the 1993 items even > > though the parent reference is 1998. It is possible to update all the > > detailed references or to return the parent reference to 1993. Either way > > they must be consistent. > > > > - Q.931(1998) introduced a number of changes from the 1993 version. If we > > update v4 to consistently reference 1998, do we want to automatically > > include all the changes in Q.931? > > > > - If we do accept, by default, the changes to Q.931, do any of these changes > > conflict with the ASN.1 coding that we use? If so, how is this resolved? > > > > However this problem is resolved, it must be consistent within H.323v4 and > > H.225.0v4. > > > > Bob > > > > ------------------------------------------------------------------ > > Robert Callaghan > > Siemens Enterprise Networks > > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > Email: Robert.Callaghan(a)ICN.Siemens.com > > ------------------------------------------------------------------ > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > VoIP Session Protocols Research Triangle Park, NC, USA > -------------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Re: Reference which version of Q.931, etc.?
by Callaghan, Robert 06 Jul '00

06 Jul '00

Rich, I guess that I misunderstood what you were saying. I agree that your proposed solution is the only practical one at this time. As to Q.932, etc. I think that it would be best to keep all references to the versions in v2 for the same reason as for Q.931. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Wednesday, July 05, 2000 11:07 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Reference which version of Q.931, etc.? Hi Bob, I just want to remind everyone that we agreed in Osaka not to update the Q.931 cross-references, but instead to revert the parent reference to Q.931 (1993) so we (I) wouldn't have to update and verify all of the table references, etc. However, when I was about to make that change, I noticed that there were references to 1998 versions of other standards (Q.932, Q.850) also, and I was concerned that these other standards might reference the 1998 version of Q.931, so we would have a synchronization problem of another kind. That's why I didn't make the change, and noted this as an open issue. I also have some concern about referencing a standard that is no longer published. My preference would be to leave the parent reference as Q.931 (1998) and update the semi-infinite number of cross-references. I agree the inconsistency has to be corrected. BTW, this also existed in v2. - Rich "Callaghan, Robert" wrote: > > On of the open issues is the correct version of Q.931 should be referenced > in H.225.0 and H.323. When v3 was decided, they was updated to reference > Q.931(1998) instead of Q.931(1993). This is a discussion of the impact of > this change and how to resolve the problems. > > - H.225.0 and Q.931 include a semi-infinite number of references to table, > figures and sections of Q.931. V3 still references the 1993 items even > though the parent reference is 1998. It is possible to update all the > detailed references or to return the parent reference to 1993. Either way > they must be consistent. > > - Q.931(1998) introduced a number of changes from the 1993 version. If we > update v4 to consistently reference 1998, do we want to automatically > include all the changes in Q.931? > > - If we do accept, by default, the changes to Q.931, do any of these changes > conflict with the ASN.1 coding that we use? If so, how is this resolved? > > However this problem is resolved, it must be consistent within H.323v4 and > H.225.0v4. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: Reference which version of Q.931, etc.?
by Callaghan, Robert 06 Jul '00

06 Jul '00

Francois, I do not know of any impact directly. However, it will be necessary to verify what the impact might be, if any. As an additional though, Q.931 supports two Calling Party IEs. Do we need two calling party structures in ASN.1 for equivalent support? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Sent: Wednesday, July 05, 2000 6:30 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Reference which version of Q.931, etc.? Bob, Can you elaborate on why some changes in Q.931 might affect the ASN.1 description? > - If we do accept, by default, the changes to Q.931, do any > of these changes > conflict with the ASN.1 coding that we use? If so, how is > this resolved?

1 0

AW: Reference which version of Q.931, etc.?
by Klaghofer Karl ICN EN HC SE 81 06 Jul '00

06 Jul '00

Remember that H.225.0 is its own protocol. Changing any reference to Q.931 versions might effect the normative H.225.0 requirements and by this compatibility. So, I thought we had agreed in Osaka to continue refering to 1993 ? As Paul pointed out the v3 98 version reference was introduced by error of the itu secretary. Usually we correct such errors which would mean changing the reference back to 93. Karl -----Ursprüngliche Nachricht----- Von: Rich Bowen [mailto:rkbowen@CISCO.COM] Gesendet am: Donnerstag, 6. Juli 2000 05:07 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Reference which version of Q.931, etc.? Hi Bob, I just want to remind everyone that we agreed in Osaka not to update the Q.931 cross-references, but instead to revert the parent reference to Q.931 (1993) so we (I) wouldn't have to update and verify all of the table references, etc. However, when I was about to make that change, I noticed that there were references to 1998 versions of other standards (Q.932, Q.850) also, and I was concerned that these other standards might reference the 1998 version of Q.931, so we would have a synchronization problem of another kind. That's why I didn't make the change, and noted this as an open issue. I also have some concern about referencing a standard that is no longer published. My preference would be to leave the parent reference as Q.931 (1998) and update the semi-infinite number of cross-references. I agree the inconsistency has to be corrected. BTW, this also existed in v2. - Rich "Callaghan, Robert" wrote: > > On of the open issues is the correct version of Q.931 should be referenced > in H.225.0 and H.323. When v3 was decided, they was updated to reference > Q.931(1998) instead of Q.931(1993). This is a discussion of the impact of > this change and how to resolve the problems. > > - H.225.0 and Q.931 include a semi-infinite number of references to table, > figures and sections of Q.931. V3 still references the 1993 items even > though the parent reference is 1998. It is possible to update all the > detailed references or to return the parent reference to 1993. Either way > they must be consistent. > > - Q.931(1998) introduced a number of changes from the 1993 version. If we > update v4 to consistently reference 1998, do we want to automatically > include all the changes in Q.931? > > - If we do accept, by default, the changes to Q.931, do any of these changes > conflict with the ASN.1 coding that we use? If so, how is this resolved? > > However this problem is resolved, it must be consistent within H.323v4 and > H.225.0v4. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: [V4] H.323 URL
by Orit Levin 06 Jul '00

06 Jul '00

1) I agree with "An H.323 entity may accept any valid URL that it understands, but should support the H.323 URL as defined in this section.'' I am not sure that it should be in this specific place in H.323v4, because it invites more questions then clarifies the H323-URL topic, ... but I will not object. 2) TD-40a defines user without "1*" on purpose, keeping the possibility to have an empty user defintion. In this way both user and host are "optional", but you can exactly parse and understand their meaning. This may be useful in Discovery Procedures (as mentioned in TD-40a). 3) Use of DNS technology is the main reason... It is not the only one... Agreed, of cause. Still, a short "motivation" phrase to be included into H.323v4 is desired. (I also agree that Annex O should describe the recommended procedures :-) 4) "Note 4" says "The H323-URL is defined to use a form without brackets". 5) I completely agree that IPv6 addresses should be included. The definition seems syntactically correct to me... till somebody finds an error. 6) In regards to "escaped". I had the same dilemma while writing the original APC-1775. "One of the RFCs " summarizes the explanations already existing in referenced by us general RFCs. So, I think, we don't need a summary here. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)PACKETIZER.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Friday, June 30, 2000 5:10 PM Subject: [V4] H.323 URL >Orit, > >You proposed to remove this sentence: >``An endpoint may accept any valid URL that it understands, but H.323 >entities should also support the H.323 URL as defined in this section.'' > >However, I prefer to keep it or something like it. I do not want people to >believe that the H.323 URL is the only valid URL that may be used within an >H.323 entity. I changed the sentence to this to not be restrictive to >endpoints: >``An H.323 entity may accept any valid URL that it understands, but should >support the H.323 URL as defined in this section.'' > >You suggested this line addition: >``...by using the DNS technology widely deployed in Internet and other IP >networks.'' > >Bob mentioned that he might want to query a non-DNS database. Certainly, >DNS will not work for a URL of this form: h323:+19193876899 > >We should probably expand the text a bit more and say that if the URL is in >the form of "user@hostport", the host portion may be considered for some >type of DNS query. However, we do not have any defined procedures for DNS >queries using this scheme.. and that's a topic for Annex O, I guess. I'd >hate to be restrictive in this section until we have defined the procedures. > >Regarding comments (4) and (5)... I assume you mean "Note 4" and "Note 5"? >If you want the IP address to be enclosed in brackets when it is IPv4, we >need to modify the syntax. However, I don't think that it is necessary. >RFC 2396, which is the source of much of this syntax, does not use brackets >for IPv4 addresses. They are, however, used in IPv6 addresses as Michael >Welser in an earlier message. Note 5 is a valid note and I have added it to >the text. > >I also question the "escaped" production. I understand what it's for, but >we do not explain it. Do we need a paragraph explaining it or is there a >reference we should make? I suspect there is text one of the RFCs that >already describes this clearly. > >I have attached the modified section of text this e-mail for review. > >Paul > >----- Original Message ----- >From: "Orit Levin" <orit(a)radvision.com> >To: <ITU-SG16(a)mailbag.cps.intel.com> >Sent: Friday, June 30, 2000 3:43 PM >Subject: H.323 URL > > >> Hi Paul and all the others! >> This is my attempt to articulate the H323-URL motivation and use in the >> shortest way. >> I don't have any problem with expanding or/and tightening the definition >of >> the H.323 URL. >> I think we should incorporate the real syntax corrections now. >> Nevertheless, I would prefer to decide a BASIC H323-URL in a way which >makes >> it possible for later backwards compatible modifications. >> I addition to that, I think that comments (4) and (5) from TD-40a should >> appear in the decided document. >> Regards, >> Orit Levin >> RADVision Inc. >> 575 Corporate Drive Suite 420 >> Mahwah, NJ 07430 >> Tel: 1 201 529 4300 (230) >> Fax: 1 201 529 3516 >> www.radvision.com >> orit(a)radvision.com >> -----Original Message----- >> From: Michael Welser <michael.welser(a)AON.AT> >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> >> Date: Friday, June 30, 2000 5:43 AM >> Subject: Re: H.323 URL Text >> >> >> >I propose to change the ABNF to the following: >> > >> > H323-URL = "H323:" user [ "@" hostport ] >> > user = 1*( unreserved / escaped ) >> > hostport = host [":" port] >> > host = hostname / IPv4address / IPv6reference >> > hostname = *( domainlabel "." ) toplabel [ "." ] >> > domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum >> > toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum >> > IPv6reference = "[" IPv6address "]" >> > IPv6address = hexpart [ ":" IPv4address ] >> > IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT >> > IPv6prefix = hexpart "/" 1*2DIGIT >> > hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] >> > hexseq = hex4 *( ":" hex4) >> > hex4 = 1*4HEXDIG >> > port = 1*DIGIT >> > unreserved = alphanum / mark >> > alphanum = ALPHA / DIGIT >> > mark = "-" / "_" / "." / "!" / "~" / "*" / "'" >> > / "(" / ")" / "&" / "=" / "+" / "$" / "," >> > escaped = "%" HEXDIG HEXDIG >> > >> >This introduces IPv6 adresses according to RFCs 2732, 2373 and 2396. The >> >ABNF still relies on RFC 2234. >> > >> >It also corrects the IPv4 address by limiting each segment to three >> >digits. >> > >> >I am not too sure about the 'port'. Although 1*DIGIT makes absolutely >> >sense, most schemes currently in use are more relaxed about it and just >> >do a DIGIT. >> > >> >I am also not too sure about the extended user definition and the >> >password extension which are used e.g. in SIP and HTTP: >> > >> > H323-URL = "H323:" userinfo [ "@" hostport ] >> > userinfo = user [ ":" password ] >> > user = *( unreserved / escaped >> > / "&" / "=" / "+" / "$" / "," ) >> > password = *( unreserved | escaped >> > / "&" / "=" / "+" / "$" / "," ) >> > etc. >> > >> >Could we need that? >> > >> >Cheers, >> > >> >Michael >> >(welser(a)acm.org) >> > >> >> -----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, June 26, 2000 12:23 PM >> >> To: ITU-SG16(a)mailbag.cps.intel.com >> >> Subject: H.323 URL Text >> >> >> >> >> >> Folks, >> >> >> >> I have attached the text that I propose adding to the H.323v4 document >> >> relating to the H.323 URL scheme. I think this text is weak, >> >> but I expect >> >> contributions to be brought to define the usage of this >> >> scheme-- presently, >> >> there really is no procedural text. >> >> >> >> I'd like to point out that I removed the telephone number >> >> portions of the >> >> URL, which should make both Orit and Bob happy :-) >> >> >> >> Please review the text and the ABNF grammar for errors. You >> >> will note one >> >> small bit of procedural text near the end where it discusses >> >> the fact that a >> >> Gatekeeper may modify the alias provided to the Gatekeeper. >> >> The substance >> >> of that existed in TD-50 (Osaka) and I thought that it was >> >> important to go >> >> ahead and include that at the very least. >> >> >> >> Please, give me feedback. Mr. Bowen and I plan to post H.323v4 and >> >> H.225.0v4 this week for review. A formal announcement will >> >> be made later >> >> today or tomorrow. >> >> >> >> Best Regards, >> >> 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

Reference which version of Q.931, etc.?
by Callaghan, Robert 06 Jul '00

06 Jul '00

On of the open issues is the correct version of Q.931 should be referenced in H.225.0 and H.323. When v3 was decided, they was updated to reference Q.931(1998) instead of Q.931(1993). This is a discussion of the impact of this change and how to resolve the problems. - H.225.0 and Q.931 include a semi-infinite number of references to table, figures and sections of Q.931. V3 still references the 1993 items even though the parent reference is 1998. It is possible to update all the detailed references or to return the parent reference to 1993. Either way they must be consistent. - Q.931(1998) introduced a number of changes from the 1993 version. If we update v4 to consistently reference 1998, do we want to automatically include all the changes in Q.931? - If we do accept, by default, the changes to Q.931, do any of these changes conflict with the ASN.1 coding that we use? If so, how is this resolved? However this problem is resolved, it must be consistent within H.323v4 and H.225.0v4. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 3

Re: Reference which version of Q.931, etc.?
by Francois Audet 05 Jul '00

05 Jul '00

Bob, Can you elaborate on why some changes in Q.931 might affect the ASN.1 description? > - If we do accept, by default, the changes to Q.931, do any > of these changes > conflict with the ASN.1 coding that we use? If so, how is > this resolved?

1 0