- sg16-avd - lists.packetizer.com

Re: H.323 Annex E optional?
by Manoj Paul 31 Jul '99

31 Jul '99

> Paul, > > Okay, but what if the EP does not indicate that it has this capability? > 7.9.2/H.225.0v3 currently says that the EP _shall_ use an unreliable channel > if in receipt of an RCF with useAnnexECallSignalling set to TRUE. Period. > Regardless of whether the endpoint indicated the capability in its RRQ. The > following would eliminate the ambiguity and possible misunderstanding: > > 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE and > supportsAnnexECallSignalling was set to TRUE in the RRQ to which this > message is in response, the endpoint receiving this message shall use call > signaling exclusively on an unreliable transport channel as described in > H.323 Annex E when placing calls." Doesn't it mean that Gk can not adopt direct call routed model between endpoints. Consider when the remote endpoint is not Annex E Compliant. Now Ep1 sends call signalling messages *only* over UDP (after receiving useAnnexECallSignalling = TRUE in RCF). This direct routed call will not go through as Ep2 is not Annex E compliant. Should Ep1 look into the callModel in ACF to figure out if it is Gk/direct routed call. If Gk routed and useAnnexECallSig = TRUE, do only UDP call signalling, and if direct routed, use Annex E Mixed TCP and UDP procedures ? -M.Paul.

2 1

FW: MegacoHGCP9 is posted
by Nancy-M Greene 30 Jul '99

30 Jul '99

fyi. -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Brian Rosen[SMTP:brosen@ENG.FORE.COM] > Sent: Friday, July 30, 1999 10:21 PM > To: megaco(a)standards.nortelnetworks.com > Subject: MegacoHGCP9 is posted > > I have received very few comments on Wednesday evening's > draft. MegacoHGCP9.pdf is available at: > ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/MegacoHGCP9.pdf > It has the following changes: > > 1. Abdallah Rayhan and his colleagues at Nortel Networks > have been furiously putting together a real parser while I'm > merrily changing the syntax. They have provided some updates > that make the grammar consistent, error free and presumably > more regular. While the changes do in fact modify the syntax, > they should not introduce any semantic changes except as noted. > > A summary of changes are: > some spelling errors were corrected > several places where I had made commas optional were > put back to requiring commas > several places where parameters should have been optional > were fixed so that they were optional > several ABNF rule construction errors were fixed > a change was made in eventParameter to fix a syntax > ambiguity > an error where SignalsDescriptor had a RequestID was fixed > an option to return an error from Transaction was added > > 2. Time Notation is changed per Chris Ross' suggestion > > 3. Nancy Greene from Nortel Networks has updated the examples > They are believed to be reasonably consistent with the current grammar. > > 4. I have clarified wording to expressly state that a Termination can > only exist in one Context at a time. > > 5. I have clarified wording in termination Mode to state that > send/receive is with respect to the Termination. A Termination in Send > mode can only talk, it cannot listen. > > 6. Text on the local, tx and rx descriptor was replaced/reworded, and > Mode text was restored/relocated to the Local descriptor section. > > A new Internet Draft referencing this pdf has been submitted, > and will be announced in a few days. > > For those attending the SG16 Berlin meeting, there will be a hard copy > of this draft, with change bars from APC-1610 available. A zipped > version of the pdf and doc files is also on the ftp site for your > use. Please note that files with "itu" in the file name have the ITU > headers and some extra text not in the IETF version (the macros were > invoked to show ITU text). > > I thank all of the people who have contributed to this editing process. > Other than the missing text on defining packages that should be > available very soon, and the separate document with the default > packages, I feel that the document is getting very close to > last call quality. > > Any further review you would care to do would be most welcome. > Feature requests will probably be discouraged. > > Brian Rosen, Editor > ------------ > Brian Rosen, Principal Engineer > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > (724) 742-6826 mailto:brosen@eng.fore.com >

1 0

IMTC Mobility, CoIP, iNOW! - joint session
by senthil.sengodan＠nokia.com 30 Jul '99

30 Jul '99

Folks: My apologies if you've received multiple copies of this email. Due to the synergy that the IMTC CoIP, iNOW! and Mobility groups have in the H.323 space, it is intended to have a joint session between these groups (in addition to any individual sessions) during SuperOP in September. If anyone is interested in making a presentation during this joint meeting, please let me know. In the mobility area, it is foreseen that the agenda would cover: 1) An overview of mobility efforts in other standards bodies - specifically ETSI TIPHON & ITU-T SG16. 2) A possible contribution/discussion on a mobility model based on H.323. 3) A possible discussion on the security aspects involved in mobility. If anyone would like to see any other specific area being addressed or would like to contribute to any of these areas, please let me know. - Senthil Sengodan Co-chair, IMTC Mobility AG

