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