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

APC-number request
by Jaakko Sundquist 08 Aug '00

08 Aug '00

Mr Okubo, Could you allocate an APC number for me for the H.323 Annex H Draft. Thank you in advance. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

APC-1903 uploaded
by Michael Fortinsky 08 Aug '00

08 Aug '00

APC-1903.zip ("H.225.0 Annex G version 2 - draft") has been uploaded to the Incoming directory at the Pictel avc-site. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Re: APC number Request
by Sakae OKUBO 07 Aug '00

07 Aug '00

Dear Mr. Gilman, Dear Mr. Li, Dear Mr. Euchner, In response to your requests, APC numbers have been allocated to your contributions as follows: APC-1904 Avaya DES with Output Feedback for Audio Encryption in H.235v3 APC-1905 UCLA Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-1906 UCLA Simulation results of ULP for transmission over error prone channels APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.225-Annex G clarification
by Archana Nehru 07 Aug '00

07 Aug '00

Michael, Thanks for responding. Please see my comments inline. Thanks Archana UsageSpecification::= sequence { sendTo ElementIdentifier ..., sendToDomainIdentifier AliasAddress } The domainIdentifier field will provide the following: (a) an indication of which domain is to receive the usageIndications (b) a resolvable address (either an explicit IP address, or something like a URL or email address that can be resolved to one or more border element addresses within the target domain) Any comments? [Archana Nehru] I am not clear how we can use one field "sendToDomainIdentifier" to contain both (a and b) information. Since "AliasAddress" is currently defined as a "choice", would not we then need one more parameter in the usage specification structure to indicate the second parameter(either a or b)? But before we come to a solution for this problem, I think we need to answer one more question which is: " what is the purpose of including a "domainId" and "Border element identifier" in the usage specfication message? How is a receiving BE supposed to interpret and use this information? If these two together do not give us a "resolvable" address, then why not add a field for a "resolvable address" only? Oddly enough Annex G specs does not discuss the purpose of exchanging (for that matter even for having) fields like "domainId" and "border element identifier" at all. So I guess we need to clarify this issue first and once we are clear with that , we can suitable fields to the "usageSpecification" structure. Please let me know what you think.

1 0

Re: H.225-Annex G clarification
by Michael Fortinsky 07 Aug '00

07 Aug '00

Hi Archana, I agree that you have found a problem with the current definition of the "sendTo" field. There are actually two problems: (1) "sendTo" is defined as an elementIdentifier, and there is no guarantee that it is unique (this you mentioned) (2) there is no guarantee that the border element that receives the "sendTo" within a usageSpec will even understand it - an elementIdentifier is not defined to be a resolvable address; it is just a string (it can contain a resolvable string, but currently the standard does not enforce this) Here is a simple example that illustrates problem (2). Assume three border elements: BE(a), BE(b), and BE(CH) (CH=clearinghouse) Each resides in a separate domain. BE(a) sends an AccessRequest to BE(CH). BE(CH) sends an AccessConfirmation, which tells BE(a) to route the call to a gatekeeper in domain b, and which contains a usageSpec that has "sendTo" = "BE(b)". BE(a) has no idea where "BE(b)" is (since BE(a) has never sent any messages to BE(a) before) so BE(a) does not know where to send usageIndications. So, I agree that something needs to be added to Annex G. I think that if we add a "domainIdentifier" field (which is defined as an aliasAddress) to the usageSpec, we can solve the problem. The new definition of the usageSpec will look like: UsageSpecification::= sequence { sendTo ElementIdentifier ..., sendToDomainIdentifier AliasAddress } The domainIdentifier field will provide the following: (a) an indication of which domain is to receive the usageIndications (b) a resolvable address (either an explicit IP address, or something like a URL or email address that can be resolved to one or more border element addresses within the target domain) Any comments? Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867 Archana Nehru <archie(a)TRILLIUM.COM> Sent by: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> 07/25/00 01:30 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 To: ITU-SG16(a)mailbag.cps.intel.com cc: Subject: H.225-Annex G clarification hi everyone, I need a clarification on the following issue for H.225 -Annex G used for communication between two border elements(BE). I would appreciate any help on this. 1. In the current Annex G specfications, border elements exchange "usageIndication" messages with each other to inform each about "call usages" etc for billing purposes. The usage Indication message is sent according to a information element called "usageSpecifcation". This element is exchanged in messages like ACCESS_CONFIRM etc. The ASN syntax defined for this "usageSpecification" is: UsageSpecification::= sequence { sendTo ElementIdentifier .... } The "sendTo" field is supposed to identify the destination "border element" to which the "usage indication" messages for a call must be sent. The issue here is that "elementidentifier" is not defined as a "unique string", so the "sendTo" field by itself cannot identify the destination BE of the "usageIndication" message uniquely? In other words, to send a usage indication message, a BE needs to know the logical address of the "destination" BE. This logical address could then be resolved to a transport address which in turn is used to send "usageIndication" messages. So dont we need to add suitable fields to the "usageSpecification" field to identify the recipient of the "usageindication" message uniquely? If yes, then we should add a "domainId"(this defines the domain within which the BE resides) and also a "logical address" to the "usageSpecification" element. Do we agree that this is required? Regards Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Reminder for contribution submission to the Portland meeting
by Sakae OKUBO 07 Aug '00