1 0

Address Change Assistance Required
by Matthew Sickles 30 Jul '99

30 Jul '99

Why are you getting this message? Recently Nortel Networks changed the domain name to nortelnetworks.com. As a result of this change, mailing lists are consistently sending mail to some of our older domain addresses. In an attempt to reduce the mail volume to these legacy domains, we are trying to contact the administrators for list-servers for assistance. What can you do? If you could please review your address databases and change the addresses that have the following domain names to nortelnetworks.com: nt.com nortel.com nortel.ca bnr.ca bnr.co.uk nortel.ie northern.co.uk nortel.co.uk Why should you assist us? Beginning in October we will start sending an NDR (non-delivery report) for all messages sent to older domains. In preparing ahead of time, we can prevent hundreds and thousands of messages from being sent to an incorrect address. What if you do not find any addresses in your database? Please disregard this message. If in future mailings you keep getting messages from me and you are annoyed, please contact me and we can work out these issues one-on-one. What if you find older Nortel Networks domains in your database? Thank you so much for your assistance, send me an e-mail with the list of addresses and I will forward you a Thank You Gift from Nortel Networks for your assistance. We appreciate your help and always appreciate the co-operation of postmasters, mailing-list and list-server administrators. Sincerely, Matthew W. Sickles Sr. Project Manager Nortel Networks Messaging Service _____ Matthew W. Sickles Nortel Networks 919.303.6656 [ESN] 455.6656 [voice] 919.303.8850 [ESN] 455.8850 [fax]

1 0

Re: H.323 Annex E optional?
by Paul Long 30 Jul '99

30 Jul '99

Paul, Okay, but what if the EP does not indicate that it has this capability? 7.9.2/H.225.0v3 currently says that the EP _shall_ use an unreliable channel if in receipt of an RCF with useAnnexECallSignalling set to TRUE. Period. Regardless of whether the endpoint indicated the capability in its RRQ. The following would eliminate the ambiguity and possible misunderstanding: 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE and supportsAnnexECallSignalling was set to TRUE in the RRQ to which this message is in response, the endpoint receiving this message shall use call signaling exclusively on an unreliable transport channel as described in H.323 Annex E when placing calls." Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 7/29/99 8:58 PM Subject: Re: H.323 Annex E optional? Paul, The endpoint does not indicate a preference-- it is to indicate capability. The gatekeeper may force an endpoint to use Annex E by setting the flag in the RCF. Paul ----- Original Message ----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, July 27, 1999 7:53 PM Subject: H.323 Annex E optional? > Is H.323 Annex E optional? H.225.0 says that an EP can indicate in an RRQ > (and a GK, in an LCF) whether it supports H.323 Annex E (call-signaling over > an unreliable channel), so Annex E is apparently optional. For example, > > 7.9.1/H.225.0v3: "supportsAnnexECallSignalling - If TRUE, this indicates > that the sender of this message is capable of call signalling [sic] on an > unreliable transport channel as described in H.323 Annex E." > > However, H.225.0 also says that via an RCF or ACF a GK can force an EP to > use Annex E. For example, > > 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE, this parameter > indicates that the endpoint receiving this message shal [sic] use call > signalling [sic] exclusively on an unreliable transport channel as described > in H.323 Annex E when placing calls." > > There is nothing in the Recommendations that requires a GK to abide by the > EP's capabilities. Is this an oversight, or does the EP merely indicate in > its RRQ a preference for supporting Annex E, and it must therefore support > this Annex? >

2 1

H.323 Annex E optional?
by Paul Long 29 Jul '99

29 Jul '99

Is H.323 Annex E optional? H.225.0 says that an EP can indicate in an RRQ (and a GK, in an LCF) whether it supports H.323 Annex E (call-signaling over an unreliable channel), so Annex E is apparently optional. For example, 7.9.1/H.225.0v3: "supportsAnnexECallSignalling - If TRUE, this indicates that the sender of this message is capable of call signalling [sic] on an unreliable transport channel as described in H.323 Annex E." However, H.225.0 also says that via an RCF or ACF a GK can force an EP to use Annex E. For example, 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE, this parameter indicates that the endpoint receiving this message shal [sic] use call signalling [sic] exclusively on an unreliable transport channel as described in H.323 Annex E when placing calls." There is nothing in the Recommendations that requires a GK to abide by the EP's capabilities. Is this an oversight, or does the EP merely indicate in its RRQ a preference for supporting Annex E, and it must therefore support this Annex?

