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

Upload of White Paper for Version 6 of H.245 (New version)
by mike.nilsson＠BT.COM 08 Oct '99

08 Oct '99

I have sent the White Paper for version 6 of H.245 to the ITU and have uploaded it to ftp://standard.pictel.com/avc-site/Incoming/h245_k.zip This contains three files: WCM (full version with change marks), NCM (full version with no change marks) and DEL (cut down version with change marks). The only change from the version I posted to the ftp site on 14 September concerns Annex I, GSM Adaptive Multi Rate Capability Definitions, where a number of the tables have been changed. Best regards Mike Nilsson ********************************************************************** * 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 * **********************************************************************

2 1

H.323 Annex E: sequence numbering?
by Manoj Paul 04 Oct '99

04 Oct '99

Hi All, I have a few concerns about H.323 Annex E proposed document. My reference is the "Proposed changes to H.323 Annex E" document which was presented at Santiago meeting of SG13/16. Section E.1.3.2 states Serial Model. It says that Annex E stack will wait until a positive reply is returned * for the same Session-Identifier *. This means that an outgoing Annex E PDU can only contain multiple payloads of the same session only. Second, it implies that the sequence number (which is present in Annex E PDU header) must be unique now across < sender host+port, rcv host+port, session-id>. We can not make sequence number unique across <sender host+port, rcv host+port> only, because the message sequences should be blocking only for same session-identifier, as stated by the NOTE appended below section E.1.3.2. The Annex E Ack message, however, only contains the sequence number of Annex E PDU. How can the sender of an Annex E PDU will distinguish for what session's PDU this ack has come for? Because sender might have sent Annex E PDUs with the same sequence number for different sessions over a given < sender host+port, rcv host+port>. Am I missing something here. I will appreciate any clarifications on the above. regards, Manoj Paul.

2 1

draft-04 vs. Results from Berlin
by Nancy-M Greene 30 Sep '99

30 Sep '99

For each point raised at the ITU-T SG16 meeting in Berlin, I have put the reference in the new Megaco/H.248 draft that covers it. This can be used to determine how the current draft implements the desired change requested in Berlin. The Berlin draft is: ftp://standards.nortelnetworks.com/wash99/MegacoH248v9Chgs.doc or ftp://standards.nortelnetworks.com/wash99/MegacoH248v9Chgs.zip The draft-04 of Megaco/H.248 is: ftp://standards.nortelnetworks.com/latest/megaco-h248_protocol.pdf, or ftp://standards.nortelnetworks.com/latest/draft-ietf-megaco-protocol-04.txt Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > Technical additions/changes/issues > ---------------------------------------------------- > T1) Section 6.2.2.2: Intercept: added a topology descriptor as a context > parameter, to allow operator intercept, wiretapping - satisfies the > regulatory requirement of only allowing the tapping of one side. Also, > removed InterceptToken from ABNF - this is done using context parameters > instead. ***Need to review this topology descriptor proposal to see > whether > it works, and whether it could be covered already in another way, using > the > muxing descriptor for example. > see draft-04 7.1.16 Topology Descriptor > T2) Section 6.2.3.3: TerminationIds - Changed "arbitrary string" to > "arbitrary schema" so it is not tied to a text encoding (there may be a > better word). Note that there is NO special meaning about the / character. > Added "In a text encoding of this protocol". Added sentence > "TerminationIDs > of physical Terminations are provisioned in the Media Gateway". > Re-included > text describing use of hierarchical terminationIds. > see draft-04 Section 6.2.2 > T3) Section 6.2.3.5: ***Make sure the parameter tables from the Santiago > text go in an annex as parameters of one of the basic packages. These > parameters would be included in the LocalDescriptor. > see draft-04 Annex D. > T4) Section 6.2.3.5: ***There is still an issue with tx and rx descriptor > names: when you do an add on the RTP termination, in the response you will > get params for RxDescriptor (local information). BUT it is also a transmit > descriptor. So, there is still a wish to call rxDescriptor the > localDescriptor, and txDescriptor the remoteDescriptor. Note added. > In draft-04, the 3 descriptors a StreamDescriptor may have are now called LocalControl, Local, and Remote. > T5) Section 6.2.3.6: ***Issue with ROOT TerminationId - It seems a bit of > a > kludge to use a special ROOT terminationId to refer to the entire MG - can > we make TerminationId optional in AuditValue, AuditCapability? then we > would > not need ROOT. Check effect to ServiceChange. > In draft-04 - ROOT left as is. Useful for applying commands to the properties of the entire MG. > T6) Section 6.3.2.11: ***Need to add a way to configure the level of > embedding of signals/events descriptor, and MGC needs to be able to find > out > the level of embedding. > In draft-04, Embedding is explicitly limited to one level of embedding (see end of 7.1.10). > T7) Section 6.3.2.11: Re-added the sentence saying at least one level of > embedding should be supported. (Why was it removed?) > In draft-04, sentence changed to say that only ONE level of embedding is allowed (see end of 7.1.10). > T8) Sectio 6.3.2.15: DigitMapDescriptor - Added a start timer, ***still > need > to add text for naming/use of transient digit maps. ***Also need to make > sure that if the MG fails to load a digit map, event notification > continues > anyway. > see draft-04 Section 7.1.14 - are two *** points above covered in draft-04? > T9) Section 6.3.2.15: Re-added some of the text in digitMapDescriptor on > wildcarding. > see draft-04 section 7.1.14 > T10) After Section 6.3.3.8: Put/Delete removed - they are for future > consideration. > ok > T11) Section 6.3.2.10, 6.3.4, Annex A, B, C: Text vs binary: Annex A added > for modified ASN.1 that describes the protocol syntax, Annex B for the > ABNF, > and the translation mechanism, and Annex C for the binary and the binary > translation mechanism. > See draft-04 Annexes A, B, C. > Agreements: ABNF remains normative. ASN.1 and compiler to compile into the > ABNF already written, will also be added as normative when they are > available. Sentence added: " This compiler is a living tool that will > likely > be enhanced over time. To start, this tool should be tested to verify that > syntax can be compiled to the ABNF defined below. > > It is expected that industry forums would define profile for use of H.248 > and this would include whether text vs binary is used, as well as which > packages would be used, etc. In Section 6.3.4, sentences added: "MGCs > should > support both encoding formats. MGs may support both formats." > see draft-04 section 7.2.9 Generic Command Syntax: "The protocol can be encoded in a binary format or in a text format. MGCs should support both encoding formats. MGs may support both formats" > T12) Section 6.3.2.10, Annex D: A new proposal has been added for native > encoding of StreamDescriptors (SDP codepoint is still there). Changes made > to ABNF, reference made to SDP RFC, and to native encoding. ***Media > descriptor parameter and value tables put into Annex D - this annex still > needs work. ***Need to add in the sentence: "It is recommended that the > native encoding method for stream descriptors be used when encoding is > binary, and the SDP method be used when the protocol encoding is > text-based." > See draft-04 - Annex D is not complete. > T13) Section 6.4.1, 6.4.3.1,6.4.3.2, 6.4.3.3: Simplify transaction > semantics > - changes to text and to ABNF (Annex B) made: removed the concept of > rollback on transactions - the document did not define how you could roll > back commands that actually cause physical changes on the MG, e.g., > sending > of a signal, subtracting a termination from a context. > > It was decided that in fact, all a transaction does, is ensure that > commands > occur in a particular order, and that no commands after a command that > fails, gets executed. In a TransactionAccept, need to say what a response > is > - added sentence on this. In a TransactionReject, the command that failed > has error code, all the rest of the commands are not executed. > See draft-04 section 8. > T14) Section 6.4.1: Transaction figure - renamed "action" to "contextId". > See draft-04 Figure 5, section 8 > T15) Section 6.5: ***An example use case for text telephony will be added > (need to move all examples to an informative appendix). > Added in draft-04 - See last example in Annex G. > T16) Section 6.6: Transport: Proposed text added - it does not change > current transport functionality in draft-ietf-megaco-protocol-03.txt. > ***Editorial changes to this section will be suggested. > Transport section is draft-04 Section 9; Transport using UDP and ALF is Annex E, Transport using TCP is Annex F > T17) Section 6.7: Security section - some clarifications to text added - > you > do not have to implement AH-in-Megaco/H.248 if you have IPSEC. Only ONE of > the two schemes is used at one time - if IPSEC is on both MGC and MG, it > is > used, otherwise AH-in-Megaco/H.248 is used. Proposed text: "The MG need > only > support IPSEC if it is capable. Otherwise it must support > AH-within-Megaco/H.248." ***Section too long, needs rewording. > see draft-04 Section 10. "Implementations of the MEGACO/H.248 protocol SHALL implement IPsec where the underlying operating system supports IPsec. Implementations of the MEGACO/H.248 protocol using IPv4 SHALL implement the interim AH-within-MEGACO/H.248 scheme. However, this interim scheme SHALL NOT be used when the underlying network layer supports IPsec. IPv6 Implementations are assumed to support IPsec and SHALL NOT use the AH-within-MEGACO/H.248 interim scheme." > T18) Section 6.7: *** Security: request clarification on how the MGC knows > what the security mechanism is that the MG is using, and vice versa. > See draft-04 Section 10. > T19) Section 7: Packages: a proposal for the writing of base packages, > along > with proposals for the base packages will be turned into an internet-draft > and submitted for comment. > See draft-04 Section 12. > T20) Section 7.2: Text added for IANA registration of packages. ***Text > still needs work. Agreed that IANA is the place to register ALL packages. > Suggestion that procedures should say that for ITU-T packages, we would > standardize the first few characters of the package name, and that a > public > document describing the packages are not necessarily required. > See draft-04 Section 13. > T21) Annex B: ***AuditCapabilities - need to allow multiple copies of > descriptors to be returned. ABNF needs to be updated. > See draft-04 Annex B - ABNF allows multiple copies of descriptors. > T22) Annex D, SDP: ***Need to be able to pass a QoS parameter to the MG. > (Note: Place to define this would be in the Package that defines > parameters > to the LocalDescriptor. Also needed in SDP.) > SDP allows a bandwidth parameter - check SDP RFC. > Editorial changes > ------------------------- > E1) Section 1: Have an ITU scope, and an IETF scope. Text that is there is > the ITU scope. > ok > E2) Architecture: Change architecture section back to Santiago determined > version of the text, and move it to H.323, instead of having it as an > annex > to H.248. If architecture is moved out, all definitions (section 3) that > pertain to the architecture section and not the protocol, for example, GK, > can be deleted. (Note - there is still an issue of where the architecture > section will live, but in any case, it will NOT be in the IETF version of > the protocol). > ok - draft-04 has no architecture section. > E3) ***Section 3: Add definition for stream, signal, event (not done yet). > see draft-04 Section 3: definition for stream, descriptor added. Still need to remove defintions of GK, etc, that are no longer referenced in this protocol document. > E4) Requirements section (old section 6) is removed. No need to reference > requirements doc in this document. > ok > E5) Section 6.1:Removed reference to "interface A". > ok > E6) Section 6.2.1, 6.2.3.1: Terminations Basic Concepts, and Overview - > some > wording changes. For example, in the case of intercept for wiretapping, a > third termination in a context does not make the context a conference > bridge. Also conference replaced by association. > see draft-04 Section 6.2 > E7) ***Section 6.2.2.1: Context general - wording changes, still needs > work. > see draft-04 Section 6.1 > E8) Section 6.2.3.1 Change Audit to AuditValue just before Termination > Dynamics section. A few other changes to paragraph describing muxing. > ok, see end of draft-04 Section 6.2 > E9) section 6.2.3.5, 6.2.3.8: The "Support" columns in several tables have > been removed (not relevant now). This makes it look like those entire > tables > have been changed - in fact it is just that a column has been removed. > ok > E10) Section 6.3.2.12: Clarifications made to definition of "brief": "no > timeout value is needed". > see draft-04 section 7.1.11 > E11) Section 6.3.3: Clarified text in Command API describing the syntax > used. > ok > E12) Section 6.3.3.1: Add command - MediaDescriptor now marked as optional > in the text. > see draft-04 section 7.2.1 > E13) section 6.2.3.5: Some clarifications made in the section on > Termination > Properties and Descriptors. > ok > E14) Section 6.2.3.7: Added section for templates, and marked it for > further > study. > for further study sections removed in draft-04. > E15) Section 6.2.3.8: Added section for scripting descriptors (marked for > further study). Make sure we can add them later to the protocol, e.g. make > sure it can be used as an alternative way of describing digit maps. > for further study sections removedin draft-04. Scripting can be added later as a new parameter to commands called a ScriptingDescriptor. > E16) Section 6.3.2.9: LocalDescriptor - mode not defined well - sentence > removed. > Termination state defined in draft-04 Section 7.1.6 (test, in service, out of service), Stream Mode in Section 7.1.8: "The allowed values for the mode parameter are "send only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), "inactive" (inactive), "loop back" (looback) and "delete" (delete). "Send" and "Receive" are with respect to the stream within a termination, so that, for example, a stream set to mode=sendonly can talk but it cannot listen. Mode set to delete is used to remove a stream from a termination." > E17) Section 6.3.2.11: ***Question: does loop in eventBuffer mean that > event > is returned each time it occurs without having to resend an > EventsDescriptor > - need to make text clearer. > see draft-04 Section 7.1.6 - is the text clearer now?: "2) BufferedEventNotificationMode - specifies whether the Media Gateway is expected to detect the requested event and notify the controller once (step by step) or repeatedly". > E18) Section 6.3.5: ***Need to renumber error codes (Need to discuss this > - > may be better to leave them with the numbering they have.) > - see draft-04 Section 7.3 - leave numbering as it is > E19) Section 7.2: ***Verify that all places that require IANA registration > in one place are grouped - error codes, packages, - (Events and signals do > NOT need to be registered - they are defined in packages). > > > > Questions > -------------- > Q1) What is the media type parameter of a termination? Is it in the stream > descriptor? or is it at the termination level? In describing the > muxDescriptor, it is stated that the media type of a termination included > in > a mux is set to mux... > erroneous text removed in draft-04 . > Q2) Check semantics in embedded signals - what happens if one of the > signals > fails - is the next signal applied or is it an error? > check. > Q3) Check that you can put two signals on a line and they are mixed. > > Q4) How does MGC to find out if MG supports digit maps? By just sending > them, and the MG ignores them if it wants to? > -------------- > > Nancy > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