07 Aug '00

Dear Q12-14/16 experts, Please be reminded of the following deadlines: /// Registration of the document: by 23:59 UTC, 11 August /// /// Distribution of the document: by 23:59 UTC, 14 August /// /// Use the ftp site (or e-mail reflector) for distribution /// This is not to encourage you to do so, but please note that contributions arrived after these deadlines may be considered subject to the agreement of the meeting. I would like to mention this because we are in the middle of summer holiday season. Please find attached at the end of this message the current list of registered contributions (as of 23:59, 7 August, Tokyo time). If your contribution is missing, please advise me. As to the contributions carried over from Osaka, I listed APC-1781, 1819, 1820, 1822 from Lucent Technologies without confirmation. Please advise me if a new version is submitted and its original Osaka contribution need not be listed. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ------< carried over from the Osaka meeting >------ APC-1765 AT&T Scope of H.323 QOS APC-1766 AT&T Requirements of H.323 QOS APC-1767 AT&T Architecture of H.323 QOS APC-1768 AT&T Specification of H.323 QOS Characteristics APC-1781 Lucent Technologies Reference Points for the Use of Annex G APC-1796 Editor (M Fortinsky) H.225.0 Annex G version1 - with corrections APC-1819 Lucent Technologies Update on ETSI TIPHON architecture work including latest TIPHON Architecture Draft APC-1820 Lucent Technologies Update on ETSI TIPHON QoS work including latest TIPHON End to End QoS Framework Draft APC-1822 Lucent Technologies Generic Bearer Descriptor for End to End QoS APC-1845 BT Applying the Extensible Package Framework to Annex G ------< registration for the Portland meeting >------ APC-1872 Q22/11 Liaison to SG16 On Interaction Between Intelligent Network Systems and H.248 APC-1873 Q22/11 Liaison to SG16 On Interworking Between H.323 Systems and Intelligent Network Systems APC-1874 Editor (P Jones) Draft H.323 version 4 APC-1875 Editor (P Jones) H.323-series Implementers Guide APC-1876 Editor (K Klaghofer) Draft Call Offer Supplementary Service for H.323 APC-1877 Editor (K Klaghofer) Draft Call Intrusion Supplementary Service for H.323 APC-1878 Editor (T Anderson) Draft H.323 Annex R (Robustness) APC-1879 Lucent Technologies Reference Points for the Use of Annex G APC-1880 Editor (F Audet) H.323 Annex M.1 "Tunnelling of signalling protocols (QSIG) in H.323" APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 APC-1883 Columbia University CPL: A Language for User Control of Internet Telephony Services APC-1884 SONUS Decomposition of Gatekeeper Functions inside a Domain APC-1885 Hughes Software Systems { to suggest amendments in the H.323 standard } APC-1886 Columbia University RFC-2824: Call Processing Language Framework and Requirements APC-1887 Siemens AG H.450.12 - Common Information Additional Network Feature for H.323 APC-1888 Siemens AG M.3 - Tunneling of DSS1 in H.323 APC-1889 Q4/8 Voice/fax switching in draft H.323 Annex D v2 APC-1890 Q4/8 Facsimile related work on draft H.248 Annex F APC-1891 Q4/8 Draft T.38 Appendix V H.248 Call Establishment Procedure Examples APC-1892 Q4/8 Proposed Edits to H.248 Annex F APC-1893 PictureTel Proposed H.242/H.245 text for dynamicPictureResizingByFour APC-1894 ALCATEL Modification to H.323 annex H APC-1895 ETSI TIPHON WG8 Liaison statement subject: "H.235 Hybrid Security Profile" APC-1896 BT Use of the Generic Framework during Registration and other RAS Messaging APC-1897 BT Additional Data Types for GenericData APC-1898 BT Clarification on the Handling of Unknown conferenceGoals APC-1899 Lucent Technologies Fast Channel Open for H.245 APC-1900 Editor (P Reddy) H.246 Annex E.1 Interworking between H.225.0 and PLMN's Mobile Application Parts APC-1901 Editor (P Reddy) H.246 Annex E.2 Interworking between H.225.0 and ANSI-41 PLMN Mobile Application Part APC-1902 Intel H.323 Mobility services using IETF's Mobile IP and new extended protocols APC-1903 Editor (M Fortinsky) H.225.0 Annex G version 2 - draft ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC number for Portland
by Sakae OKUBO 07 Aug '00

07 Aug '00

Dear Mr. Fortinsky, >I have the following documents to submit for the Portland meeting: > >(1) APC-1796: H.225.0 Annex G version1 - with corrections > This document was submitted for the Osaka meeting, but was not >discussed due to time constraints. Understood. >(2) Please assign an APC number for the following document (which I will >then post to the pictel Incoming directory). > > Title - H.225.0 Annex G version 2 - draft > Source - Editor > This is an update to APC-1797 from Osaka, containing changes >discussed during the Osaka meeting. APC-1903 has been allocated to this contribution. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
by Roy, Radhika R, ALCOO 07 Aug '00

