- sg16-avd - lists.packetizer.com

Contributions APC-1984, APC-1985, APC-1986 uploaded
by Michael Fortinsky 31 Oct '00

31 Oct '00

The following contributions: APC-1984 editor (M. Fortinsky) H.225.0 Annex G Version2 Draft APC-1985 VocalTec Communications Ltd H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Ltd Clarifications Related to H.225.0 Annex G Service ID's have been uploaded to: ftp://standard.pictel.com/avc-site/Incoming/ Mr Okubo: could you please move them to the 0011_Gen directory? Thank you. 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

AW: fastStart element in all Q.931 messages up to and including C onnect
by Klaghofer Karl ICN EN HC SE 81 31 Oct '00

31 Oct '00

Paul, The clarifying text below as proposed by Francois looks good to me. It should be added to v4 in this way. Regards, Karl -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@packetizer.com] Gesendet am: Dienstag, 31. Oktober 2000 07:34 An: Francois Audet; 'Anatoli Levine'; Paul Long Cc: h323implementors(a)imtc.org Betreff: Re: fastStart element in all Q.931 messages up to and including C onnect Francois, You proposed the following textual changes (see enclosed in <NEW></NEW>): _____ The called endpoint accepts a proposed channel by returning the corresponding OpenLogicalChannel structure in a Q.931 message sent in response to Setup, up to and including Connect. <NEW>A called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect. Calling endpoints should react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.</NEW> _____ I don't have any problem inserting this text into H.323, but I do fear that people will rely on such repetitions and they may not happen. Indeed, I would state that an H.323 entity shall not expect more than one response to Fast Connect. I don't disagree with this text, because I always encourage developers to be very tolerant of "noise" on the wire-- and I consider repetitive data like this to be "noise". :-) You call these religious arguments... they might be, but we really need closure on this issue. Unlike the MGCP vs H.248 debates, the world can live with two media gateway control protocols. However, I don't want to see vendors split on implementation issues relating to H.323: that's not good for anybody at all. If we don't come to an agreement on it here and now, you know that we'll be correcting it as a customer fumes over interoperability issues later on. I'd much rather see us agree to something than to bring grief upon our customers. Can everyone live with the above textual changes? Do we need more? Is it well understood that there may be one and only one response containing fastStart? Paul

1 0

Contributions APC-1982 and 1983 uploaded
by Horvath Ernst 31 Oct '00

31 Oct '00

Dear all, contributions APC-1982 and APC-1983 have been uploaded to the incoming directory on the PictureTel site. These are the third drafts of Recs. H.450.10 (Call Offer) and H.450.11 (Call Intrusion). Both are proposed for determination at the forthcoming SG16 meeting. Best regards, Ernst Horvath Siemens AG ======================== Tel: +43 5 1707-45897 Fax: +43 5 1707-56992 Email: ernst.horvath(a)siemens.at ======================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Contribution APC-1995.zip uploaded
by John Segers 31 Oct '00

31 Oct '00

Dear all, A few minutes ago I uploaded my contribution APC-1995 to the incoming directory on the PictureTel site. Best regards, John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:] MD-110 uploaded (new messages to H.225 Anne x G)
by Jaakko Sundquist 31 Oct '00

31 Oct '00