2 1

APC-1629
by Tom-PT Taylor 29 Jul '99

29 Jul '99

I'm sorry, I think it best if I withdraw APC-1629. It has a fair amount of new material, which I think I should expose to my IETF colleagues for a first opinion before sending on to SG 16. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Re: IEEE 802.11 Wireless LAN in Berlin
by Dr. Stephan Wenger 29 Jul '99

29 Jul '99

Jo, postest Du das bitte noch in itu.adv.video und Q.11 reflector? Danke. IStar ziert sich, bin noch dran. Mfg StW -----Original Message----- From: Joerg Ott <jo(a)INFORMATIK.UNI-BREMEN.DE> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Donnerstag, 29. Juli 1999 18:14 Subject: IEEE 802.11 Wireless LAN in Berlin >Dear meeting participants, > >we will have at least one access point for the IEEE 802.11 wireless >LAN (frequency hopping) available -- so the PCMCIA cards you may have >used at/bought for the last IETF should work. Cards are available >from e.g. BreezeCom and Symbol Technologies (at least those were proven >to work at the IETF). > >Also a quick reminder for folks who still need wires: do not forget to >bring your twisted pair cables... > >See you in Berlin, >Joerg >

1 0

IEEE 802.11 Wireless LAN in Berlin
by Joerg Ott 29 Jul '99

29 Jul '99

Dear meeting participants, we will have at least one access point for the IEEE 802.11 wireless LAN (frequency hopping) available -- so the PCMCIA cards you may have used at/bought for the last IETF should work. Cards are available from e.g. BreezeCom and Symbol Technologies (at least those were proven to work at the IETF). Also a quick reminder for folks who still need wires: do not forget to bring your twisted pair cables... See you in Berlin, Joerg

1 0

FW: version 8 of Megaco/H.248
by Nancy-M Greene 29 Jul '99

29 Jul '99

Glen Freundlich has uploaded APC-1610, which is the changes to Megaco/H.248 proposed by IETF Megaco. Work has still continued on the draft this week, so we will have a paper copy of the latest version of the draft for discussion in Berlin. The document has not changed much - the differences are a clean up of the proposed ABNF and the Example Use Cases. I have been reworking the Example Use Case section to ensure that it works with the proposed ABNF. I would like to go through this section with anyone interested in Berlin. The paper copy brought in will be the draft put out July 30th. Below is a URL to the draft put out July 28th. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Thursday, July 29, 1999 5:26 AM > To: 'megaco(a)standards.nortelnetworks.com' > Subject: version 8 of Megaco/H.248 > > I have uploaded Brian Rosen's version 8 of the MegacoHgcp protocol > document - .pdf and .doc versions. > > One more version will go out Friday July 30th.There will be paper copies > of this version at the Berlin SG16 meeting. At least one change in the > July 30th version will be an update of the example use cases so they match > the ABNF. These can then be discussed in Berlin. > > ***If you have problems downloading these files, please contact Brian > Rosen (brosen(a)eng.fore.com) or Tom Taylor (taylor(a)nortelnetworks.com) > > Filenames: > MegacoHGCP8.zip (which is a zip of the pdf and doc version of the the > protocol) > MegacoHGCP8.pdf (which is the pdf version) > > URL: > > ftp://standards.nortelnetworks.com/megaco/docs/Oslo99 > > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

Re: H.245v6?
by mike.nilsson＠BT.COM 29 Jul '99

29 Jul '99

Paul, There has been no drastic jump in version numbers for H.245. Version 5 was approved in Chile, and is available at ftp://standard.pictel.com/avc-site/9905_San/h245_i.zip Version 6 was determined in Chile. The additions relative to the decided version 5 are given in TD69(PLEN), TD14(PLEN), TD22(PLEN), TD24(PLEN) of the Chile meeting. These are available from the ITU ftp site. I have attached a zip file containing these for convenience. Best regards Mike Nilsson <<H245_V6_DET.zip>> ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: Tuesday, July 27, 1999 6:53 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.245v6? > > H.323v3 references H.225.0v3 and H.245v6, but I cannot find even a draft > of > H.245v6. Anybody know where it is? Also, why the drastic jump in H.245 > versions? > > Paul Long > Smith Micro Software, Inc.

2 1

Re: Question on use of Disconnect and Release
by Francois Audet 28 Jul '99

28 Jul '99

