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

Re: [Fwd: CPL/323]
by Sakae OKUBO 21 Jul '00

21 Jul '00

Dear Mr. Anderson, >Couyld you give me another APC number for the second CPL document: > >Title: "RFC-2824: Call Processing Language Framework and Requirements" APC-1886 has been allocated to this document. 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

Comments on H.225.0 v4 Whitedraft (sourceAddress)
by Klaghofer Karl ICN EN HC SE 81 20 Jul '00

20 Jul '00

One more try, since it seems that my previous mail I sent out yesterday did not arrive. Regards, Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Klaghofer Karl ICN EN HC SE 81 > Gesendet am: Tuesday, July 18, 2000 12:02 > An: 'ITU-SG16(a)mailbag.cps.intel.com' > Betreff: Comments on H.225.0 v4 Whitedraft (sourceAddress) > > Rich and others, > > H.225.0v4 White draft, section 7.3.10 Setup reads: > "... > sourceAddress - Contains the alias addresses for the source; the dialed > digit string of the source is in the Q.931 Calling Party Number IE. The > primary address shall be first. > ..." > > PROPOSED TO BE CORRECTED TO: > "... > sourceAddress - Contains the alias addresses of the source. Note that the > E.164 Number of the source is contained within Calling Party Number > Information Element. The primary address shall be first. > ..." > > Background: > As part of the global v4 change to replace the term "e164" by the term > "dialedDigits" in the whole H.225.0 document, the sentense in current v4 > Whitedraft does not make sense anymore and should be corrected in v4 in > Portland. I think what we wanted to say is that the E.164 number is > contained within the Calling Party Number IE and not the dialed digit > string ! Dialed digit string (unstructured number which maybe may include > prefixes, etc would be put into sourceAddress.dialedDigits). > Note: There might be further sections where the simple replacement of the > term e164 by term dialed digits may have caused vagueness, since term e164 > in v2 was actually used for both - real E.164 but also unstructured digit > strings. > > Regards, > Karl Klaghofer > ------------------------------------------------------- > Karl Klaghofer, Siemens AG > Dpmt ICN EN HC D81, VoIP Architecture & Standardization > Hofmannstr. 51, 81359 Munich, Germany > Tel.: +49 89 722 31488; Fax.: +49 89 722 37629 > Mail: 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

2 1

SIP-H.323 Interworking Draft
by Roy, Radhika R, ALCOO 20 Jul '00

20 Jul '00

Hi, Everyone: We are now pleased to inform that the "SIP-H.323 Interworking Requirements" Internet-Draft has been completed. You can find the draft as follows: Title : SIP-H.323 Interworking Requirements Author(s) : H. Agrawal, R. R. Roy, V. Palawat, A. Johnston, C. Agboh, K. Singh, and H. Schulzrinne Filename : draft-agrawal-sip-h323-interworking-reqs-00.txt Pages : 19 Date : 12-Jul-00 Abstract: "This document describes the requirements for the logical entity known as the interworking function (IWF) that will allow the interworking between the SIP(Session Initiation Protocol) and H.323 networks." This draft is expected to be presented in the 48th IETF meeting in Pittsburgh, USA (July 31 - August 4, 2000) and may become an Informational RFC if no future comments are received. The next step is to produce the "SIP-H.323 Interworking" draft for producing an IETF RFC based on this requirement draft. Best regards, Radhika R. Roy AT&T

1 0

[H.323 Mobility:] Update to Service Definitions for Annex H
by Roelands Marc 20 Jul '00

20 Jul '00

Hi all, I uploaded the updated version of MD-102 to ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102a_ServiceDefi nitions.zip . (it contains change bars to mark the added text) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323v4 and Annex D
by Francois Audet 19 Jul '00

19 Jul '00

Francois, The bi-directional TCP support was added during the last Geneva meeting. No issues were raised in Osaka. If there are issues with it, hopefully people will find them before November! We could specify that H.323 use H.245v7-- I do not see any reason why we should not consider that option. The only reason that I did not increase the revision number is that Annex D may be implemented optionally. If somebody chooses to implement H.323v4 without Annex D support, there is nothing they would need from H.245v7. I have no problem with mandating v7 for H.323v4. It is a small editorial change: a "7" instead of a "6" ;^) However, it really makes no difference at all to me. I'll be agreeable with whatever the experts believes makes the most sense. Me too.

1 0

H.323v4 and Annex D
by Francois Audet 19 Jul '00

19 Jul '00

Hi all, H.323v4 Annex D refers to an H.245 codepoint (t38FaxTcpOptions) that is only present in H.245v7 and not in H.246v6. How do we fix this? I think it is too late to fix H.245v6 isn't it? The alternatives would be: * Require H.245v7 for H.323v4, instead fo H.245v6 * Pull out Annex D of H.323 and make it require a different version of H.245. (Extremely bad idea since the Annex has a lot of other useful material) * Pull out the bidirectional TCP thing we added on-the-spot at the last meeting. At least until the next revision. Any views? Am I missing something? Also, there is a reference to something called t38Capability in Annex D: it should be t38Fax. (This is editorial). ----- François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 <http://www.nortelnetworks.com/> http://www.NortelNetworks.com

2 1

Re: [H.323 Mobility:] Service Definitions for Annex H
by Roy, Radhika R, ALCOO 19 Jul '00

19 Jul '00

Hi, Everyone: Further along the line of service definitions, I like to draw your attention related to AT&T contributions submitted (D.353 and D.354) in the last February'00 (Geneva) meeting. We can also discuss some of the definitions provided there along with Siemens's and Intel's contributions. In this connection, I am enclosing the copy of D.353 only. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roelands Marc [mailto:Marc.Roelands@SIEMENS.ATEA.BE] Sent: Wednesday, July 19, 2000 3:37 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Service Definitions for Annex H Hi all, I have just uploaded MD-102 on Service Definitions for discussion, at ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102_ServiceDefin itions.zip . It is the first part of several Siemens/Intel inputs for the new chapter 5 for which input was requested in Osaka. I hope to send an updated/extended version still in a few days (i.e. before my holidays). (Since it is only a 19K file, I attach it here too.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be

1 0

[H.323 Mobility:] Service Definitions for Annex H
by Roelands Marc 19 Jul '00

19 Jul '00

Hi all, I have just uploaded MD-102 on Service Definitions for discussion, at ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102_ServiceDefin itions.zip . It is the first part of several Siemens/Intel inputs for the new chapter 5 for which input was requested in Osaka. I hope to send an updated/extended version still in a few days (i.e. before my holidays). (Since it is only a 19K file, I attach it here too.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be

1 0

Re: Request for an APC number
by Sakae OKUBO 19 Jul '00

19 Jul '00

Dear Rohit Gupta, >Is it possible to register a contribution to ITU-T SG16 for non-ITU >members? I wish to register > a contribution to suggest ammendments in the H.323 standard. > > Rohit Gupta > Hughes Software Systems > India Thank you for your contribution, to which APC-1885 has been allocated. 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

APC documents
by Sakae OKUBO 18 Jul '00

18 Jul '00

Dear Dale, APC-1884 has been allocated to your contribution: >"Decomposition of Gatekeeper Functions inside a Domain" source SONUS To other experts, please note the following contribution has been registered: >APC-1883 >Source: Columbia University >Title: CPL: A Language for User Control of Internet Telephony Services 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