FW: Megaco/H.248 Packages Teleconference
by Tom-PT Taylor 30 Sep '99

30 Sep '99

Second try. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904-I:EXCH] > Sent: Thursday, September 30, 1999 3:17 AM > To: megaco(a)standards.nortelnetworks.com; itu-sg-16(a)mailbag.intel.com > Subject: Megaco/H.248 Packages Teleconference > > I have started by reserving 20 ports for the call -- I expect this will > increase as your requests come in (mailto:taylor@nortelnetworks.com). The > phone number to call is > > +1 919 905 6338 (Nortel attendees call 260 6338). > > Once dialled in, if you have DTMF, dial the following passcode when > prompted: > 209516# > If you do not have DTMF, wait for the operator to come on line and then > state the above passcode. > > If the fact that you have to pay to connect to this number is a barrier to > your participation, please let me know and I'll figure out how to reserve > a > toll-free number instead. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961

1 0

H.323/H.225.0 V3 has been decided
by Dale L. Skran 30 Sep '99

30 Sep '99

H.323 Interested Parties: I am pleased to announce that today SG16 "decided" H.323 V3 and H.225.0 V3, as well as H.323 Appendix IV. Thanks to all who contributed to this effort, but especially to the editors, Paul Jones and Glen Freundlich. I would like to give a special thanks to Glen Freundlich for all his hard work on H.225.0 V2 and V3, and welcome again the new H.225.0 V4 editor, Rich Bowen of Cisco. The draft output will be shortly available on the reflector. Thanks for your attention, Dale Skran Rapporteur SG16 WP2 Q13

1 0

Q12-14/16 Red Bank meeting
by Sakae OKUBO 30 Sep '99

30 Sep '99

Dear Q12-14/16 experts, This is to report that we have obtained the final approval of the SG16 management for holding the Rapporteur meeting in Red Bank during 18-22 October. Please note the following deadlines for submission of your contributions: /// Registration of the document: by 8 October (Friday) /// /// Distribution of the document: by 11 October (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// The meeting notice is available at: ftp://standard.pictel.com/avc-site/9910_Red/Notice_Red_Bank.txt or http://standard.pictel.com/ftp/avc-site/9910_Red/Notice_Red_Bank.txt 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

FW: Packages Conference Call
by Tom-PT Taylor 30 Sep '99

30 Sep '99

Glen Freundlich suggested I cross-post this one to the SG 16 list. The conference call will take place Monday morning at 8:00 am PDT (11:00 am EDT, 5:00 pm where I am in Germany). I don't have a decent count of ports needed yet, so I haven't yet arranged a number to call. Please let me know if you want to take part (mailto:taylor@nortelnetworks.com). > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904-I:EXCH] > Sent: Tuesday, September 28, 1999 10:02 AM > To: megaco(a)standards.nortelnetworks.com > Subject: Packages Conference Call > > Today or tomorrow, all going well, Mike Kallas and his collaborators will > release a draft of the basic packages document which is an essential part > of > the Megaco work product. I am sure this document will need work from the > list to get it into final shape -- I myself don't agree with it entirely. > To help us along, I propose that we have an audio conference early next > week > to get a feeling for the group's consensus on a number of policy issues. > This could be followed if necessary by a drafting session next week or the > week after, open to anyone who wants to take part. > > What follows is a proposed agenda for the audio conference. Advance > discussion on the list to prepare the way will be most welcome. Those who > want to take part in the audio conference please let me know whether > Monday > or Tuesday would be better. I will be in Europe, which will tend to bias > me > against starting times later than 3 pm EDT, but you can state preferred > time > if you want. > > Agenda: > > 1. Scope of the Basic Packages Document > > Is there any special significance to the packages we choose to put in this > document as opposed to another one? > What applications do we cover? > - carrier only, or enterprise too? > - lines, trunks, data, text? > - digital circuit, RTP, ATM AAL1, ATM AAL2, ATM AAL5, FR? > > 2. Package and Event Definition Policy > > Do we try to define a minimum number of events and signals with broad > scope > and a number of parameters, or lots of specialized events and signals with > fewer parameters? (Example: a single recvTone event with parameters > indicating the class(es) of tones to listen for, versus separate events > for > DTMF, MF, FAX, data modems, and (maybe) call progress tones.) > > Can the same events be defined in different packages? > > How do we handle regional variations? > > Do we assume the MGC and MG already understand (are mutually provisioned > with) specific tones beyond a single common basic set (e.g. both units > understand what PAT023 means), or do we provide for such provisioning in > Megaco? > > Do we define actions which combine signals and events in their behavioural > description, or do we keep things at the atomic level we have inherited > from > MGCP? > Example: we could define a "collect" signal(?) which has the following > behavioural specification (not as complete as I'd make it in a real > specification): > -- apply dial tone to the termination (with the regional variant of dial > tone supplied as a possible parameter) > -- discontinue dial tone when the first of two events happens: timeout > awaiting first digit (in which case dial tone should be replaced with > reorder tone), or first digit received > -- collect and report digits according to the supplied digit map, if any > -- buffer additional digits after the initial report pending further > instructions from the MGC. > > > 4. What Events/Signals And Packages Should We Have? > > The specification about to be released has the following packages and > events > and signals within them: > > Generic audio package > Events: ToneStartDetected, ToneEndDetected, LongToneDetected > Signals: PlayTone, StopTone, DefineTone > > Generic DTMF package > Events: ToneDetected, SilenceDetected > Signals: PlayTone, StopTone > > Dialpad package > Events: DialpadKeyDown, DialpadKeyUp > Signals: DialpadEcho > > Function key package > Events: FunctionKeyDown, FunctionKeyUp > Signals: AssignFunctionKeyName > > Indicator package > Events: none > Signals: SetIndicator, SetName > > Monochrome text display package > Events: none > Signals: Display, ClearDisplay > > Softkey package > Events: KeyDown, KeyUp > Signals: SetName, Display > > Trunk generic package > Events: ModemDetected, FAXToneDetected, ReportFailure > Signals: BusyTone, RingingTone, CongestionTone > > Trunk supplementary package > Events: ContinuityTest > Signals: ContinuityTone > > NAS package > Events: ReportFailure, AuthorisationSucceeded, AuthorisationDenied, > CallbackRequest, AAAFail > Signals: none > > RTP package > Events: ReportFailure, QualityAlert > Signals: none > Statistics: the usual > > Announcement server package > Events: AnnouncementFailure, AnnouncementCompleted > Signals: AnnouncementPlay > > > 5. Miscellaneous Definitional Issues > > Event/signal configuration vs. event reporting. > > Relationship of event reporting to digit maps -- especially the > inclusion > of MF events in our present ABNF. > > What has to go into the packages which indicate the network-specific > characteristics of terminations? > > Meaning of terminationMode: "send" to the exterior or into the context? > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > > > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961

1 0

Endless Loop
by Meyer, Greg W 29 Sep '99

29 Sep '99

All: As you have already noticed yesterday, there was an endless loop between the Cisco automated postoffice and this mail reflector. The person, who was subscribed to this mail reflector, apparently moved from Cisco and was removed from their mail service. When a posting occurred, it went to Cisco's postoffice who now knew nothing of him. So it replied to the mail reflector (not the originator of the message) and there went the loop. I'm afraid this may be a consequence to the the limitations of this mail server, the needs of its members and errant postoffices. We must keep the list open for public postings (non-members of the list can post) because of email address changes and group-listings (companies/groups subscribed under one email address where they manage their own subscribers). I currently monitor the postings by routing them to a special mailbox. Unfortunately, my duties prevent me from looking at this every day (travel, meetings, etc.). So it's possible that one of these endless loop conditions might occur without my knowledge. Here's where you can help. If you see this happening, please contact me (mailto:greg.w.meyer@intel.com, or call 503.264.9506) directly but please don't post to the reflector (which would only make matters worse). Please don't post any new messages while an endless loop condition is in progress (again, it'll only make matters worse). Once I'm on it, I'll zap the offender from the list and post an "all clear" notice. I apologize for filling up everyone's mailboxes and appreciate your help. Greg Meyer mailto:greg.w.meyer@intel.com 503.264.9506 -----Original Message----- From: Sherlock, Stuart [mailto:stuart.sherlock@INTEL.COM] Sent: Tuesday, September 28, 1999 2:02 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Your mail to ggoodkni could not be delivered. Somebody clean this up!!!!! I am not doing anything here. Stuart -----Original Message----- From: nobody(a)CISCO.COM [mailto:nobody@CISCO.COM] Sent: Tuesday, September 28, 1999 1:51 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Your mail to ggoodkni could not be delivered. Hello. You have sent mail to an address that is no longer valid at Cisco Systems. We have the following forwarding information for this address: [Sorry. No forwarding information available.] If this is a mailing list, please feel free to either remove the name or update the address with the information above. Thank you. Postmaster Cisco Systems, Inc. The headers of your original message follows: ------------------------------------------------- >From ITU-SG16(a)mailbag.cps.intel.com Tue Sep 28 13:50:13 1999 >Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) > by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id NAA05751; > Tue, 28 Sep 1999 13:50:12 -0700 (PDT) >Received: (from smap@localhost) > by proxy2.cisco.com (8.8.7/8.8.5) id NAA23136; > Tue, 28 Sep 1999 13:49:54 -0700 (PDT) >Received: from mailbag.cps.intel.com(192.102.199.72) by proxy2.cisco.com via smap (V2.0) > id xma023126; Tue, 28 Sep 99 20:49:52 GMT >X-SMAP-Received-From: outside >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA01333; > Tue, 28 Sep 1999 13:23:39 -0700 (PDT) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8c) with spool id 145971 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, 28 > Sep 1999 13:23:39 -0700 >Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id NAA01253 for > <ITU-SG16(a)mailbag.cps.intel.com>; Tue, 28 Sep 1999 13:13:37 -0700 > (PDT) >Received: by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) id NAA14884 for > ITU-SG16(a)mailbag.cps.intel.com; Tue, 28 Sep 1999 13:23:24 -0700 (PDT) >Precedence: Junk >Message-ID: <199909282023.NAA14884(a)sj-mailhub-2.cisco.com> >Date: Tue, 28 Sep 1999 13:23:24 -0700 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: nobody(a)cisco.com >Subject: Your mail to ggoodkni could not be delivered. >Comments: To: ITU-SG16(a)mailbag.cps.intel.com >To: ITU-SG16(a)mailbag.cps.intel.com >