> Joe, > > I have a question on APC-1623. > > If memory serves me right, Q.2931 uses only Release and > Release Complete, > i.e. > > > ---- Release ----> > <--- Release Complete ---- > > As I am conscious of the numbers of messages flying around I > was wondering > if this is sufficient and this would be a better way to go. This is correct: contrary to Q.931, Q.2931 does not use a DISCONNECT message.

1 0

Re: APC-1630 ("SDP Encoding for H.248") uploaded/enclosed
by Pete Cordell 28 Jul '99

28 Jul '99

Chip, A quick question,... With your encoding is there a convenient way to find parameters after the SDP without parsing the entire SDP message? Similarly, what rule do you use to decide whether you are starting to parse a new SDP message? Do you look for a new v=0 line, or is there an empty line? Or are these sorts of details not relevant at this time? Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Chip Sharp <chsharp(a)CISCO.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 28 July 1999 05:23 Subject: APC-1630 ("SDP Encoding for H.248") uploaded/enclosed >I have uploaded APC-1630 for potential consideration at the upcoming >rapporteur's meeting. It is also enclosed below. > >Warning: This contribution is text encoded. ;-) >Chip > >------------------------------------------------------------------ >| | >| ITU Telecommunication Standardization Sector Document APC- 1630 | >| Study Group 16 | >| Q.12-14/16 Rapporteur Meeting 27 August, 1999| >| Berlin, 2-6 August 1999 | >| | >| SOURCE*: Cisco Systems, Inc. | >| TITLE : SDP Encoding for H.248 | >| PURPOSE: Proposal | >| | >| _________________________ | >| | >| | >| | >| *Contact: Chip Sharp, chsharp(a)cisco.com | > ------------------------------------------------------------------ > >Abstract: >The use of SDP encoding has been proposed for H.248. This >contribution proposes the following: > >1) The SDP encoding that has been proposed since the March >compromise should be maintained at least as an option. > >2) The encodedparameter should refer to RFC2327 for the SDP encoding. > >3) The package names and event names should be text encoded and >registered with IANA for extensibility. > >4) An IANA considerations section needs to be added to provide >guidelines for registering with IANA. > > >Session Description Protocol: >--------------------------- >The Session Description Protocol (SDP) is described in RFC2327 >(ftp://nis.nsf.net/internet/documents/rfc/rfc2327.txt) It is a >standards-track protocol in the IETF. Refer to the current edition of >the "Internet Official Protocol Standards" (STD 1, >ftp://ftp.isi.edu/in-notes/std/std1.txt) for the standardization state >and status of this protocol. > >From the abstract of RFC2327: > "SDP is intended for describing multimedia sessions for the > purposes of session announcement, session invitation, and > other forms of multimedia session initiation." > >SDP Proposal: >------------ > >The encodedDescriptor should maintain the option for SDP encoding. > >The encodedDescriptor production should be changed to: > >encodedDescriptor = (SDPToken COMMA *SDPinformation) | > (H245Token COMMA quotedOctetString ) | > (extensionParameter COMMA quotedOctetString ) > >Add the following production: > >SDPinformation = announcement ;Normative: <announcement> is > ;defined in Appendix A of RFC2327 > >In addition, an extension mechanism should be defined. It is >recommended that a similar mechanism to that defined in >http://search.ietf.org/internet-drafts/draft-huitema-megaco-mgcp-v1- >00.txt be used. > > >Package and Event Proposal: >-------------------------- >Various Packages are currently being defined for H.248. It is >expected that a certain number of packages will be included in the >base standard. However, it is also expected that more packages will >need to be defined as more applications are defined. > >This contribution recommends that the package names and event names be >text acronyms that are registered with IANA. This will allow new >packages and events to be added in an extensible manner. > >This mechanism is already used for many applications on the Internet. >For example, MIME types are registered with IANA. This practice >allows extensions to the base capabilities without having to rev the >base specification every time a new capability is added. > >The ITU in general and SG16 in particular already have established >precedence in using IANA registration in ITU Recommendations. This is >a well-established practice in SG16. All the TCP/UDP ports used in >the H.323 series recommendations are registered with IANA. Therefore, >there should be no procedural problem with using IANA registration. > >The following text should be added: > >In Section 7.2.2.6 Packages, add the following sentence: >"Package names, referred to in this document as PackageName, will be >registered with IANA." > >The following changes should be made to the packageName and >eventParameterName productions: > >packageName = NAME ;Normative - The values this production takes are > ; registered with IANA as defined in Section ??? > > >eventParameterName = NAME ;Normative - The values this production takes are > ; registered with IANA as defined in Section ??? > > > >A Section should be added defining the guidelines for registering events and >packages with IANA. > >For example, the following text could be used (taken from SIP): >" When registering a new SIP option, the following information MUST be > provided: > > o Name and description of option. The name MAY be of any length, > but SHOULD be no more than twenty characters long. The name > MUST consist of alphanum (See Figure 3) characters only; > > o Indication of who has change control over the option (for > example, IETF, ISO, ITU-T, other international standardization > bodies, a consortium or a particular company or group of > companies); > > o A reference to a further description, if available, for > example (in order of preference) an RFC, a published paper, a > patent filing, a technical report, documented source code or a > computer manual; > > o Contact information (postal and email address); > >This procedure has been borrowed from RTSP [4] and the RTP > AVP [26]." > >However, this is not sufficient. Guidelines similar to those defined in >RFC2327 should be developed. > > >CONCLUSION >---------- > >In conclusion: >1) The SDP encoding that has been proposed since the March >compromise should be maintained at least as an option. > >2) The encodedparameter should refer to RFC2327 for the SDP encoding. > >3) The package names and event names should be text encoded and >registered with IANA for extensibility. > >4) An IANA considerations section needs to be added to provide >guidelines for registering with IANA. > > > >-------------------------------------------------- >Chip Sharp Consulting Engineering >Cisco Systems Telco Bio-region >Reality - Love it or Leave it. >-------------------------------------------------- >