Hi again Martin, My comments embedded & marked with [Jaakko:]. > > The other question I have concerns AuthenticationRejection: > > Why do you reverse tunnel - that is, feed back - > the tunneled > > message in the reject? > > Well, this was just a thought that maybe it would be > beneficial, if the > originating gatekeeper would receive the (presumably) > same message it has > tunneled, so that it can make sure that the message > indeed is the one it has > sent. On the other hand, since we are talking about > communications taking > place through a route of trusted parties (also > secured with H.235 methods), > maybe this kind of integrity check is unnecessary. > What do you think? > > Meu:> If the reverse tunnel is solely for security > purposes, then I do not consider this useful. As you said, > the entire authentication message including the tunneled > message is integrity protected on a hop-by-hop basis. Due to > the principle of chained trust in the security architecture, > the MT can be certain that the authentication message has not > been tampered in transit. As a conclusion, the reverse tunnel > does not make sense from a security point of view. [Jaakko:] I guess you're right. I'll take this away also. > > I thought, that the reverse tunnel were useful > perhaps for matching the confirmation with the request > message. But then, some simpler means than conveying the > entire message should be sufficient. [Jaakko:] I also thought about this, but came to the same conclusion that it should be the GK's responsibility to construct the GCF or RCF (or whatever) messages to be sent to the MT based on the information received in the AuthenticationConfirmation. > What about the following scenario: > Several MTs "attach" to the same GK. All these MTs > are subscribed to the same AuF. Thus, the GK has several > outstanding AuthenticationRequests issued for each MT. How > does the GK associate the related AuthenticationConfirmation then? [Jaakko:] The purpose of the destinationInfo field is to indicate to which User's authentication the message is related. Now, thinking of this, I think the field shouldn't be optional, so I'll make a correction here also. > > Finally a general question: > > Once there was a discussion that Annex G not only be used > > among Border elements as currently defined in the > H.225 Annex > > Gv1 scope, but to extend its usage for mobility purposes. If > > this were true, then Annex G could be applied also between > > the GK-VLF/BE and between HLF/BE-AuF. What is the current > > status of that discussion? > > I guess this issue hasn't been throughly discussed > yet. My personal opinion > is that we should extend the usability of the H.225 > Annex G protocol also to > other functional entities besides the BE. On the > other hand, I would be > quite happy also, if we would limit the first version > of H.323 Annex H by > not handling all the interfaces in the architecture > diagram and concentrate > on the VLF - HLF -interface (with or without BEs) > instead. The reason for > the latter argument is that I would assume that > implementors might be quite > happy with co-located functional entities so that > they would have a > GK/VLF/BE and HLF/AuF/BE elements, thus necessitating > only the mentioned > VLF/BE - HLF/BE network interface. > > Meu>: this could simplify things a lot! I'll include the proposition for only defining this one interface in the first version of the annex in my contribution "Changes to H.323 Annex H". Thanks again for the mails, this discussion has rendered the contribution much better already. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: Fast Connect - Switching to H.245 procedure / UII vs. Keypad IE
by Dan Davidson 31 Oct '00

31 Oct '00

(This mail is a fusion of two previously separated streams: Fast Connect - Switching to H.245 procedure and UII vs. Keypad IE) Paul, All this would mean that when using fast connect to set-up a call against and IVR (i.e. calls in which DTMF are sent immediately after call set-up), H.245 UII messages shall be used for DTMF transport and the first H.245 UII message has to be preceded by Capability Exchange and Master Slave Determination procedures. Isn't this slow ( and I'm not counting in all the TCP connection set-up when tunnelling is not supported)? Isn't there a faster, standardised, way to convey DTMF when using fast connect ? Thanks, Dan -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, October 31, 2000 7:59 AM To: Dan Davidson; h323implementors(a)imtc.org Subject: Re: UII vs. Keypad IE Dan, An endpoint that communicates with a SET device may certainly do this-- and must if they expect to get DTMF digits from a SET device. However, two non-SET devices should not use this method. As far as I know, there is no means of signaling to the other endpoint that you have the "capability" of using the keypad IE. That means that any non-SET device must use UII. That might be something worth considering as a means of removing further dependencies on H.245. We could very easily add such support and signal it within H.225.0. However, I have seen no proposals for that. Paul -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, October 31, 2000 7:59 AM To: Dan Davidson; h323implementors(a)imtc.org Subject: Re: Fast Connect - Switching to H.245 procedure Dan, There's nothing hidden there. Essentially, this text is re-enforcing the idea that Fast Connect does not somehow bypass any of the H.245 messages (except that channels are opened). When starting H.245, you send the H.245 terminal capability set and the master/slave determination messages as appropriate. Paul ----- Original Message ----- From: "Dan Davidson" <dan.davidson(a)commatch.com> To: <h323implementors(a)imtc.org> Sent: Monday, October 30, 2000 2:38 PM Subject: Fast Connect - Switching to H.245 procedure > > The H.323v2 Recommendation describes the Fast Connect procedure and mentions > that if necessary, a H.245 connection can be established. > > It also mentions: " When H.245 procedures are activated, all mandatory > procedures of > H.245 that normally occur upon initiation of an H.245 connection shall be > completed prior > to initiation of any additional H.245 procedures." > > Question: What are the H.245 mandatory procedures the recommendation refers > to ? > > Dan > > -------------------------------------------------------------------------- - > ------------------------------ > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > subscribe or unsubscribe from this list > ------------------------------ > -------------------------------------------------------------------------- - >