1 0

WG: H.225.0 - Length of Cause IE in Release Complete message
by Horvath Ernst 29 Sep '99

29 Sep '99

Considering the issue further, a length of one octet is definitely wrong (it must be 2 octets for an empty Cause IE) and has to be fixed (original mail is attached below). Ernst Horvath Siemens AG ==================== > -----Ursprüngliche Nachricht----- > Von: Horvath Ernst > Gesendet am: Mittwoch, 29. September 1999 11:15 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.225.0 - Length of Cause IE in Release Complete message > > Dear Mr. Freundlich, > > In H.225.0V3, section 7.3.9, the Cause IE is marked CM, and the associated > note implies that this IE can actually be included (see table 12/H.225.0). > But the length of one octet allows only an empty IE, which is meaningless. > > > Is this an error or intentional? In any case it is confusing and should be > fixed at the Red Bank meeting. > > Ernst Horvath > Siemens AG

1 0

H.225.0 - Length of Cause IE in Release Complete message
by Horvath Ernst 29 Sep '99

29 Sep '99

Dear Mr. Freundlich, In H.225.0V3, section 7.3.9, the Cause IE is marked CM, and the associated note implies that this IE can actually be included (see table 12/H.225.0). But the length of one octet allows only an empty IE, which is meaningless. Is this an error or intentional? In any case it is confusing and should be fixed at the Red Bank meeting. Ernst Horvath Siemens AG

1 0

APC Document number
by Noriko Hosokawa 29 Sep '99

29 Sep '99

Dear Paul E. Jones In response to your request, APC-1667 has been allocated to your contribution. APC-1667 > Source: Editor (P Jones) > Title: H.323v4 draft 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 NortelNetworks ISO/IEC 11571 addressing in H.323 Annex V 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure 1662 VocalTec Communications Ltd. et. al. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 AT&T H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1665 AT&T Viewgraph Presentation of H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1666 Nortel and Siemens Megaco/H.248 Generic Packages 1667 Editor (P Jones) H.323v4 draft 1668 1669 1670 ----------------------------------------------------------------------------

1 0

APC Document number
by Noriko Hosokawa 29 Sep '99

29 Sep '99

Dear Zacharias Bilalis In response to your request, APC-1666 has been allocated to your contribution. APC-1666 > Source: Nortel and Siemens > Title: Megaco/H.248 Generic Packages 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 NortelNetworks ISO/IEC 11571 addressing in H.323 Annex V 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure 1662 VocalTec Communications Ltd. et. al. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 AT&T H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1665 AT&T Viewgraph Presentation of H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1666 Nortel and Siemens Megaco/H.248 Generic Packages 1667 Editor (P Jones) H.323v4 draft 1668 1669 1670 ----------------------------------------------------------------------------

1 0

[Q] H.323 supplementary services
by Lee Hyoung soo 29 Sep '99

29 Sep '99

Is there any study group or mailing list related with supplementary services in H.323? best wishes, soo.

1 0

Re: Your mail to ggoodkni could not be delivered.
by Sherlock, Stuart 28 Sep '99

28 Sep '99

Somebody clean this up!!!!! I am not doing anything here. Stuart -----Original Message----- From: nobody(a)CISCO.COM [mailto:nobody@CISCO.COM] Sent: Tuesday, September 28, 1999 1:51 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Your mail to ggoodkni could not be delivered. Hello. You have sent mail to an address that is no longer valid at Cisco Systems. We have the following forwarding information for this address: [Sorry. No forwarding information available.] If this is a mailing list, please feel free to either remove the name or update the address with the information above. Thank you. Postmaster Cisco Systems, Inc. The headers of your original message follows: ------------------------------------------------- >From ITU-SG16(a)mailbag.cps.intel.com Tue Sep 28 13:50:13 1999 >Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) > by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id NAA05751; > Tue, 28 Sep 1999 13:50:12 -0700 (PDT) >Received: (from smap@localhost) > by proxy2.cisco.com (8.8.7/8.8.5) id NAA23136; > Tue, 28 Sep 1999 13:49:54 -0700 (PDT) >Received: from mailbag.cps.intel.com(192.102.199.72) by proxy2.cisco.com via smap (V2.0) > id xma023126; Tue, 28 Sep 99 20:49:52 GMT >X-SMAP-Received-From: outside >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA01333; > Tue, 28 Sep 1999 13:23:39 -0700 (PDT) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8c) with spool id 145971 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, 28 > Sep 1999 13:23:39 -0700 >Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id NAA01253 for > <ITU-SG16(a)mailbag.cps.intel.com>; Tue, 28 Sep 1999 13:13:37 -0700 > (PDT) >Received: by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) id NAA14884 for > ITU-SG16(a)mailbag.cps.intel.com; Tue, 28 Sep 1999 13:23:24 -0700 (PDT) >Precedence: Junk >Message-ID: <199909282023.NAA14884(a)sj-mailhub-2.cisco.com> >Date: Tue, 28 Sep 1999 13:23:24 -0700 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: nobody(a)cisco.com >Subject: Your mail to ggoodkni could not be delivered. >Comments: To: ITU-SG16(a)mailbag.cps.intel.com >To: ITU-SG16(a)mailbag.cps.intel.com >

1 0

Red Bank hotel alternatives
by Glen Freundlich 28 Sep '99

28 Sep '99

Dear Colleagues, If you have found that the hotel for the Red Bank meeting is fully booked, an alternative is a Courtyard Marriott. I've been told this hotel is a 5 to 10 minutes by car from the Molly Pitcher where the meeting will be held. I've also been told the hotel will honor the Lucent rate of $110 per night (excluding taxes) if you mention it. I'd suggest booking as soon as possible. Details are: Courtyard Lincroft 245 Half Mile Road Red Bank, NJ 07701 732-530-5552 800-321-2211 Please contact me if I can provide any assistance. 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 Document number
by Noriko Hosokawa 28 Sep '99

28 Sep '99

Dear Roy, Radhika R In response to your request, APC-1664 and APC-1665 have been allocated to your contributions. APC-1664 > Source: AT&T > Title: H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking APC-1665 > Source: AT&T > Title: Viewgraph Presentation of H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure 1662 VocalTec Communications Ltd. et. al. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 AT&T H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1665 AT&T Viewgraph Presentation of H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1666 1667 1668 1669 1670 ---------------------------------------------------------------------------- ----

1 0

APC Document number
by Noriko Hosokawa 28 Sep '99

28 Sep '99

Dear Irina Suconick In response to your request, APC-1663 has been allocated to your contribution. APC-1663 > Source: Editor (I Suconick) > Title: H.341 V2 contribution 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure 1662 VocalTec Communications Ltd. et. al. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 1665 ----------------------------------------------------------------------------

1 0

APC Document number
by Noriko Hosokawa 28 Sep '99

28 Sep '99

Dear Boaz Michaely In response to your request, APC-1661 and APC-1662 have been allocated to your contributions. APC-1661 > Source: VocalTec Communications Ltd. > Title: Resolution of H.245 ambiguity when using Fast Connect procedure APC-1662 > Source: VocalTec Communications Ltd. et. al. > Title: Changes to H.323 to support operation behind basic NAT devices - version 2 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure 1662 VocalTec Communications Ltd. et. al. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 1665 ---------------------------------------------------------------------------- ----

1 0

Re: Megaco/H.248 reqs -06
by Irina Suconick 27 Sep '99

27 Sep '99

Hi Tom, It would be nice to get together in NJ and discuss MAGACO MIB. We can set up a time when it gets closer to the meeting. Regards, Irina. > -----Original Message----- > From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] > Sent: Thursday, September 23, 1999 8:14 PM > To: ITU-SG16(a)mailbag.cps.INTEL.com > Subject: Re: Megaco/H.248 reqs -06 > > This message uses a character set that is not supported by the Internet > Service. To view the original message content, open the attached > message. If the text doesn't display correctly, save the attachment to > disk, and then open it using a viewer that can display the original > character set. << File: message.txt >>

1 0

H.282 document - Re: H283 decided document is available
by Mark Duckworth 27 Sep '99

27 Sep '99

Paul, You can get H.282 at ftp://www.imtc.org/imtc-site/Data_Conferencing_AG/T120-top/geneva98-2/Deter… This is the Determined version, which is the same as what has been Decided. Mark Paul Long <plong(a)SMITHMICRO.COM> on 09/25/99 03:56:13 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Mark Duckworth/PicTel) Subject: Re: H283 decided document is available Mark, Where can I find H.282? I can't find it at standard.pictel.com or www.itu.ch. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Mark Duckworth [mailto:Mark_Duckworth@PICTEL.COM] Sent: Friday, June 04, 1999 8:56 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H283 decided document is available I uploaded it to the ftp site. ftp://standard.pictel.com/avc-site/Incoming/H283_decided.zip Mark