2 1

Question on use of Disconnect and Release
by Pete Cordell 28 Jul '99

28 Jul '99

Joe, I have a question on APC-1623. If memory serves me right, Q.2931 uses only Release and Release Complete, i.e. ---- Release ----> <--- Release Complete ---- As I am conscious of the numbers of messages flying around I was wondering if this is sufficient and this would be a better way to go. I've included a picture in the attachment. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

Opening HTTP channels
by Pete Cordell 28 Jul '99

28 Jul '99

Espen, I read your contribution about using HTTP to control services with great interest. I have been meaning to write such a proposal myself. My approach differed from yours though. I was primarily thinking of opening HTTP channels using H.245. (However, I can see the use for HTTP in the call signalling, although I would prefer the signalling to be done using the generic package scheme that I have proposed in APC-1631.) My approach was to define a generic capability that contained a capability identifier (any that you suggest would suffice), and also include a field to specify a URL, a field to indicate re-load and optionally a numerical field to indicate which browser window should display the page. Only the capability identifier would be required in the TCS. The other fields are used when opening a channel. As the HTTP channel is really opened from client to server, but it is the server that is requesting the channel to be opened, I intended to use the H.245 RequestMode message. This would specify the HTTP channel using the generic capability above. It would specify the URL to use, or whether a re-load was required. If there were more than one page being displayed, then it could indcate which window to display the data in. As the time that an HTTP channel is open is really very small, and there was really no convenient way to detect when a user had stopped looking at a page, I decided to do away with OLC signalling as it made no sense. Anyway, at the end of the day it adds no value. The resultant exchange would look something like (forgive my lack of drawing skills): -----TCS declaring HTTP support-----> . . Other signalling . <-----RequestMode( HTTP: URL=http://....) --- ------RequestModeAck ------> ------- HTTP Get ------> <----- 200 OK -------- I think this is a cleaner way than using OLC signalling. Specifying a URL allows an HTTP service to be attached without originally setting out to do that. I hope this is clear, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

APCs 1610, 1622 uploaded
by Glen Freundlich 28 Jul '99

28 Jul '99

Dear Q.12-14/16 Experts, I have uploaded the following APCs to the Incoming directory: 1610 - Changes to H.248 Proposed by IETF Megaco 1622 - Expression of Gateway Call Capacity Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

APC-1631 uploaded
by Pete Cordell 28 Jul '99

28 Jul '99

APC-1631 has been uploaded to the PictureTel Incoming directory. The title is: "A Package based Extensible Object-Oriented Framework for H.225" Apologies for the delay. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

Attachment to APC-1558
by Sakae OKUBO 28 Jul '99

28 Jul '99

Dear Q.12-14/16 experts, I have found that APC-1558 (reproduction of TD-24/GEN from the Santiago meeting) has an attachment E.mm. This is now available at the ftp site. ftp://standard.pictel.com/avc-site/9908_Ber/APC-1558-att.zip or http://standard.pictel.com/ftp/avc-site/9908_Ber/APC-1558-att.zip Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

List of uploaded APC documents
by Noriko Hosokawa 28 Jul '99

28 Jul '99

Dear Q.12-14/16 experts, Attached please find the list of uploaded contributions as of 15:00 (Tokyo time) Tuesday 27 July. Those documents yet to be uploaded are marked with *. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ******************************************************** Documents for Q.12-14/16 Rapporteur meeting in Berlin (2-6 August 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9908_Ber/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9908_Ber/APC-1???.??? * yet to be uploaded # to be uploaded after the SG11 Rapporteur meeting this week + to be uploaded on Thursday ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 Editor Draft H.323 Annex J: Security for H.323 Annex F 1564 L M Ericsson H.224 Modified for text conversation 1565 DataBeam Corporation Usage of Expanded T.35 Country Codes in Recommendations H.225.0,H.245, and H.283 1566 Editor H.243 Draft revised ITU-T Recommendation H.243 (white doc.) 1567 L M Ericsson Generic Service ControlTransport 1568 Lucent and H.245 Generic Capabilities Definition and AT&T H.225 Packetization Specification for the North American Cellular/PCS TDMA Vocoders (ACELP and US1) 1569 BT and Tech- Editorial Clarifications to H.323 and the Know-Ware Implementer's Guide 1570 BT and Tech- Clarifications on Third-Party Pause Know-Ware 1571 Rapporteur for Q.12/16 (S Okubo) Status of Draft Amendment 7 to H.222.0|ISO/IEC 13818-1 -- Carriage of ISO/IEC 14496 (MPEG-4) content over H.222.0|ISO/IEC 13818-1 (MPEG-2) System streams 1572 Editor (K Sakai) Draft Implementor's Guide for H.321 V2 1573 Editor (S Okubo) Draft Implementor's Guide for H.310 V2 1574 SG16 Correspondence Representative to DAVIC (S Okubo) DAVIC work on TV Anytime and TV Anywhere systems 1575 Rapporteur for Q.19/16 (S Hayashi) H.245 Capability Definition and H.225.0 Packetization Specification for G.729 1576 Japan Guideline for assigning the T.35 terminal provider codes in Japan 1577 Oki et al Proposed modifications to resolve the inconsistent ASN.1 syntaxes between T.38 Annex B and H.245 1578 Oki et al Proposed additional liasion to SG8 on T.38 Appnedix II 1579 Hitachi, Ltd. Prototype system of H.262 layered video transmission 1580 IETF Megaco Working Group Media Gateway control protocol architecture and requirements 1581 Lucent Technologies and Nortel Networks H.323 v3 and H.225 v3 Support for Improved Alias Registrations 1582 Lucent Technologies H.323 v3 and H.225 v3 Endpoint Registration Clarifications 1583 Siemens AG Error in Coding Bearer Capabilities 1584 Siemens AG Inter-Zone Addressing 1585 Siemens AG Correction of Alias Conflict in H.225.0v3 1586 Siemens AG Identification of Gateway Protocol 1587 Siemens AG Null AliasAddress 1588 SIEMENS Restricted Numbers/Aliases in Supplementary Service APDUs 1589 SIEMENS Work on Supplementary Service Interworking started 1590 SIEMENS Draft H.450.9 "Call Completion Supplementary Services for H.323 1591 AT&T, VocalTec, DataBeam and Alcatel Functional Requirements and Service Classes to Support QOS in H.323 1592 Lucent Technologies Q.SIG Transport in H.323 Systems 1593 PictureTel and Nortel Networks Backward compatibility and clarification text in H.323 Annex C 1594 PictureTel Problem with XRS (Message Not Understood) RAS message 1595 PictureTel Additional information in ARQ for Gateway calls 1596 PictureTel H.245 support for G.722.1 1597 Siemens Feature key management extensions for H.323 SET terminals 1598 VocalTec Communications Ltd Adopting a Pragmatic Approach to IPT-IN InterWorking 1599 VocalTec Clarifications to the fast connect procedure 1600 VocalTec Comments on Transporting DTMF in H.323 1601 VocalTec Changes to H.323 to support operation via basic NAT devices #1602 VocalTec Communications Ltd IN-IPT interworking - feecback from the SG11 Rapporteur #1603 VocalTec Communications Ltd and Marconi Communications Ltd Scope definition of Annex D to H.246 1604 VocalTec Changes to H.248 to assure H.323 GW interoperability *1605 Intel Corporation Proposed Terms of Reference for H.323 Mobility 1606 Cisco Systems Proposal for Transporting User Input via RTP 1607 Cisco Systems Proposal for Enforcing Symmetric Codec Operation with Fast Connect 1608 Tech-Know-Ware and Lucent H.GCP/Megaco Structured Message Encoding Using an ASCII Line Format 1609 Lucent Technologies Support for Q.931 TNS and NSF IEs in H.225.0 *1610 Q.14 Rapporteur Changes to H.248 Proposed by IETF Megaco 1611 RAD Data Communications LTD Proposals for the next version of H.341 MIB 1612 Lucent Technologies,Intel Corporation,FORE Systems Inc.,Teles AG Proposing structured media and bearers for H.248, 1613 Lucent Technologies Proposal for PUT and DELETE commands in H.248, 1614 Lucent Technologies Scripting framework for H.248, 1615 Lucent Technologies H.242 package for support of decomposed H.323-to-H.320 gateways in H.248 1616 LM Ericsson H.GCP and encoding in networks 1617 LM Ericsson Signalling Transport for H.GCP 1618 LM Ericsson Handling of Optional H.GCP commands 1619 LM Ericsson Notification Indicators in H.323 1620 LM Ericsson Signalling Transport in H.323 *1621 LM Ericsson Draft H.246 Annex C *1622 Lucent Technologies Expression of Gateway Call Capacity 1623 Lucent Technologies Need for the Q.931 Disconnect and Release Messages in H.225.0 1624 TAO Some considerations on the new Annex to H.323 for high quality audiovisual communications 1625 Oki Electric Indsutry Editorial errors in H.450.5 and H.450.7 1626 Nortel Networks Tunneling of Q.SIG information in H.225.0 1627 IETF Megaco Working Group R2 Package for MEGACO Protocol 1628 IETF Megaco Working Group Megaco IP Phone Media Gateway +1629 IETF Megaco Working Group Basic Packages For Megaco/H.248 1630 Cisco Systems,Inc. SDP Encoding for H.248. *1631 Tech-Know-Ware and BT A Package based Extensible Object-Oriented Framework for H.225 1632 Lucent Technologies, Tech-Know-Ware, Intel Corporation, FORE Systems, VocalTec Communications, Teles AG Structured Syntax for H.248 1633 Mitel Proposals for Enhanced Feature Support in H.323 1634 Intel Security tokens for releaseComplete UUIE 1635 Telcordia Technologies Mapping H.245 semantics to SDP 1636 Telcordia Technologies Comparing EBNF and ASN.1 for text encoding *1637 Rapporteur Q13 Protocols for Trunking and Access Gateways *1638 LucentTechnologies Gatekeeper Modification of Destination Addresses *1639 LucentTechnologies Trunk and Line Selection in H.323 Gateways 1640 Nortel Networks Clarification on the use of E.164 numbers *1641 Lucent Interoperabity between H.323 Systems using G.711 and SD/CNG 1642 Alcatel and Nortelnetworks Reference to af-saa-0124.000 specification in H.323.V3 1643 MPEG Liaison Statement from SC 29/WG 11 to ITU-T SG 16 on MPEG-4 Over H.32x Terminals [SC 29/WG 11 N 2887] ---------------------------------------------------------------------------- ----

1 0

APC-1630 ("SDP Encoding for H.248") uploaded/enclosed
by Chip Sharp 27 Jul '99

27 Jul '99

I have uploaded APC-1630 for potential consideration at the upcoming rapporteur's meeting. It is also enclosed below. Warning: This contribution is text encoded. ;-) Chip ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC- 1630 | | Study Group 16 | | Q.12-14/16 Rapporteur Meeting 27 August, 1999| | Berlin, 2-6 August 1999 | | | | SOURCE*: Cisco Systems, Inc. | | TITLE : SDP Encoding for H.248 | | PURPOSE: Proposal | | | | _________________________ | | | | | | | | *Contact: Chip Sharp, chsharp(a)cisco.com | ------------------------------------------------------------------ Abstract: The use of SDP encoding has been proposed for H.248. This contribution proposes the following: 1) The SDP encoding that has been proposed since the March compromise should be maintained at least as an option. 2) The encodedparameter should refer to RFC2327 for the SDP encoding. 3) The package names and event names should be text encoded and registered with IANA for extensibility. 4) An IANA considerations section needs to be added to provide guidelines for registering with IANA. Session Description Protocol: --------------------------- The Session Description Protocol (SDP) is described in RFC2327 (ftp://nis.nsf.net/internet/documents/rfc/rfc2327.txt) It is a standards-track protocol in the IETF. Refer to the current edition of the "Internet Official Protocol Standards" (STD 1, ftp://ftp.isi.edu/in-notes/std/std1.txt) for the standardization state and status of this protocol. >From the abstract of RFC2327: "SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation." SDP Proposal: ------------ The encodedDescriptor should maintain the option for SDP encoding. The encodedDescriptor production should be changed to: encodedDescriptor = (SDPToken COMMA *SDPinformation) | (H245Token COMMA quotedOctetString ) | (extensionParameter COMMA quotedOctetString ) Add the following production: SDPinformation = announcement ;Normative: <announcement> is ;defined in Appendix A of RFC2327 In addition, an extension mechanism should be defined. It is recommended that a similar mechanism to that defined in http://search.ietf.org/internet-drafts/draft-huitema-megaco-mgcp-v1- 00.txt be used. Package and Event Proposal: -------------------------- Various Packages are currently being defined for H.248. It is expected that a certain number of packages will be included in the base standard. However, it is also expected that more packages will need to be defined as more applications are defined. This contribution recommends that the package names and event names be text acronyms that are registered with IANA. This will allow new packages and events to be added in an extensible manner. This mechanism is already used for many applications on the Internet. For example, MIME types are registered with IANA. This practice allows extensions to the base capabilities without having to rev the base specification every time a new capability is added. The ITU in general and SG16 in particular already have established precedence in using IANA registration in ITU Recommendations. This is a well-established practice in SG16. All the TCP/UDP ports used in the H.323 series recommendations are registered with IANA. Therefore, there should be no procedural problem with using IANA registration. The following text should be added: In Section 7.2.2.6 Packages, add the following sentence: "Package names, referred to in this document as PackageName, will be registered with IANA." The following changes should be made to the packageName and eventParameterName productions: packageName = NAME ;Normative - The values this production takes are ; registered with IANA as defined in Section ??? eventParameterName = NAME ;Normative - The values this production takes are ; registered with IANA as defined in Section ??? A Section should be added defining the guidelines for registering events and packages with IANA. For example, the following text could be used (taken from SIP): " When registering a new SIP option, the following information MUST be provided: o Name and description of option. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (See Figure 3) characters only; o Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium or a particular company or group of companies); o A reference to a further description, if available, for example (in order of preference) an RFC, a published paper, a patent filing, a technical report, documented source code or a computer manual; o Contact information (postal and email address); This procedure has been borrowed from RTSP [4] and the RTP AVP [26]." However, this is not sufficient. Guidelines similar to those defined in RFC2327 should be developed. CONCLUSION ---------- In conclusion: 1) The SDP encoding that has been proposed since the March compromise should be maintained at least as an option. 2) The encodedparameter should refer to RFC2327 for the SDP encoding. 3) The package names and event names should be text encoded and registered with IANA for extensibility. 4) An IANA considerations section needs to be added to provide guidelines for registering with IANA. -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

H.245v6?
by Paul Long 27 Jul '99

27 Jul '99

H.323v3 references H.225.0v3 and H.245v6, but I cannot find even a draft of H.245v6. Anybody know where it is? Also, why the drastic jump in H.245 versions? Paul Long Smith Micro Software, Inc.

1 0

Documents uploaded
by Kaynam Hedayat 27 Jul '99

27 Jul '99

Dear colleagues, I have uploaded the following documents into the incoming directory: APC-1593: Backward compatibility and clarification text in H.323 Annex C (PictureTel and Nortel) APC-1594: Problem with XRS (Message Not Understood) RAS message (PictureTel) APC-1595: Additional information in ARQ for Gateway calls (PictureTel) APC-1596: H.245 Support for G.722.1 (PictureTel) Regards, Kaynam Hedayat

1 0

APC-1629 -- Basic Packages For H.248
by Tom-PT Taylor 27 Jul '99

27 Jul '99

I have to apologize for late delivery of APC-1629. Editing was going well, but I had to leave for the airport. Due to last-minute distractions I managed to leave my computer behind. I'm afraid I won't be able to upload APC-1629 until Thursday morning. Tom Taylor

1 0

Re: APC-1573
by Sakae OKUBO 27 Jul '99

27 Jul '99

Dear Mr. Euchner, > it appears to me that file APC-1573.zip does not contain the related > contribution APC-1573.doc as one should assume by the file name. The zip > archive rather contains the APC-1572.doc. Thus, I am not able to locate > APC-1573.doc so far. Thank you very much for your advice. APC-1573.zip has been replaced with the file containing APC-1573.doc. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

APC-1597 uploaded
by Korpi, Markku 27 Jul '99

27 Jul '99

I have uploaded: APC-1597 "Feature key management extensions for H.323 SET terminals" Markku Korpi Siemens Information & Communication Networks 4900 Old Ironsides Dr., Santa Clara, CA 95054-1811, U.S.A. Phone: +1 408 492 7328, Fax: +1 408 492 4666, Mobile +1 408 390 5677 E-mail: markku.korpi(a)icn.siemens.com

1 0