1 0

AW: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
by Euchner Martin 31 Oct '00

31 Oct '00

Jaakko, Thanks for your answers. Please see my comments marked with meu:> below. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: jaakko.sundquist(a)nokia.com [SMTP:jaakko.sundquist@nokia.com] Gesendet am: Dienstag, 31. Oktober 2000 09:12 An: Martin.Euchner(a)icn.siemens.de; ITU-SG16(a)mailbag.cps.intel.com Betreff: RE: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G) Hi Martin, See my comments embedded. > Hi Jaakko, > > I'm not certain, whether I really understand the purpose of > the EncryptionToken. > If I look at Annex G v1, H.235 Clear and CryptoTokens are > always present in each Annex G message; they are conveyed > within AnnexGCommonInfo and thus are already part of each > annex G message. Thus, I would say, that EncryptionToken is > somewhat redundant and we do not need that this way. You're quite right, the encryptionToken certainly seems unnecessary, thus I'll take it away from the contribution. Meu> ok. Thanks. > > The other question I have concerns AuthenticationRejection: > Why do you reverse tunnel - that is, feed back - the tunneled > message in the reject? Well, this was just a thought that maybe it would be beneficial, if the originating gatekeeper would receive the (presumably) same message it has tunneled, so that it can make sure that the message indeed is the one it has sent. On the other hand, since we are talking about communications taking place through a route of trusted parties (also secured with H.235 methods), maybe this kind of integrity check is unnecessary. What do you think? Meu:> If the reverse tunnel is solely for security purposes, then I do not consider this useful. As you said, the entire authentication message including the tunneled message is integrity protected on a hop-by-hop basis. Due to the principle of chained trust in the security architecture, the MT can be certain that the authentication message has not been tampered in transit. As a conclusion, the reverse tunnel does not make sense from a security point of view. I thought, that the reverse tunnel were useful perhaps for matching the confirmation with the request message. But then, some simpler means than conveying the entire message should be sufficient. What about the following scenario: Several MTs "attach" to the same GK. All these MTs are subscribed to the same AuF. Thus, the GK has several outstanding AuthenticationRequests issued for each MT. How does the GK associate the related AuthenticationConfirmation then? What do you think? > Finally a general question: > Once there was a discussion that Annex G not only be used > among Border elements as currently defined in the H.225 Annex > Gv1 scope, but to extend its usage for mobility purposes. If > this were true, then Annex G could be applied also between > the GK-VLF/BE and between HLF/BE-AuF. What is the current > status of that discussion? I guess this issue hasn't been throughly discussed yet. My personal opinion is that we should extend the usability of the H.225 Annex G protocol also to other functional entities besides the BE. On the other hand, I would be quite happy also, if we would limit the first version of H.323 Annex H by not handling all the interfaces in the architecture diagram and concentrate on the VLF - HLF -interface (with or without BEs) instead. The reason for the latter argument is that I would assume that implementors might be quite happy with co-located functional entities so that they would have a GK/VLF/BE and HLF/AuF/BE elements, thus necessitating only the mentioned VLF/BE - HLF/BE network interface. Meu>: this could simplify things a lot! Thanks for the mail, it was very useful. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:] MD-110 uploaded (new messages to H.225 Anne x G)
by Jaakko Sundquist 31 Oct '00

31 Oct '00