1 0

APC Document number
by Irina Suconick 27 Sep '99

27 Sep '99

Dear Mr. Okubo, I would like to request an APC number for H.341 V2 contribution. Thanks, Irina

1 0

APC Document number
by Noriko Hosokawa 27 Sep '99

27 Sep '99

Dear Dave Walker In response to your request, APC-1660 has been allocated to your contribution. APC-1660 > Source: Mitel > Title: Proposed H.323 Annex L (Stimulus Protocol) 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 1662 1663 1664 1665 1666 ----------------------------------------------------------------------------

1 0

APC Document number
by Noriko Hosokawa 27 Sep '99

27 Sep '99

Dear Jaakko Sundquist In response to your request, APC-1659 has been allocated to your contribution. APC-1659 > Source: Nokia > Title: Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 1662 1663 1664 1665 1666 ---------------------------------------------------------------------------- ----

1 0

Would you like to double your sales?
by Zack 26 Sep '99

26 Sep '99

*** URGENT *** ACCEPT CREDIT CARDS FOR YOUR BUSINESS AND INCREASE YOUR PROFITS 30%-50% ! INTERNET STOREFRONT HOMEBASED OR MAIL ORDER BUSINESSES WE SPECIALIZE IN HELPING THE SMALL BUSINESS OWNER! IF YOU CALL IN THE NEXT FIVE DAYS YOU WILL RECEIVE: NO APPLICATION FEE NO PROGRAMMING FEE AND YOUR FIRST AND LAST MONTH LEASE PAYMENT IS FREE YOU CAN GET STARTED FOR ONLY $9.95 !!! DON'T FORGET TO ASK ABOUT OUR WEB HOSTING AND DESIGN PACKAGE !!! CALL (888) 264-9272 OUR HOURS OF BUSINESS ARE 9AM - 6PM MST ///////////////////////////////////////////////////////////////////// / Please remove at mailto:linbm@angelfire.com?subject=remove //////////////////////////////////////////////////////////////////////

1 0

Multilevel marketing, invest only $20.00 and get $50,000 in 90 Days
by johh＠NETMANOR.COM 26 Sep '99

26 Sep '99

THE PROGRAM $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ INCREDIBLE $0 to $50,000 in 90 days!!! Dear Friend, You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details. "AS SEEN ON NATIONAL TV" Thank you for your time and interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. HERE IT IS BELOW: *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days ! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response: "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. In less than one week, I was starting to receive orders for REPORT #1 By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!! ! Remember, it won't work if you don't try it. This program does work , but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945.I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS!I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if youdon't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! -- When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. -- Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested,and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do justthat, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5.......................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).....$50,000 THIS TOTALS ---------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER and NAME *** Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. -- Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: A.D.Lee P.O. Box 939 Ft. Pierce, Fl 34954 REPORT #2;The Insiders Guide to Sending Bulk E-mail on the Internet ORDER REPORT #2 FROM: Tom A. Laios Laios & Associates 380 Mercure Laval, Qc H7X 3S8 Canada REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: Creative Aid 19425 Soledad Cyn Ste B-136 Santa Clarita, Ca. 91351-2600 REPORT #4;How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet; ORDER REPORT #4 FROM: Heidi Lupi c/o H J Resources, P. O. Box 14434 North Palm Beach, Fl 33408 About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* -- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don 't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at vinx2(a)usa.net /////////////////////////////////////////////////////////////////

2 1

H283 decided document is available
by Mark Duckworth 25 Sep '99

25 Sep '99

I uploaded it to the ftp site. ftp://standard.pictel.com/avc-site/Incoming/H283_decided.zip Mark

2 1

Re: Hard Copies of Red Bank contributions
by Euchner Martin 24 Sep '99

24 Sep '99

does this mean, that the bulk of paper can safely stay at home and we do not have to bring paper copies with us? Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Glen Freundlich [SMTP:ggf@LUCENT.COM] Sent: Thursday, September 23, 1999 7:41 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Hard Copies of Red Bank contributions We plan to have network access for all attendees, so would encourage attendees to work in a paperless mode. In addition, we do not plan to reproduce paper documents. Regards, Glen Euchner Martin wrote: > I'm also a bit concerned about that enormous number of copies to bring in. > > Do we have some experiences from the Berlin Meeting, how many copies actually have been used? I assume that this number is far below 80. May be 40 is still sufficient. > > Alternatively, it might be a good idea to print 2 pages on one sheet in order to save trees and reduce weight! > > Martin. > ----------------------------------------------------------------------- > | Dipl.-Inf. Phone: +49 89 636-46201 > | Martin Euchner Fax : +49 89 636-48000 > | Siemens AG > | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html > | Otto-Hahn-Ring 6 Internet: http://www.siemens.de > | D-81730 Muenchen > | __________________ > | Germany > ----------------------------------------------------------------------- > > -----Original Message----- > From: Karl.Klaghofer(a)ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] > Sent: Wednesday, September 22, 1999 3:37 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Hard Copies of Red Bank contributions > > The meeting notice states "bring 80 copies of your document to Red Bank if > it should be in hardcopy". > > Is there a clear rule whether hard copies are required at the meeting or not > ? > > Remark: 80 copies of voluminous contributions (e.g. updated draft standards) > is a lot of pounds ! > > Thanks, > Karl Klaghofer > > ------------------------------------------------ > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 > Hofmannstr. 51, D-81359 Munich, Germany > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > e-mail: karl.klaghofer(a)icn.siemens.de -- 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

3 2

APC number
by jaakko.sundquist＠NOKIA.COM 24 Sep '99

24 Sep '99

Could I be allocated an APC number for TITLE: Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) Thanks in advance - Jaakko Sundquist, Nokia ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

APC Document number
by Noriko Hosokawa 24 Sep '99

24 Sep '99

Dear Mr.Karl Klaghofer In response to your request, APC-1658 has been allocated to your contribution. APC-1658 > Source: Editor (K Klaghofer) > Title: Draft H.450.9 Call Completion Supplementary Services for H.323 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 1660 1661 ----------------------------------------------------------------------------

1 0

Fw: Contribution number
by Noriko Hosokawa 24 Sep '99

24 Sep '99

Dear Mr.Francois Audet In response to your request, APC-1656 and APC-1657 have been allocated to your contributions. > Source: Nortel Networks APC-1656 > Title: Tunnelling of signalling messages in H.225.0 APC-1657 > Title : Applicability of signalling tunnelling mechanism to Q.SIG 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 1660 1661 ---------------------------------------------------------------------------- ----

1 0

ICIP-99 and Packet Video 2000
by Sakae OKUBO 24 Sep '99

24 Sep '99

Dear SG16 colleagues, Please find attached the following calls in the areas close to that of our standardization efforts: - ICIP-99 Call for participation, 24-28 October 1999 in Kobe (Japan) - Packet Video Workshop Call for papers, 1-2 May 2000 in Cagliari (Italy) 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 *********************************************************** ------------------------< ICIP-99 >------------------------------- ICIP-99 Tutorials The IEEE 1999 International Conference on Image Processing October 24-28, 1999, International Conference Center Kobe - Kobe, JAPAN Tutorials will be held Sunday, October 24, 1999 Please select from below, and note that some sessions are given in parallel. Tutorial day is Sunday, October 24, 1999. Tutorials Cost 12,000 JPY for Non-Students and 6,000 JPY for Students who register in advance, 17,000 JPY and 6,000 JPY for those who register after September 6, 1999 or later, respectively. Tutorial-only registration will be available exclusively on-site. All-Day Session: 9:00 AM-12:00 Noon & 2:00 PM-5:00 PM Session SF1: Introduction to Multimedia Systems and Standards A. M. Tekalp (Univ. of Rochester) , A. Puri (ATT Research Labs.) Morning Tutorials (Select One): 9:00 AM-12:00 Noon Session SA1: Content Security & Data Hiding in Digital Media A.N. Akansu (New Jersey Inst. of Tech.), E.J. Delp (Purdue Univ.) Session SA2: Intelligent Multimedia Processing T.Chen (Carnegie-Mellon Univ.), J.N.Hwang (Univ. of Washington), S.Y. Kung (Princeton Univ.) Session SA3: Model-Based Halftoning T. N. Papas (Bell Laboratories, Lucent Technologies), D. L. Neuhoff (Univ. of Michigan) Afternoon Sessions (Select One): 2:00 PM-5:00 PM Session SP1: The JPEG 2000 C. Christopulos (Ericsson Telecom), A. N. Skodras (Univ. of Patras) Session SP2: Biometrics: Techniques for Personal Identification A. K. Jain (Michigan State Univ.) , L. Hong (Visionics), S. Pankanti (IBM T. J. Watson Research Center) Session SP3: Introduction to Medical Image Processing M. Analoui (Indiana Univ.) Session SP4: Image and Video Recovery Aggelos K. Katsaggelos (Northwestern Univ.) Early Registration Deadline September 6, 1999 For more details on the rest of the ICIP-99 program, visit: http://icip99.ozawa.ics.keio.ac.jp/ General Chair:Yasuhiko Yasuda, Waseda University Conference Manager: Shingo Abe, J Communications, Email: abes(a)pop16.odn.ne.jp ------------------------< PV-2000 >----------------------------- CALL FOR PAPERS --------------- ================= PACKET VIDEO 2000 ================= The 10th International Packet Video Workshop 1-2 May 2000 Forte Village Resort, Cagliari, Sardinia, Italy http://www.diee.unica.it/pv2000/ ------------------------------------------------------------------------ The 10-th edition of the International Packet Video Workshop (PV 2000) will be held in the middle of the Mediterranean Sea, at the Forte Village Resort near Cagliari (Sardinia island), Italy. The workshop is devoted to present technological advancements and innovations in video communications over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to welcome you in Sardinia in May 2000 for what will be a rewarding and exciting experience! Francesco G.B. De Natale and Daniele D. Giusto PV2000 General Chairs, University of Cagliari, Italy ---------------------------------------------------------------------- TECHNICAL COMMITTEE CHAIRS Leonardo Chiariglione, CSELT, Italy Maurizio D $B=D (Bina, Cefriel and Politecnico di Milano, Italy ---------------------------------------------------------------------- TECHNICAL COMMITTEE (members) John Arnold, Univ. New South Wales, Australia Andrea Basso, AT&T, USA Stephen Casner, CISCO, USA Shih-Fu Chang, Columbia University, USA M. Reha Civanlar, AT&T, USA Jon Crowcroft, Univ. College London, UK Edward Delp, Purdue Univ., USA Touradj Ebrahimi, EPFL, Switzerland Mohamed Ghanbari, Univ. Essex, UK Barry G. Haskell, AT&T, USA Yu Hen Hu, Univ. Wisconsin, USA Aggelos Katsaggelos, Northwestern Univ., USA Jae-Kyoon Kim, Samsung, Korea Faouzi Kossentini, Univ. British Columbia, Canada C.-C. Jay Kuo, Univ. Southern California, USA Steven McCanne, U.C. Berkeley, USA James Modestino, Rensselaer Polytechnic Institute, USA Geoff Morrison, BT, UK Hans-Georg Musmann, TU Hannover, Germany Sakae Okubo, Telecommunications Adv. Org., Japan Naohisa Ohta, Sony, Japan Joerg Ott, Univ. Bremen, Germany Fernando Pereira, Instituto Superiore T $B;D (Bnico, Portugal Majid Rabbani, Eastman Kodak, USA Amy Reibman, AT&T, USA Philippe Salembier, UPC, Spain Henning Schulzrinne, Columbia Univ., USA Gary Sullivan, Microsoft, USA A. Murat Tekalp, Univ. Rochester, USA Thierry Turletti, INRIA, France John Woods, Rensselaer Polytechnic Institute, USA Stephan Wenger, TU Berlin, Germany Hiroshi Yasuda, Tokyo Univ., Japan ------------------------------------------------------------------------ PUBLICATIONS AND DEMOS Luigi Atzori, University of Cagliari, Italy ------------------------------------------------------------------------ TECHNICAL PROGRAM The technical program of Packet Video 2000 will consist of invited talks, submitted paper presentations, poster sessions and demos. Topics of interest include, but are not limited to: Video processing and transmission Video streaming over the Internet Network adaptive video coding and transport Packetized video for home LANs Packetized video for wireless/mobile systems Packet video protocols and storage formats Layered coding for error resilience and heterogeneous networks Packet loss resilient coding and transport Terminal and server architectures for Internet TV Efficient transcoding for heterogeneous networks Congestion control Error concealment Pre and post-processing for picture quality enhancement Statistical multiplexing for greater network and terminal utilization Traffic shaping for efficient network and terminal utilization Interstream synchronization for multiple video presentations Packet network performance modeling and evaluation Rate control for VBR video Standards: MPEG4, MPEG7, H.263, H.323, RTP, RTSP, SIP, SDP Multicasting, MBONE applications Implementations and commercial applications ------------------------------------------------------------------------ BEST PAPER AWARD The author of the best paper will receive a $250 prize and a diploma suitable for framing. ------------------------------------------------------------------------ SUBMISSIONS Please submit an electronic manuscript written in Word or HTML, not exceeding 10 printed pages. We will produce a CD-ROM (pdf format) containing all the accepted papers. Submit your work in ONE of the following forms: 1) a Word document OR 2) a set of HTML files organized in a single directory to: pv2000(a)diee.unica.it Detailed instructions for authors and help with manuscript preparation can be found on the conference web page. ------------------------------------------------------------------------ SUBMISSION DEADLINES Paper submission: December 15, 1999, Notification of acceptance: February 29, 2000 Final paper delivery: March 31, 2000 ------------------------------------------------------------------------ LOCAL ARRANGEMENTS PV2000 Organizing Committee Dept. of Electrical and Electronic Engineering University of Cagliari Piazza d'Armi 09123 Cagliari, Italy pv2000(a)diee.unica.it