07 Aug '00

Hi, FX: Yes, it is OK for GK/BE <-> HLF/VLF (H.323 backend services protocol). But the questions remain for HLF <-> HLF. Thanks, Radhika R. Roy -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Thursday, August 03, 2000 11:04 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs roy, You're right, there is a new interface between the BE and the HLF, but it is in the "mobile domain", so I don't think it breaks anything. And we can have an HLF-HLF in a second step, but not today since we don't want to mandate anything new in the originationg domain. fx "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> on 02/08/2000 03:46:53 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Francois-Xavier DEROME/FR/ALCATEL) Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs Hi, FX: I like your approach that you have stated here in the email. With respect to the draft APC.xxx that you have proposed, I have few questions: 1. At present in H.323, there are mechanisms in place how the communications need to be made between the GKs or between the BEs or between the GK-BE and BE-GK when the user remain in one GK (or GK-BE) can communicate for resolving the information with another user located within another GK (or BE/GK). That is, the communication is made via the GK (or GK/BE) to locate another GK (or GK/BE) where is use is residing (for resolving information or placing a call). 2. The base H.323 spec and H.225.0 Annex G spec clearly provide those mechanisms as stated in item 1. However, your contribution appears to suggest that a GK (or BE) will use the VLF and HLF to locate another GK (or BE) where the user resides (currently). My assumption is that there can be HLF-to-HLF communications by-passing the GK-to-GK (or GK/BE-BE/GK) communications for resolving the information. It has been mentioned in my earlier emails that HLF-to-HLF communications is not an extension of H.323 protocol. Therefore, it appears to me that your contribution does not follow the model that have been suggested in items 1 and 2 per H.323 and Annex G. Am I missing anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Tuesday, August 01, 2000 5:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs I tried to follow your discussion on annex G. Can we split the problem in 2 parts : - the mobility management - the call control Concerning the mobility management, I think we can define the rules we want and there should be no restriction from the current annex G limitation. Concerning the call management, we MUST follow the current annex G and that's what I wanted to make clear in my APC. I think one solution could be for the BE in the mobile domain to put in the routeinfo field a sendAccessRequest to let him resolve the new location with the HLF fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.225 white draft
by Terry L Anderson 07 Aug '00

07 Aug '00

I am looking over the "GenericData" related fields in the ASN.1 and saw one asymmetry. Several commands (e.g., Alerting, ARQ, etc) contain featureSet FeatureSet OPTIONAL while Setup contains neededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, desiredFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, supportededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, which with the exception of the replacementFeatureSet BOOLEAN is exactly the contents of FeatureSet. Is there a reason for having these separately in Setup rather than having featureSet in Setup? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

3 4

Re: Important Portland Meeting Details & Late Fees
by Sebestyen Istvan ICN M CS 27 05 Aug '00

05 Aug '00

Dear Colleagues, please do sign up quickly. We can not leave Intel and ourselves "in the rain". Also attendies should please not go to stay elsewhere, if someone is thinking to do this, as again the meeting preparation plan of Intel collapses. If we get into difficulties, first people staying elsewhere should pay first the meeting fee. Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, 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.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/standards ---------------------------------------------------------------------------- ---------------- > ---------- > From: Meyer, Greg W[SMTP:greg.w.meyer@INTEL.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Friday, August 04, 2000 8:40 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Important Portland Meeting Details & Late Fees > Importance: High > > Q.11 - 15/16 Experts: > > Here's a few important details of the Portland meeting being held August > 21 > - 25. > > 1. The hotel will release the block of rooms on Monday, Aug 7th. We > currently have half of the projected number of participants registered. > This > creates a problem for both Intel and the unregistered participants. The > delay of registrations means that late-registrants may not get a room > (there's few, if any, alternatives in this remote location) and Intel is > liable for unused rooms. To avoid a meeting fee (due to the liability), we > ask that everyone register as soon as possible. Registrations after Aug > 7th > will incur a late-registration fee of $300, charged by the hotel upon > check-in. You may download the registration form from this URL: > http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip > > If you cannot download the form or have difficulties with faxing it, > please > send mailto:valeriex.nester@intel.com. A signed form will still be needed > but this will help avoid a late-registratin fee. Be sure to indicate your > check-in and check-out dates, which Question you will attend and how many > guests you will have attend the Event Dinner on Wednesday. > > 2. Several people have asked for true Kosher food. The hotel can arrange > for > a special delivery of Kosher if the meals are prepaid. Lunches are around > $16 and dinners around $30. Please contact Janine Voudrie > [Janine.Voudrie(a)theresort.com, +1-503-622-2221] with your requests and > payment information. Orders will need to be received by August 14th. > > Greg Meyer > Intel Corporation > mailto:greg.w.meyer@intel.com > +1.503.264.9506 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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