Hi Martin, See my comments embedded. > Hi Jaakko, > > I'm not certain, whether I really understand the purpose of > the EncryptionToken. > If I look at Annex G v1, H.235 Clear and CryptoTokens are > always present in each Annex G message; they are conveyed > within AnnexGCommonInfo and thus are already part of each > annex G message. Thus, I would say, that EncryptionToken is > somewhat redundant and we do not need that this way. You're quite right, the encryptionToken certainly seems unnecessary, thus I'll take it away from the contribution. > > The other question I have concerns AuthenticationRejection: > Why do you reverse tunnel - that is, feed back - the tunneled > message in the reject? Well, this was just a thought that maybe it would be beneficial, if the originating gatekeeper would receive the (presumably) same message it has tunneled, so that it can make sure that the message indeed is the one it has sent. On the other hand, since we are talking about communications taking place through a route of trusted parties (also secured with H.235 methods), maybe this kind of integrity check is unnecessary. What do you think? > Finally a general question: > Once there was a discussion that Annex G not only be used > among Border elements as currently defined in the H.225 Annex > Gv1 scope, but to extend its usage for mobility purposes. If > this were true, then Annex G could be applied also between > the GK-VLF/BE and between HLF/BE-AuF. What is the current > status of that discussion? I guess this issue hasn't been throughly discussed yet. My personal opinion is that we should extend the usability of the H.225 Annex G protocol also to other functional entities besides the BE. On the other hand, I would be quite happy also, if we would limit the first version of H.323 Annex H by not handling all the interfaces in the architecture diagram and concentrate on the VLF - HLF -interface (with or without BEs) instead. The reason for the latter argument is that I would assume that implementors might be quite happy with co-located functional entities so that they would have a GK/VLF/BE and HLF/AuF/BE elements, thus necessitating only the mentioned VLF/BE - HLF/BE network interface. Thanks for the mail, it was very useful. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC number
by Sakae OKUBO 30 Oct '00

30 Oct '00