1 0

Re: Megaco/H.248 reqs -06
by Tom-PT Taylor 24 Sep '99

24 Sep '99

No. I never did get to talk to you in Oslo. Sorry about that, but maybe we can get together in Redbank. Tom Taylor > -----Original Message----- > From: Irina Suconick [SMTP:isuconick@VIDEOSERVER.COM] > Sent: Tuesday, September 21, 1999 4:41 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Megaco/H.248 reqs -06 > > This document mentions H.248 MG requirements for the MIB. Is any > work being started on the MIB? > Irina. > > > > -----Original Message----- > > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > > Sent: Monday, September 20, 1999 10:39 PM > > To: ITU-SG16(a)mailbag.cps.INTEL.com > > Subject: Megaco/H.248 reqs -06 > > > > The text below lists additions and clarifications made to > > <draft-ietf-megaco-reqs-05.txt>, and now found in > > <draft-ietf-megaco-reqs-06.txt>. > > > > Until it is available in the IETF I-D directory, you can get a copy of > it > > at: ftp://standards.nortelnetworks.com/megaco/docs/latest > > > > It includes clarifications asked for by ITU-T SG16 at their Berlin > > meeting. > > > > If there are no more comments on this requirements draft, then I would > > ask Tom Taylor to send it for WG last call. > > > > Note that there are references to fill in, and a few editor's notes to > > remove. I will do this in a few days if there are no other comments. > > > > Nancy > > > > > > ------------- > > > > > > 5.4. Signal/Event Processing and Scripting > > > > l. Provide an extension mechanism for implementation defined events > > and signals with, for example, IANA registration procedures. [ADD > > FOLLOWING > > SENTENCE:]It may be useful to have an Organizational Identifier (i.e. > ITU, > > ETSI, > > ANSI. . .) as part of the registration mechanism. > > > > 5.6. Test Support > > > > b. Specifically support [DELETE103, 105, and 108 ] test line operation > > [ADD] > > (e.g. > > 103, 105, 108). > > > > > > 5.8. Signalling Control > > > > Establishment and provisioning of signalling backhaul channels (via > > SIGTRAN for example is out of scope. [QUESTION: WHY was this marked as > out > > of > > scope?] Answer: it has been decided that this capability is not > > fundamental > > to the protocol, so can be kept out of scope, and handled some other > way. > > > > 6.1. Resource Status Management > > > > c. Provide a method for the MGC to request that the MG release all > > resources [ADD THE FOLLOWING] under the control of a particular MGC [END > > OF > > ADD] > > currently in use, or reserved, for any or all connections. > > > > 6.2. Resource Assignment > > > > c. Allow the use of DNS names and IP addresses to identify MGs and > > MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other > > identifiers > > for MGs or MGCs when other non IP transport technologies for the > protocol > > are > > used. > > > > > > 8.1 MG-MGC Association Requirements > > > > b. Allow multiple MGCs to send control messages to an MG. Thus, the > > protocol must allow control messages from multiple [DELETE] IP > > [ADD]signalling > > addresses to a single MG. > > > > 7.3 MIB Requirements > > > > [ADD c.] > > c. H.248 MG MIB must support spirit of H.341 by either the MG, MGC, or > > both > > acting > > together. > > > > > > 8.2. Performance Requirements > > > > d. Support peak calling rates (e.g. in the order of 140 calls/second) > at > > the > > MGC on a moderately loaded [DELETE IP] IP network. > > > > > > 11. Requirements specific to particular bearer types > > > > Table 1: Bearer Types and Applications > > > > Bearer Type Applications Transit Network > > ================================================================ > > > > [ADD FR] > > > > Multimedia H.323 H.323 Multimedia IP, ATM, FR > > Gateway and MCU > > [REPLACE SS7 with IP, ATM, FR] > > Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR > > > > > > 11.1.1. Requirements for TDM PSTN (Circuit) > > > > b. Missing - inconsistent numbering - renumber section > > > > > > 11.1.3.3. Media adaptation > > > > b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls to be mapped > to > > a > > single > > VCC. > > [ADD For AAL2] For AAL2, these calls are differentiated within each > > VCC > > by a AAL2 > > channel > > identifier. An AAL2 connection may span more than 1 VCC and transit > > AAL2 switching devices. ATMF standards are working on an end-to-end > > AAL2 connection identifier as part of the AAL2 signalling > > set.[REPLACE > > LAST > > SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end identifier the Served > > User > > Generated Reference (SUGR). It carries information from the originating > > user > > of the > > AAL2 signalling protocol to the terminating user transparently and > > unmodified. > > > > > > 11.2.10. Multipoint Control Units > > > > [ADD g.] > > g. The ability for the MG to function as an H.323 MP, and for the MGC to > > function > > as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should > be > > possible > > for audio, data, and video MG/MPs to be physically separate while being > > under the > > control of a single MGC/H.323 MC. > > -------------- > > > > > -------------------------------------------------------------------------- > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Hard Copies of Red Bank contributions
by Euchner Martin 23 Sep '99

23 Sep '99

I'm also a bit concerned about that enormous number of copies to bring in. Do we have some experiences from the Berlin Meeting, how many copies actually have been used? I assume that this number is far below 80. May be 40 is still sufficient. Alternatively, it might be a good idea to print 2 pages on one sheet in order to save trees and reduce weight! Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Karl.Klaghofer(a)ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, September 22, 1999 3:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Hard Copies of Red Bank contributions The meeting notice states "bring 80 copies of your document to Red Bank if it should be in hardcopy". Is there a clear rule whether hard copies are required at the meeting or not ? Remark: 80 copies of voluminous contributions (e.g. updated draft standards) is a lot of pounds ! Thanks, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

Upload of White Paper for Version 6 of H.245
by mike.nilsson＠BT.COM 23 Sep '99

23 Sep '99

I have uploaded a draft of the White Paper for version 6 of H.245 to: ftp://standard.pictel.com/avc-site/Incoming/h245wcmj.zip Please send comments as soon as possible as this will have to be submitted to the ITU at the end of September. Best regards Mike Nilsson ********************************************************************** * 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 * **********************************************************************

3 2

Re: Upload of White Paper for Version 6 of H.245
by mike.nilsson＠BT.COM 23 Sep '99

23 Sep '99

Rich, There is nothing in the latest version of H.245 relating to this. My understanding is that we sent a liaison to SG8 identifying two possible solutions to the problem, and gave them a deadline of 18 October (i.e. The New Jersey meeting) for response. Hopefully the issue can be resolved in NJ and the result included in H.245 V6 in February. Best regards Mike ********************************************************************** * 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: Rich Bowen [SMTP:rkbowen@CISCO.COM] > Sent: Wednesday, September 22, 1999 7:17 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Upload of White Paper for Version 6 of H.245 > > Mike, > > In the Berlin meeting report, APC-1644a, it was noted that there > was an inconsistency in the ASN.1 with respect to T.38. A liaison > (TD-43a) was to be sent to SG 8 suggesting two possible solutions > in H.245 v6, but no decision was indicated as to which of the > two solutions would be used. > > Do you know the current status of this issue? I noticed that neither > of the suggested solutions appears in the white paper for H.245 v6. > > Thanks, > Rich > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > rkbowen(a)cisco.com Research Triangle Park, NC > -------------------------------------------------------------------- > mike.nilsson(a)BT.COM wrote: > > > > I have uploaded a draft of the White Paper for version 6 of H.245 to: > > > > ftp://standard.pictel.com/avc-site/Incoming/h245wcmj.zip > > > > Please send comments as soon as possible as this will have to be > submitted > > to the ITU at the end of September. > > > > Best regards > > > > Mike Nilsson > > > > ********************************************************************** > > * 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 * > > **********************************************************************

1 0

Hard Copies of Red Bank contributions
by Karl.Klaghofer＠ICN.SIEMENS.DE 22 Sep '99

22 Sep '99

The meeting notice states "bring 80 copies of your document to Red Bank if it should be in hardcopy". Is there a clear rule whether hard copies are required at the meeting or not ? Remark: 80 copies of voluminous contributions (e.g. updated draft standards) is a lot of pounds ! Thanks, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

AW: H.450 support
by Karl.Klaghofer＠ICN.SIEMENS.DE 22 Sep '99

22 Sep '99

