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

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