Dear Mr. Jones, Ms. Levin, Mr. Bowen, In response to your request, APC numbers have been allocated to your contributions as attached. This would be an almost final list of contributions to the 9-10 November Rapporteur meeting. 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 *********************************************************** Documents of the Q.12-14/16 Geneva meeting (9-10 November 2000) APC-1950 SG11 (Q.BIC/11) Liaison To SG 12, SG 13 And SG 16 Asking For Guidance On Quality Of Services to be Supported with the BICC Protocol APC-1951 Study Group 11 BICC Special Rapporteurs Liaison to SG 16 proposing some additional clarifications in the H.323 Implementers Guide for H.246 Annex C. APC-1952 SG 11 Joint Special Rapporteurs for BICC Support of directionality in "H.248 Annex K - Announcement Package" APC-1953 Accord Networks Support bi directional channels in annex C fast start APC-1954 Lucent Technologies, NTT DoCoMo H.324 Annex C multimedia call package for H.248 APC-1955 NTT DoCoMo, NEC Identification of references to IETF Documents in H.225.0 version 4 (per Recommendation A.5) APC-1956 Oki Electric Adding ServiceControl fields to LCF/LRJ APC-1957 Editor (P Jones) H.323 Implementor's Guide APC-1958 Editor (P Jones) H.323 v4 APC-1959 Editor (O Levin) H.323 Annex O Draft APC-1960 Lucent Technologies Proposal to create an SDL representation of H.248 APC-1961 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding Section B.4.3 APC-1962 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the password and shared secret APC-1963 Editor (M Euchner) Clarification on the use of sendersID and generalID in white Draft H.235 Version 2 APC-1964 Editor (M Euchner) REVISED ITU-T RECOMMENDATION H.235 VERSION 2 - SECURITY AND ENCRYPTION FOR H-SERIES (H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS - CORRECTED VERSION FOR DECISION APC-1965 Editor (M Euchner) Draft H.235 Version 3 - Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 Editor (M Euchner) Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 Editor (M Euchner) Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 Mobile Environments" APC-1968 Editor (T Anderson) Draft H323 Annex R APC-1969 Editor (P Jones) Editorial and Technical Corrections to H.323v4 APC-1970 Cisco Systems Signalling of ingress and egress Carrier/Circuit Identifier information in H.225.0 Messages and Annex G Messages APC-1971 Cisco Systems Third Party Re-routing of a Fast Connect Initiated Call APC-1972 Cisco Systems Ported Number Indications in H.225.0 messages APC-1973 Cisco Systems Reserving Resources for Calls APC-1974 Editor (R Callaghan) H.450.12 - Common Information Additional Network Feature for H.323 APC-1975 Editor (R Callaghan) H.323 Annex M.3 - Tunneling DSS1 in H.323 APC-1976 Siemens H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture APC-1977 Siemens Deficiencies of H.225.0 for a native transport of DSS1 APC-1978 AT&T Mobility Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1979 AT&T Application Layer QOS Signalling Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1980 AT&T Common Value Added Intelligent Backend Services (BES) Protocols for all Applications APC-1981 Editor (K Klaghofer) Editorial comments to H.450.9 White document (COM16-117E) APC-1982 Editor (K Klaghofer) H.450.10 Call Offer Supplementary Service for H.323 APC-1983 Editor (K Klaghofer) H.450.11 Call Intrusion Supplementary Service for H.323 APC-1984 Editor (M Fortinsky) H.225.0 Annex G version 2 APC-1985 VocalTec Communications H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Clarifications Related to H.225.0 Annex G Service ID's APC-1987 Editor (F Audet) H.323 Annex M.1 - QSIG tunnelling APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 APC-1990 Comverse Network Systems H.225.0 Annex G v2: support for Service Zone APC-1991 Comverse Network Systems H.225.0 v4: Enhancing SupportedProtocols to indicate video APC-1992 Siemens {to be advised} APC-1993 Siemens {to be advised} APC-1994 Siemens {to be advised} APC-1995 Lucent Technologies Issues for H.248 implementors' guide APC-1996 Nortel Networks Proposed corrections to H.323v4 Annex D on T.38 fax switchover APC-1997 Editor (C Groves) Draft H.248 Implementors' Guide APC-1998 Editor (C Groves) Draft H.248 Annex K - Generic Announcement Package APC-1999 Editor (C Groves) Draft H.248 Annex L - Error Code and Service Change Reason Description APC-2000 Ericsson H.248 Annex x - Load Control Package APC-2001 Ericsson Direction in H.248 annex K APC-2002 Ericsson Signal on Root for H248v2 APC-2003 France Telecom Mobility management protocol in H.323 Annex H APC-2004 Editor (M Buckley) Latest Draft of Annex N of H.323 APC-2005 Lucent Technologies Transport QoS Parameters and Traffic Descriptor for QoS Characterisation in H.323 systems APC-2006 Editor (M Buckley) Latest draft of TIPHON DTS05003 "End to End Quality of Service Control and Signalling in TIPHON Systems" APC-2007 Editor (A Heidermark) Editorial changes to Annex H to H.248 APC-2008 Editor (A Heidermark) Editorial changes to Annex I to H.248 APC-2009 LM Ericsson Use of Call Independent Signalling for Service Control APC-2010 Nortel Networks Use of inband tones in H.323 using special RTP payload types APC-2011 Editor (J Sundquist) H.323 Annex H Draft APC-2012 Nokia New messages to the H.225 Annex G protocol APC-2013 Nokia Changes to the H.323 Annex H APC-2014 Korea Telecom Comment to H.323 Annex K APC-2015 Korea Telecom A Procedure for Multimedia Mail Service APC-2016 NTT DoCoMo Support of HTTP in H.324 APC-2017 Nokia Comparison of 3GPP All IP and H.323 Annex H architectures APC-2018 UCLA, Samsung Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-2019 UCLA, Samsung Proposals for H.323 Annex I APC-2020 France Telecom Support of a direction indication in the generic announcement package APC-2021 France Telecom Proposed package for data transmission over analog lines APC-2022 Editor (D Wolfstein) H.323 Annex P Draft (modem relay over H.323) APC-2023 Cisco Number Portability Release Cause Code APC-2024 Cisco TRIP Contribution for Annex O/H.323 APC-2025 RADVision Remarks on the scope of H.323 Annex L APC-2026 Editor (R Bowen) Draft H.225.0 v4 ---------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC- Number Request
by Louis Fourie 30 Oct '00

30 Oct '00

Mr. Okubo, Please allocate an APC-number for me for the following contribution: "Number Portability Release Cause Code" - as a Cisco contribution Thanks in advance. - Louis Fourie Cisco Systems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0