Alex, The B side that does not support H.450 may just ignore the received supplementary service request. I.e. ROSE at the originating side has to figure out that the other side does not support H.450 (i.e. if no return result, return error or return reject is received from B to a supplementary service request). Although the User-User Information element itself is mandatory, the h4501SupplementaryService apdu is optional. Even in Q.931, sending a STATUS message in case of "optional, unrecognized Information elements received" is just optional. I.e., I recommend not to rely on receiving a STATUS message from the B side in your scenario. In a similar case - in case of optional information element received with contents error - H.323 Implementers guide even requires to just ignore the IE (but act on the rest of the message). Note: If at least H.450.1 is supported by the B side, then B has to respond according to the "interpretation apdu" setting. Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Alex Chatilov [SMTP:achatilov@email.msn.com] > Gesendet am: Donnerstag, 16. September 1999 07:57 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450 support > > Hello, > > I have a question about how to detect does remote endpoint supports H.450 > (without using a timer)? Is it clear that receiving endpoint has to replay > with a STATUS message in case when it receive an H.450 related FACILITY > message? > > Assume that we have: > > Originator side sent: > -------------------- > > FACILITY > FacilityIE > (length=0) > ... > User-UserIE > H323-UserInformation > h323-UU-PDU > h323-message-body = empty > ... > h4501SupplementaryService > (H.450.x request) > ... > ... > ... > > Remote side received FACILITY, here is no > support for H.450, so we will respond with > STATUS message where the causeIE = > 100 (invalid IE contents), or > 99 (Information element/parameter non-existent > or not implemented), or > 97 (Message type non-existent or not implemented) > > STATUS > ... > CauseIE > ... > cause = XX > diagnostics = YY > ... > > Am I right? > > Thank you, > Alex

1 0

Re: Megaco/H.248 reqs -06
by Brian Rosen 21 Sep '99

21 Sep '99

No, want to start such an effort? Volunteers accepted! Brian > -----Original Message----- > From: Irina Suconick [mailto:isuconick@VIDEOSERVER.COM] > Sent: Tuesday, September 21, 1999 4:41 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Megaco/H.248 reqs -06 > > > This document mentions H.248 MG requirements for the > MIB. Is any > work being started on the MIB? > Irina. > > > > -----Original Message----- > > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > > Sent: Monday, September 20, 1999 10:39 PM > > To: ITU-SG16(a)mailbag.cps.INTEL.com > > Subject: Megaco/H.248 reqs -06 > > > > The text below lists additions and clarifications made to > > <draft-ietf-megaco-reqs-05.txt>, and now found in > > <draft-ietf-megaco-reqs-06.txt>. > > > > Until it is available in the IETF I-D directory, you can > get a copy of it > > at: ftp://standards.nortelnetworks.com/megaco/docs/latest > > > > It includes clarifications asked for by ITU-T SG16 at their Berlin > > meeting. > > > > If there are no more comments on this requirements draft, > then I would > > ask Tom Taylor to send it for WG last call. > > > > Note that there are references to fill in, and a few > editor's notes to > > remove. I will do this in a few days if there are no other comments. > > > > Nancy > > > > > > ------------- > > > > > > 5.4. Signal/Event Processing and Scripting > > > > l. Provide an extension mechanism for implementation > defined events > > and signals with, for example, IANA registration > procedures. [ADD > > FOLLOWING > > SENTENCE:]It may be useful to have an Organizational > Identifier (i.e. ITU, > > ETSI, > > ANSI. . .) as part of the registration mechanism. > > > > 5.6. Test Support > > > > b. Specifically support [DELETE103, 105, and 108 ] test > line operation > > [ADD] > > (e.g. > > 103, 105, 108). > > > > > > 5.8. Signalling Control > > > > Establishment and provisioning of signalling backhaul channels (via > > SIGTRAN for example is out of scope. [QUESTION: WHY was > this marked as out > > of > > scope?] Answer: it has been decided that this capability is not > > fundamental > > to the protocol, so can be kept out of scope, and handled > some other way. > > > > 6.1. Resource Status Management > > > > c. Provide a method for the MGC to request that the MG release all > > resources [ADD THE FOLLOWING] under the control of a > particular MGC [END > > OF > > ADD] > > currently in use, or reserved, for any or all connections. > > > > 6.2. Resource Assignment > > > > c. Allow the use of DNS names and IP addresses to identify MGs and > > MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other > > identifiers > > for MGs or MGCs when other non IP transport technologies > for the protocol > > are > > used. > > > > > > 8.1 MG-MGC Association Requirements > > > > b. Allow multiple MGCs to send control messages to an MG. > Thus, the > > protocol must allow control messages from multiple [DELETE] IP > > [ADD]signalling > > addresses to a single MG. > > > > 7.3 MIB Requirements > > > > [ADD c.] > > c. H.248 MG MIB must support spirit of H.341 by either the > MG, MGC, or > > both > > acting > > together. > > > > > > 8.2. Performance Requirements > > > > d. Support peak calling rates (e.g. in the order of 140 > calls/second) at > > the > > MGC on a moderately loaded [DELETE IP] IP network. > > > > > > 11. Requirements specific to particular bearer types > > > > Table 1: Bearer Types and Applications > > > > Bearer Type Applications Transit Network > > ================================================================ > > > > [ADD FR] > > > > Multimedia H.323 H.323 Multimedia > IP, ATM, FR > > Gateway and MCU > > [REPLACE SS7 with IP, ATM, FR] > > Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR > > > > > > 11.1.1. Requirements for TDM PSTN (Circuit) > > > > b. Missing - inconsistent numbering - renumber section > > > > > > 11.1.3.3. Media adaptation > > > > b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls > to be mapped to > > a > > single > > VCC. > > [ADD For AAL2] For AAL2, these calls are > differentiated within each > > VCC > > by a AAL2 > > channel > > identifier. An AAL2 connection may span more than 1 > VCC and transit > > AAL2 switching devices. ATMF standards are working on > an end-to-end > > AAL2 connection identifier as part of the AAL2 signalling > > set.[REPLACE > > LAST > > SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end > identifier the Served > > User > > Generated Reference (SUGR). It carries information from the > originating > > user > > of the > > AAL2 signalling protocol to the terminating user transparently and > > unmodified. > > > > > > 11.2.10. Multipoint Control Units > > > > [ADD g.] > > g. The ability for the MG to function as an H.323 MP, and > for the MGC to > > function > > as an H.323 MC, connected by this protocol (MEGACOP/H.248). > It should be > > possible > > for audio, data, and video MG/MPs to be physically separate > while being > > under the > > control of a single MGC/H.323 MC. > > -------------- > > > > > -------------------------------------------------------------- > ------------ > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

Re: Megaco/H.248 reqs -06
by Irina Suconick 21 Sep '99

21 Sep '99

This document mentions H.248 MG requirements for the MIB. Is any work being started on the MIB? Irina. > -----Original Message----- > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > Sent: Monday, September 20, 1999 10:39 PM > To: ITU-SG16(a)mailbag.cps.INTEL.com > Subject: Megaco/H.248 reqs -06 > > The text below lists additions and clarifications made to > <draft-ietf-megaco-reqs-05.txt>, and now found in > <draft-ietf-megaco-reqs-06.txt>. > > Until it is available in the IETF I-D directory, you can get a copy of it > at: ftp://standards.nortelnetworks.com/megaco/docs/latest > > It includes clarifications asked for by ITU-T SG16 at their Berlin > meeting. > > If there are no more comments on this requirements draft, then I would > ask Tom Taylor to send it for WG last call. > > Note that there are references to fill in, and a few editor's notes to > remove. I will do this in a few days if there are no other comments. > > Nancy > > > ------------- > > > 5.4. Signal/Event Processing and Scripting > > l. Provide an extension mechanism for implementation defined events > and signals with, for example, IANA registration procedures. [ADD > FOLLOWING > SENTENCE:]It may be useful to have an Organizational Identifier (i.e. ITU, > ETSI, > ANSI. . .) as part of the registration mechanism. > > 5.6. Test Support > > b. Specifically support [DELETE103, 105, and 108 ] test line operation > [ADD] > (e.g. > 103, 105, 108). > > > 5.8. Signalling Control > > Establishment and provisioning of signalling backhaul channels (via > SIGTRAN for example is out of scope. [QUESTION: WHY was this marked as out > of > scope?] Answer: it has been decided that this capability is not > fundamental > to the protocol, so can be kept out of scope, and handled some other way. > > 6.1. Resource Status Management > > c. Provide a method for the MGC to request that the MG release all > resources [ADD THE FOLLOWING] under the control of a particular MGC [END > OF > ADD] > currently in use, or reserved, for any or all connections. > > 6.2. Resource Assignment > > c. Allow the use of DNS names and IP addresses to identify MGs and > MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other > identifiers > for MGs or MGCs when other non IP transport technologies for the protocol > are > used. > > > 8.1 MG-MGC Association Requirements > > b. Allow multiple MGCs to send control messages to an MG. Thus, the > protocol must allow control messages from multiple [DELETE] IP > [ADD]signalling > addresses to a single MG. > > 7.3 MIB Requirements > > [ADD c.] > c. H.248 MG MIB must support spirit of H.341 by either the MG, MGC, or > both > acting > together. > > > 8.2. Performance Requirements > > d. Support peak calling rates (e.g. in the order of 140 calls/second) at > the > MGC on a moderately loaded [DELETE IP] IP network. > > > 11. Requirements specific to particular bearer types > > Table 1: Bearer Types and Applications > > Bearer Type Applications Transit Network > ================================================================ > > [ADD FR] > > Multimedia H.323 H.323 Multimedia IP, ATM, FR > Gateway and MCU > [REPLACE SS7 with IP, ATM, FR] > Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR > > > 11.1.1. Requirements for TDM PSTN (Circuit) > > b. Missing - inconsistent numbering - renumber section > > > 11.1.3.3. Media adaptation > > b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls to be mapped to > a > single > VCC. > [ADD For AAL2] For AAL2, these calls are differentiated within each > VCC > by a AAL2 > channel > identifier. An AAL2 connection may span more than 1 VCC and transit > AAL2 switching devices. ATMF standards are working on an end-to-end > AAL2 connection identifier as part of the AAL2 signalling > set.[REPLACE > LAST > SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end identifier the Served > User > Generated Reference (SUGR). It carries information from the originating > user > of the > AAL2 signalling protocol to the terminating user transparently and > unmodified. > > > 11.2.10. Multipoint Control Units > > [ADD g.] > g. The ability for the MG to function as an H.323 MP, and for the MGC to > function > as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should be > possible > for audio, data, and video MG/MPs to be physically separate while being > under the > control of a single MGC/H.323 MC. > -------------- > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Security - H.235 message integrity
by Euchner Martin 21 Sep '99

21 Sep '99

Douglas, thanks a lot for the detailed explanation. I'm quite convinced now that the substitution method really works without the versioning drawback of the emptying method. As I do not have a clear feeling what the other people think about this approach; I added your substitution method as proposal to the Annex J profile for the time being. Discussion should resolve which way to go.... Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU] Sent: Monday, September 20, 1999 11:55 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Security - H.235 message integrity Martin, Firstly, I hope that the mechanism for encoding the HMAC is well understood, and the reason for using HMAC-SHA1-96 (RFC-2404). Secondly, the decoding: The message which arrives is a bucket of bits, inside a TPKT. (It would be nice to have something in the TPKT to tell us whether the message contained is encrypted, but it doesn't. :-( ) If it's encrypted, assume you can tell and decrypt it. This is what the HMAC has been calculated over, with the HMAC field set to zeroes. Decode the message and extract the HMAC from the data tree. This bit string occurs in the message where the HMAC is stored, and it is a random pattern produced by the HMAC function of the sender - it is *very* unlikely to occur in the message more than once. Search the message for the bitstring, if you don't find it, check your source code and PER decoder. To be safe, copy the message to a buffer, set the located bitstring to zero in the copy, and compute the HMAC. If it matches, the message is OK. If the HMAC does not match, search from the previously located bitstring plus one. If you get a second match - copy, zero-fill, compute-HMAC and compare as before. Repeat until you get to the end of the message or match the HMAC. No re-encoding of the message is required, nor is it desirable. Apart from retrieving the HMAC from the message, the HMAC location and recomputation is completely independent of whether the message is RAS or Annex G, much less which version. Hence it is completely version-safe. For non-repudiation, you must use public-private key pairs and certificates. The message is signed by computing the HASH as above, and then encrypting that hash with the private key.The receiver computes the HASH as before, decrypts with the public key, and compares the result. If they match, the message is OK, and was created by the holder of the private key. If a proxy is to change components, then the proxy will have to recompute the MAC (keyed or signed) using its own credentials. In this case it is the proxy that is attempting to guarantee the integrity and authenticity of the message, so the EP MAC is destroyed. If you want to just authenticate just a few fields, so a proxy/firewall can change parts of the message, and the other endpoint can check the few, it is best to compute the authentication code on the unencoded fields. This can be done in a hashed CryptoToken, with the hashed values included or not in the CryptoToken. Extreme care must be taken to ensure that the rules for encoding the ToBeHashed are well specified. Regards, Douglas At 19:08 1999-09-20 +0200, Euchner Martin wrote: >Douglas, > >first of all, I'm glad to see a very interesting and fruitful discussion here. Thus, I would rather carry on these specific topics about the syntax and procedures on the SG16 discussion list and hear also other people's opinions about that. > [snip]

1 0

APC Document number
by Noriko Hosokawa 21 Sep '99

21 Sep '99

Dear Mr.Toshiaki Suzuki In response to your request, APC-1655 has been allocated to your contribution. APC-1655 > Title : Real-time system of H.262 layered video transmission > Source : Hitachi Ltd. 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 Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 1657 ---------------------------------------------------------------------------- ----

1 0

Megaco/H.248 reqs -06
by Nancy-M Greene 21 Sep '99

21 Sep '99

The text below lists additions and clarifications made to <draft-ietf-megaco-reqs-05.txt>, and now found in <draft-ietf-megaco-reqs-06.txt>. Until it is available in the IETF I-D directory, you can get a copy of it at: ftp://standards.nortelnetworks.com/megaco/docs/latest It includes clarifications asked for by ITU-T SG16 at their Berlin meeting. If there are no more comments on this requirements draft, then I would ask Tom Taylor to send it for WG last call. Note that there are references to fill in, and a few editor's notes to remove. I will do this in a few days if there are no other comments. Nancy ------------- 5.4. Signal/Event Processing and Scripting l. Provide an extension mechanism for implementation defined events and signals with, for example, IANA registration procedures. [ADD FOLLOWING SENTENCE:]It may be useful to have an Organizational Identifier (i.e. ITU, ETSI, ANSI. . .) as part of the registration mechanism. 5.6. Test Support b. Specifically support [DELETE103, 105, and 108 ] test line operation [ADD] (e.g. 103, 105, 108). 5.8. Signalling Control Establishment and provisioning of signalling backhaul channels (via SIGTRAN for example is out of scope. [QUESTION: WHY was this marked as out of scope?] Answer: it has been decided that this capability is not fundamental to the protocol, so can be kept out of scope, and handled some other way. 6.1. Resource Status Management c. Provide a method for the MGC to request that the MG release all resources [ADD THE FOLLOWING] under the control of a particular MGC [END OF ADD] currently in use, or reserved, for any or all connections. 6.2. Resource Assignment c. Allow the use of DNS names and IP addresses to identify MGs and MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other identifiers for MGs or MGCs when other non IP transport technologies for the protocol are used. 8.1 MG-MGC Association Requirements b. Allow multiple MGCs to send control messages to an MG. Thus, the protocol must allow control messages from multiple [DELETE] IP [ADD]signalling addresses to a single MG. 7.3 MIB Requirements [ADD c.] c. H.248 MG MIB must support spirit of H.341 by either the MG, MGC, or both acting together. 8.2. Performance Requirements d. Support peak calling rates (e.g. in the order of 140 calls/second) at the MGC on a moderately loaded [DELETE IP] IP network. 11. Requirements specific to particular bearer types Table 1: Bearer Types and Applications Bearer Type Applications Transit Network ================================================================ [ADD FR] Multimedia H.323 H.323 Multimedia IP, ATM, FR Gateway and MCU [REPLACE SS7 with IP, ATM, FR] Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR 11.1.1. Requirements for TDM PSTN (Circuit) b. Missing - inconsistent numbering - renumber section 11.1.3.3. Media adaptation b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls to be mapped to a single VCC. [ADD For AAL2] For AAL2, these calls are differentiated within each VCC by a AAL2 channel identifier. An AAL2 connection may span more than 1 VCC and transit AAL2 switching devices. ATMF standards are working on an end-to-end AAL2 connection identifier as part of the AAL2 signalling set.[REPLACE LAST SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end identifier the Served User Generated Reference (SUGR). It carries information from the originating user of the AAL2 signalling protocol to the terminating user transparently and unmodified. 11.2.10. Multipoint Control Units [ADD g.] g. The ability for the MG to function as an H.323 MP, and for the MGC to function as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should be possible for audio, data, and video MG/MPs to be physically separate while being under the control of a single MGC/H.323 MC. -------------- -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Security - H.235 message integrity
by Douglas Clowes 20 Sep '99

20 Sep '99

Martin, Firstly, I hope that the mechanism for encoding the HMAC is well understood, and the reason for using HMAC-SHA1-96 (RFC-2404). Secondly, the decoding: The message which arrives is a bucket of bits, inside a TPKT. (It would be nice to have something in the TPKT to tell us whether the message contained is encrypted, but it doesn't. :-( ) If it's encrypted, assume you can tell and decrypt it. This is what the HMAC has been calculated over, with the HMAC field set to zeroes. Decode the message and extract the HMAC from the data tree. This bit string occurs in the message where the HMAC is stored, and it is a random pattern produced by the HMAC function of the sender - it is *very* unlikely to occur in the message more than once. Search the message for the bitstring, if you don't find it, check your source code and PER decoder. To be safe, copy the message to a buffer, set the located bitstring to zero in the copy, and compute the HMAC. If it matches, the message is OK. If the HMAC does not match, search from the previously located bitstring plus one. If you get a second match - copy, zero-fill, compute-HMAC and compare as before. Repeat until you get to the end of the message or match the HMAC. No re-encoding of the message is required, nor is it desirable. Apart from retrieving the HMAC from the message, the HMAC location and recomputation is completely independent of whether the message is RAS or Annex G, much less which version. Hence it is completely version-safe. For non-repudiation, you must use public-private key pairs and certificates. The message is signed by computing the HASH as above, and then encrypting that hash with the private key.The receiver computes the HASH as before, decrypts with the public key, and compares the result. If they match, the message is OK, and was created by the holder of the private key. If a proxy is to change components, then the proxy will have to recompute the MAC (keyed or signed) using its own credentials. In this case it is the proxy that is attempting to guarantee the integrity and authenticity of the message, so the EP MAC is destroyed. If you want to just authenticate just a few fields, so a proxy/firewall can change parts of the message, and the other endpoint can check the few, it is best to compute the authentication code on the unencoded fields. This can be done in a hashed CryptoToken, with the hashed values included or not in the CryptoToken. Extreme care must be taken to ensure that the rules for encoding the ToBeHashed are well specified. Regards, Douglas At 19:08 1999-09-20 +0200, Euchner Martin wrote: >Douglas, > >first of all, I'm glad to see a very interesting and fruitful discussion here. Thus, I would rather carry on these specific topics about the syntax and procedures on the SG16 discussion list and hear also other people's opinions about that. > [snip]

1 0

Contribution uploaded
by Francois Audet 20 Sep '99

20 Sep '99

Contribution APC-1654 ISO/IEC addressing in H.323 Appendix V has been uploaded to the incoming directory. ----- 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/>

1 0

Re: Security - H.235 message integrity
by Euchner Martin 20 Sep '99

20 Sep '99

Douglas, first of all, I'm glad to see a very interesting and fruitful discussion here. Thus, I would rather carry on these specific topics about the syntax and procedures on the SG16 discussion list and hear also other people's opinions about that. All my comments are in the text below. Regards, Martin ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Douglas Clowes [SMTP:dclowes@ozemail.com.au] Sent: Monday, September 20, 1999 3:00 AM To: Euchner Martin Cc: El-Gebaly, Hani; inowag(a)imtc.org Subject: RE: Security At 14:10 1999-09-17 +0200, Euchner Martin wrote: >Douglas and Hani, > > >first I would like to confirm, that Annex J applies the method as described by Hani in a previous mail. > >Let's assign some mnemonics to the procedures on the table for easier discussion and let's call this method the "emptying method" as the ICV/hash field is emptied before the calculation. > >Douglas proposed two alternative methods for computing ICVs or hash values: >The first method - let's call it the "substitution method" for short - works in a similar way as the emptying method except that there is only one ASN.1 pass and the hash/icv value has to be located in the coded ASN.1 by a particular (unambiguous) bit pattern. > >I would name the other proposed method as the "envelope method" as new ASN.1 syntax is put around the protected message. > >While it is true that the emptying method suffers from the versioning problem, I do not quite understand why this does not apply also to the substitution method. How does a receiver with a lower protocol version know which fields to exclude the recomputation of? Also I doubt that the trail and error method for locating the bitpattern is efficient. Firstly, I am assuming that the Message Authentication Code ((H)MAC) is being performed over the entire message. I'm not sure if this assumption is common to us all, hence I am explicitly stating it here. This implies that there are *no* fields to be excluded from any recomputation. This is correct. In "authenticaton & integrity" mode of Annex J, the (H)MAC is computed over the entire message after the message has been ASN.1 encoded into a bitstring. This step is done by the sender as well as the receiver. For your substitution method, I think you are right and the method described should work without any versioning problems. I guess that the crucial procedure at the receiver is roughly as follows: 1) receive the message 2) locate and find the sender's hash value; call this result RV. Actually, how does the receiver know where to find the hash bits in the message bitstring? The position of the hash value may vary from one RAS message to another. This sounds like a problem.... Any ideas please? The only way I could think of is to ASN.1 decode the message, and then re-encode it with a known (default) pattern and find that pattern in the received message. The position of the hash value in the received message should correspond to the found position of the known pattern. Is it guaranteed that this procedure works independently of protocol versions??? 3) reset the hash value bits in the received message to some default pattern, then recompute the keyed hash over the message; call the result HV 4) compare HV == RV etc .... Since the computation is over a bit string of unknown/indeterminate construction, versioning cannot affect the result, because at the time you generate or check the hash, you don't even care that it's an encoded message, much less PER encoded, or even ASN.1, or even RAS/Annex G - it's just a bit string. If I'm not clear on that, let me know and I'll try again to explain it. Secondly, as long as the "bitpattern" is sufficiently random, it is very unlikely to occur in the message randomly - one in 2^96, 2^128, or 2^160 depending on algorithm. Of course, if one uses zeroes or spaces or the gatekeeperId, it's more likely, but if one uses the HMAC from the previous message as the bitpattern, you might get a collision every few years/millenia. > >I'm not quite certain whether I fully understood the envelope method. Is it true that the BESTP could be a RRQ for example, while the ABESTP would be the actual message sent through the wire? How does this method address the versioning issue? What happens when BESTP sees some extensions? Again, the versioning is not an issue, because the thing that is being signed/encrypted is just a bitstring. The checking/decrypting independent of the contents. It's an encapsulation or tunnelling mechanism, independent of what is being encapsulated or tunnelled. >If this is the case then it is probably already far too late for changing to the envelope method if it works at all. It appears to me that H.225.0 would have to be changed fundamentally. Well, not really too late, and it could be made to work, but that is more properly a subject for the SG16 list, rather than the iNOW! list. Since the GRQ/GCF can indicate that the enveloped method is supported, and should be employed, it's just a simple versioning issue. This will test my understanding of ASN.1 and PER encoding... (someone correct me if I'm wrong). In H.225.0, RasMessage is a PDU and is identified in the encoded message by a tag value. I believe that H323-UserInformation is another. These are differentiated in an inbound PDU by their tag value (and channel). Let's invent a new H.225.0 PDU call SecurityMessage, defined as: SecurityMessage ::= SEQUENCE { encryptionAlgorithm OBJECT IDENTIFIER OPTIONAL, encryptionParams ParamS OPTIONAL, signatureAlgorithm OBJECT IDENTIFIER OPTIONAL, signatureParams ParamS OPTIONAL, messageText OCTET STRING, signatureText OCTET STRING OPTIONAL } toBeSecured TYPE-IDENTIFIER.&Type(RasMessage) The message could be signed, or encrypted, or signed and encrypted, or neither (in which case it should be just a plain RAS message). * Signed only: encode the RAS PDU into the toBeSecured octet string, and place in the messageText OCTET string. Compute the signature into signatureText. Set signatureAlgorithm and signatureParams with appropriate values. * Encrypted only: encode the RAS PDU into the toBeSecured OCTET string and encrypt, placing the ciphertext result into messageText. Set encryptionAlgorithm and encryptionParams with appropriate values. * Signed and Encrypted: encode the RAS PDU into the toBeSecure OCTET STRING. Compute the signature into signatureText. Encrypt toBeSecured into messageText. Set the algorithm OIDs and params with appropriate values. Possible variations include: o Encrypt the signatureText with the same algorithm and params used on messageText. o Next the signature structure within the encrypted structure - SecurityMessage ::= SEQUENCE { encryptionAlgorithm OBJECT IDENTIFIER OPTIONAL, encryptionParams ParamS OPTIONAL, encryptedText OCTET STRING, } SignedRasMessage { signatureAlgorithm OBJECT IDENTIFIER OPTIONAL, signatureParams ParamS OPTIONAL, signatureText OCTET STRING OPTIONAL, signedText OCTET STRING } ToBeEncrypted TYPE-IDENTIFIER.&Type(SignedRasMessage) ToBeSigned TYPE-IDENTIFIER.&Type(RasMessage) The process: encode the RAS message, as ToBeSigned, into signedText. If signing, set signatureAlgorithm and signatureParams and calculate signatureText. Encode SignedMessage into encryptedText. If encrypting, set encryptionAlgorithm and encryptionParams, and encrypt encryptedText. In either case, and in H.235 as it stands, ParamS would be redefined as: ParamS ::= SEQUENCE { ranInt INTEGER OPTIONAL, iv8 IV8 OPTIONAL, ..., keySequenceId INTEGER(0..??) OPTIONAL } to accommodate a change in keys for delayed and out of order message delivery. >Finally, the ICV field is no longer always at the end of the message as certain H.225.0 v3 RAS messages have been extended by new fields since version 2. Well, I had the H.225.0 AnnexG messages in mind when I said that, and even then, it's not literally true. But it doesn't matter logically, as long as you can find the correct part. >Comments please. > > >Regards > >Martin. > Regards, Douglas

1 0

Re: Questions on H.235
by Euchner Martin 20 Sep '99

20 Sep '99

Douglas, please see my answers below in the text. Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU] Sent: Monday, September 20, 1999 1:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Questions on H.235 At 12:01 1999-09-17 +0200, Euchner Martin wrote: >Douglas, > >as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security. > > >On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols). > >For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement. OK, I forgot the multicast case. However, the generalId should, IMHO, be either that of the recipient (unicast) or not present (multicast), rather than that of the sender as shown. H.235v2 fixes this. >Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented. While you're at it, 10.3.2 method for forming a key from a password is embarrassingly weak. A short password ('X' for example) produces a key which is mostly zero bits. Even a longer pass phrase will prod use a key with high order bits set to zero in each byte, and similar characteristics reducing a keys strength significantly. Most credible schemes would use a hash function (MD5 or SHA1) over the pass phrase, and would not fill out the pass phrase with zeroes. The amount of entropy in such a key will be very low, and one should not use such a key for bulk encryption. To do so would provide an attacker with a large amount of cryptotext, some of which will be known, enabling a known-cryptotext attacks. An additional key generation/exchange mechanism should be employed. It is true that 10.3.2 does not provide absolute security . A more secure way would be to use hashed passwords instead of the plain PW as you wrote. However, the entropy does not increase effectively by hashing. Thus, implementations should check and avoid weak passwords by some means. Anyway, the (hashed) password is not applied to bulk encryption; rather it is used for registration and authentication purposes. >Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2. In UDP based protocols, strict sequencing is not possible, because message order and delivery and duplication are not guaranteed. An eavesdropper can easily generate a sequence number in the range, so a legitimate message will duplicate an illegitimate message sequence number. A signature is a more secure check. a) correct: strict sequencing on UDP does not work. RAS/Annex J uses the randomVal as a counter, making several messages with the same timestamp unique. This allows to detect duplicated messages. b) When message integrity is applied to the entire message, an attacker no longer is able to generate fake messages just by guessing the counter, as the attacker cannot compute the correct hash without possessing the password. >Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J. Good. It should not be part of H.235 either. Even if we all agree to remove B.4.2, does the ITU procedure (maintaining backwards compatibility) allow us to do? >A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature. I understand that HMAC-xxx-96 gives away less information on the key, and should be preferred for a long term password based mechanism. Sounds as a good suggestion. Annex J will reflect this change. >Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Trouble is that, for a time, neither party knows that a message is lost. If I send you an xRQ and you send me a new random in the xCF, which random do you use to check my next message? It needs to be different depending on whether the xCF was lost or not. If you use the new one, and my next transmission is a retransmit of the original xRQ, will you reject it because it doesn't use the new random? You will have to check both. If I send you an xRQ that lives for a while in a router queue, receive a new random and use it in a message that arrives at you before the earlier one (out of order reception happens) and you check it against the new random, it matches. When the first message arrives, it has the old random. Will you reject it or ignore it? Either way, will I understand that I have to recompute it and send it again. If you reject it, I may fail the operation. If you ignore it, I may resend the same bit-pattern with the old random. This issue is closely linked with B.4.2; luckily, Annex J does not reference it. >Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile). Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and 2402). see some lines above: Annex J will use the truncated hashing I agree with you there, but wonder if it's better to sign the entire message, just the DH component, or both. Actually, Annex J offers both methods: signing the entire message or signing only a subset including the DH params. Regards, Douglas >Regards, > >Martin.

1 0

Media Gateway Control 99 : Call for paper
by Peter Lewis 20 Sep '99

20 Sep '99

Paris, France, 15-17 December 1999 Media Gateway Control 99 Conference. MGCP, Megaco, H.248. How to assure convergence between IP and PSTN networks. Technical challenges, trials, interoperability tests, normalization work. Call for papers: www.upperside.fr/bamgc.htm Thanks

1 0

reminder for Red Bank meeting
by Glen Freundlich 20 Sep '99

20 Sep '99

Dear Colleagues, This is just a reminder that the hotel where we are holding the upcoming Q.11-15 meeting will hold a block of rooms until this Wednesday, 22 September. Also, please remember to register for the meeting as described in the meeting announcement so that we can plan for the size of the meeting. 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

Re: Queries on RAS security !!
by Euchner Martin 20 Sep '99

20 Sep '99

Aparna, please note, that Jim Toga is no longer editor of H.235. I took over responsibility to carry on H.235 version 2. Anybody with questions, suggestions and improvements should get in touch with me therefore. 1. Relation of registration info by GK: The GK can associate the registration information through the delivered endpointID and callID. Further on, commercially available stacks offer identifications means by messages handles or simply IP addresses for example. All this could be useful in keeping track of state and context. 2. Key update: H.235 offers a key update (key refreshment) procedure for the media session key; this procedure is not applicable to RAS for the following reasons: a) Passwords are subscription-based information. The subscription procedure (registration, obtaining, refreshing PWs) are not part of the recommendation. This all can be achieved by some means out-of-band. By such a procedure you can also refresh your passwords of course. b) Diffie-Hellman keys act as a master key. There is no explicit key update procedure for such keys. Implicitly, you could terminate (close) the connection and immediately re-open/reregister; thereby establishing automatically a new key. Regards, Martin ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Aparna Saha [SMTP:apsaha@HSS.HNS.COM] Sent: Monday, September 20, 1999 6:45 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Queries on RAS security !! Hi Jim, I have a few queries related to H.235, specifically, RAS security. This is regarding the RAS procedures for authentication . During the GRQ-GCF exchange, the security info ( the secret key and the algorithmId ) gets established with the GK. For the subsequent RRQ, how does the GK relate the RRQ with the info stored ? Is there any mechanism for refreshing keys in RAS ? Thanks and regards, Aparna.

1 0

Registration of participation and contribution
by Sakae OKUBO 20 Sep '99

20 Sep '99

Dear Q12-14/16 experts, This is to encourage you to make the subject registrations as soon as possible. Rapporteurs need the final approval of the SG16 management for holding the Red Bank meeting where indication of a sufficient number of participants and contributions are required. 1. Registration of participation To register your meeting attendance, please send an e-mail registration of the following form: To: rrroy(a)att.com, eileen.patterson(a)ascend.com Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Red Bank meeting registration Name: Company: Arrival: Departure: Special needs: 2. Registration of contributions /// Registration of the document: by 8 October (Friday) /// /// Distribution of the document: by 11 October (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// When you are going to submit a document, please notify S. Okubo as soon as possible, by 8 October (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. 3. Further details Please see the meeting notice: ftp://standard.pictel.com/avc-site/9910_Red/Notice_Red_Bank.txt or http://standard.pictel.com/ftp/avc-site/9910_Red/Notice_Red_Bank.txt 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