- sg16-avd - lists.packetizer.com

Files at the ftp site
by Sakae OKUBO 28 Jun '98

28 Jun '98

Dear Jean-Pierre, I have sorted out the files at the /Incoming directory of Q.12-14/16 ftp site. There are three gif files: TD-97, TD-98, TD-99. TD-99 has zero byte, and the remaining two appear irrelevant to the meeting. Do you have any ideas? I cannot find your TD-19 "Exhibition of a H.323 decentralized conference" anywhere. Could you please upload it? 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

Minutes from Multimedia MIB audio call o
by George Kajos 26 Jun '98

26 Jun '98

SQ16 Q14 Multimedia Management Information Base Audio Call 6/24 Minutes Agenda 1. IETF submission/coordination 2. APC 1380 GW, MC, MP Annexes 3. Cannes summary The call started late because George gave out incorrect bridge numbers and it took the first 15 minutes of the call to try to get people onto the bridge. As a result a number of people couldn't get into the conference. Actual participants: Attendees Mike Thatcher, Cisco Zvi Mizrahy, Pnina Vortman, IBM Haifa Orit Levin, RadVision Joon Maeng, VTEL Bill Strahm, Mark Baugher, Intel Picturetel Ghislaine Griswold, Lucent Don Dewar, George Kajos, David Reich, Irina Suconick, VideoServer People unable to attend because of the phone number problem: Nicole Gallant, Nortel David Walker, Ashok Ganesan, and Annette Lanteigne, Mitel I apologize for the mistake. IETF It was agreed at the Cannes meeting to obtain IETF input to the Multimedia MIB. The procedure appears to be for George to send email to the Operations and Maintenance Area Directors requesting a working group, stating the interest of the number of companies involved and the existing body of work. George will volunteer to co-chair the working group. It was discussed whether the IETF would find a qualified co-chair, but we will wait until we get a response to the email request. George will put together a strawman charter and send this request by 6/26/98. A poll was taken as to whether there would be adequate representation at the August meeting and it was clear that there would be a number of companies in attendance. A recurring issue is whether the work is going to be performed at the IETF or the ITU-T. The model discussed is the details of content are clearly ITU charter work, while SNMP and MIB format and organization are inputs we expect to be likely from the IETF. The Multimedia MIB document APC-1380 is organized as a main document and a series of Annexes representing individual pieces. Yet some of the attendees though it might be more appropriate to separate the Annexes into possibly 3 MIB submissions; H323, H320, H245. This caused some confusion as to where the GW MIB would go. It was decided to finish the Annexes of the Multimedia MIB document before concluding the format of the submission to the IETF. GW, MC, MP The GW, MC, and MP Annexes did not get submitted to the meeting at Cannes for the June ITU meeting. Zvi Mizrahy and Prina Vortman of IBM Haifa indicated they would send the gateway Annex APC1393 to the mailing list. One of the questions which was discussed was how to place the gateway in the overall hierarchy. It could probably be brought up to the main level rather than under H.323. The decision was deferred until the next meeting after the group had a chance to understand the proposal. One other element of the proposal was that there would be a set of definitions which would likely be moved up into the textual conventions and registration file. George also placed it in the avc-site\incoming directory on the Picturetel FTP site. VideoServer reiterated their intent to develop an MC and MP contribution of the next 2-3 weeks. Cannes review A brief summary of the Cannes meeting was discussed. First APC 1380 was presented which outlined the hierarchy and MIB organization. RTP was shown as Annex 1 in the document, but it is still an issue as to where it should appear. George, Irina and Joon discussed individual proposals. The RAS MIB and indexing issues reappeared. There was more discussion about correlation between admission and call signalling tables, but there's no conclusion. Gary Thom did not get feedback from his liaison to ITU SG4 on management. Thus, the whole effort is still on a dual path. Many present expressed a need to keep this work moving as rapidly as possible. Next Meeting: Wednesday, July 8, 1998 11:00 - 1:00 PM EST. Current Action Items: 1. George Kajos - Publish meeting minutes (this report) and schedule next conference. 2. George Kajos - Confer with ISO and IETF network management experts regarding placement of H.Multimedia MIB - generate request to O&M Area Director 3. Group - Admission table indices - Issue of index uniqueness waiting for example of a problem. 4. Group - Admission and CallSignalling Tables index correlation. 5. Group - review APC1393 (GW) from Zvi Mizrahy and Prina Vortman 6. VideoServer - Gernerate MC and MP proposal George Kajos VideoServer, Inc 63 Third Avenue Burlington, MA 01803 781-505-2193 (phone) 781-505-2101 (fax)

1 0

test
by Dale L. Skran 26 Jun '98

26 Jun '98

This is a test; please ignore. Dale

1 0

H.225.0/RAS ICV calculation
by Pekka Pessi 26 Jun '98

26 Jun '98

Hello, While debugging our ASN.1/PER encoder, I noticed a problem with the way ICV is calculated in H.225.0. Briefly, the PER encodings change when a SEQUENCE type is further extended, even if the new extension additions are not included in the SEQUENCE value. The issue prevents interoperability between software using H.225.0 version 2 and software using any version, it should be solved before any version 2 devices are released. Pekka Pessi h2250-integrityCheckValue-problem.txt Pekka Pessi <pessi(a)research.nokia.com> $Revision: 1.1 $ Nokia Research Center June 1998 Comments on H.225.0 (1998): Problems When Calculating integrityCheckValue The current H.225.0 algorithm for calculating the ICV does not work well with the PER extension mechanism. In order to interwork, each H.323 device needs a separate PER encoding function for each version of H.225.0 ASN.1 definitions. Algorithm for Calculating integityCheckValue According to the H.225.0 v2, integrityCheckValue is defined and calculated as follows: ICV ::= SEQUENCE { algorithmOID OBJECT IDENTIFIER, -- the algorithm used to compute the signature icv BIT STRING -- the computed cryptographic integrity check -- value or signature } integrityCheckValue - provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message. The above algorithm (AFAIK I have understood it correctly) assumes that the sender and receiver can encode the PDU exactly in the same way. It is a reasonable assumption, as PER produces only one possible (canonical) encoding for given PDU. However, there is a serious problem: the canonical representation changes if the ASN.1 SEQUENCE type is extended later. PER Encoding of an Extended ASN.1 SEQUENCE In the PER encoding of extensions to SEQUENCE types, the encoder first encodes the number of extensions as a normally small non-negative integer, then a bit field with one bit for each extension followed by the extensions itself (bit is one if the extension is present, zero if not). The encoding of each extension is preceded by the length of their encoding in octets. Now, if the sender A uses following ASN.1 definition for a SEQUENCE Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL } When encoding this, the length of extension bitfield is 2. However, recipient B is using extended version of Foo like this: Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL } B decodes the Foo, removes ICV and encodes the packet again. In the resulting encoding, the length of extension bitfield is 3, and the ICV that B regenerates is different that A generated and sent to B. B is not able to interwork with systems using earlier version of the ASN.1 spec. ASN.1 Compilers Don't Grok Unknown Extensions There are also problems because the way some ASN.1 compilers behave. Using our previous example, when A receives Foo with the importantExtension field from B, A has somehow to include the value when it is re-encoding Foo in order to calculate the ICV. However, it may be very hard to present an value of an unknown extension to the ASN.1 encoding functions. As a possible solution the ICV calculation could be included in the ASN.1 decoding process. Problems with Non-OPTIONAL Extensions Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL extensions. Let us assume that software C uses following ASN.1 definition for Foo: Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType } There are two kinds of problems with an extension like criticalExtension. First, the encoder may try to ensure that all encoded PDUs conform to the specification and signal an error when a PDU without criticalExtension is encoded. Another problem is that the intermediate representation produced by the ASN.1 compiler may not provide means for application to express that criticalExtension is not present. (In other words, the produced structure usually contains a flag telling whether an optional field is present or not. Such flags are not included when the field is not optional.) The presense or absence of the OPTIONAL flag in an extension does not change the PER encoding of the SEQUENCE. In order to avoid previously mentioned problems, application may use a version of ASN.1 notation that has extra OPTIONAL keyword after each extension. Solution 1: Clarification to the PER Encoding Process The text in PER document (X.691, 1994) is somewhat ambiguous how many bits should be included in the extension present bitfield of SEQUENCE. To quote verbatim: "Let the number of extension additions in the type being encoded be "n", then a bit-field with "n" bits shall be produced for addition to the field-list." (Is the "type being encoded" the abstract syntax or an actual value like { bar 1, baz 2 }?) However, the 0 bits at the end of extension present bitfield can be left out without changing the resulting semantics: the corresponding extensions are not present. As a result, the PER encoding does not change after a new extension is added to the ASN.1 specification. This solution, while leaving H.225.0 v2 protocol as it is, requires however changes to some existing ASN.1 compilers, and in a pessimal case, to the X.691 standard text, too. Solution 2: Hack The receiving application does not decode and the re-encode the PDU, but rather removes the ICV from the encoded PDU. In practice, this requires that application can identify PER-encoded fields within the PDU and it can regenerate them, i.e. it has effectively the same functionality as a PER encoder/decoder. Solution 3: Calculating ICV Differently The following algorithm for generating and checking the ICV makes it possible to avoid all the previously mentioned problems. The problems are avoided by breaking the protocol layering, the application changes directly the PER-encoded PDU: integrityCheckValue - provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation an ICV with a previously agreed magic value (or key when using MDC) will be inserted to this field. The magic value will contain same algorithmOID and exactly as many bits in the icv BIT STRING as the computed value. After computation, the sender replaces the magic value with the computed integrity check value and transmits message. The receiver decodes message, replaces the received integrity value with the magic value, calculates the ICV and compares it with the received value. NOTE: The sender or receiver can encode the ICV separately and replace it directly within the encoded PDU, when the magic ICV and computed ICV have exactly the same length. When replacing ICV value within an encoded PDU, re-encoding the whole PDU can be avoided. NOTE: The above algorithm does not require directly changing the PER-encoded PDU. Like the current algorithm, ICV can be replaced with a new value above presentation layer then PDU will be re-encoded. It makes it easy, however: as the magic value is a very unique octet-aligned bit pattern (random data of 64 bits or more, probably), it should be easy to spot and replace it from the encoded PDU. NOTE: It is not advisable to use magic value as the key to MAC algorithm. Example code: int icv_replace( u_char *msg, size_t len, u_char const *icv, u_char const *magic, size_t ilen) { u_char *m, *mim; size_t i, j, ilen_in_octets, ilen_in_full_octets; ilen_in_octets = (ilen + 7) >> 3; ilen_in_full_octets = ilen >> 3; /* find magic value from message */ for (m = msg, mim = NULL; m - msg < len - ilen_in_octets; m++) { /* NOTE: the magic value/icv may not be integral number of octets */ for (i = 0; i < ilen_in_full_octets; i++) { if (m[i] != magic[i]) break; } if (i == ilen_in_full_octets) { if (mim) return -2; /* failure: two or more magic values found */ mim = m; } } if (mim == NULL) { return -1; /* failure: no magic value found */ /* replace magic value with icv */ for (i = 0; i < ilen_in_octets; i++) { mim[i] ^= magic[i] ^ icv[i]; } return 0; /* success */ } Solution 4: Fourth alternative is to treat encoded RasMessage as octet string. IVC can be calculated over that octet string and appended to the PDU on separate layer. E.g., RAS PDU could be defined as follows: RasMessage ::= CHOICE { --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- -- all previous RasMessage CHOICEs are here --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- authenticatedRasMessage SEQUENCE { plainRasMessage OCTET STRING, ivc IVC, ... } }

4 5

Report of the Cannes meeting
by Sakae OKUBO 26 Jun '98

26 Jun '98

Dear Q.12-14/16 experts, I have uploaded draft report of the Cannes meeting (APC-1425) at the /Incoming directory. ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip /APC-1425_w95.zip w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) with Word 97. w95 is a version converted into Word 6/95; there are obvious errors in section numbering and figures. Please review it in a week time, and give me any comments. I will then complete it, uploade it at /9806_Can directory and send its copies to the SG16 management. 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

how many port pairs in a call/conference?
by grm＠ZURICH.IBM.COM 24 Jun '98

24 Jun '98

OK, I thought these were easy questions but maybe people wonder 'what does he mean by RTP Session?' Let me rephrase: (A) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in a two-party call with two-way audio? (B) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in an n-party conference with everybody sending and receiving audio and using distributed multi-unicast? Marcel Graf IBM Zurich Research Lab > I'm trying to find an answer to the question (A) "how many RTP > Sessions are there for a two-party call with two-way audio?", and to > the related question (B) "how many RTP Sessions are there for an > n-party conference with each participant being an audio Source and an > audio Sink and using distributed multi-unicast?". > > What I already know is that, assuming unidirectional Logical > Channels, in the first case there are two Logical Channels, and in > the second case there are n*(n - 1) Logical Channels. > > H.245 says about the sessionID: "The sessionID is a unique RTP or > T.120 Session Identifier in the conference. It is used by the > transmitter to refer to the session to which the logical channel > applies. Only the master can create the session identification. By > convention, there are three primary sessions. The first primary > session with a session identification of 1 is the audio session, the > second primary session with a session identification of 2 is the > video session, and the third primary session with a session > identification of 3 is the data session." > > Can I interpret this paragraph as saying that in case (A) there is > only one RTP Session, and in case (B) there is only one RTP Session, > too? > > If that is correct, then the following paragraph from H.323 section > 6.2.8.2 "Logical channel signalling" comes into play: "If a > corresponding reverse channel is opened for a given existing RTP > session (identified by the RTP sessionID), the mediaControlChannel > transport addresses exchanged by the OpenLogicalChannel process shall > be identical to those used for the forward channel. Should a > collision occur where both ends attempt to establish conflicting RTP > sessions at the same time, the master endpoint shall reject the > conflicting attempt as described in Recommendation H.245. The > rejected OpenLogicalChannel attempt may then be retried at a later > time." > > What type of conflict does this paragraph refer to? Given there is a > single RTP Session, and (multi-)unicast is used, each endpoint > chooses the RTP and RTCP port it is listening on independently of the > others. (The paragraph can't be talking about multicast, because it > is the MCs responsibility to allocate multicast addresses.) > > I also made the following observation: The "primary session > convention" established in the cited H.245 paragraph seems to be > contradicted by the samples shown in H.323 Appendix I "Sample MC to > Terminal Communication Mode Command" which uses the sessionIDs 2 and > 3 differently. Maybe the convention is only meant for two-party calls? > > > Marcel Graf > IBM Zurich Research Lab

2 1

Re: SNMP audio call
by Tom-PT Taylor 24 Jun '98

24 Jun '98

Please reserve a port for Nortel. Nicole Gallant will be taking part on our behalf. > -----Original Message----- > From: George Kajos [SMTP:gkajos@VIDEOSERVER.COM] > Sent: Tuesday, June 23, 1998 9:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: SNMP audio call > > Hello folks, > I'm resuming the Multimedia MIB audio call tomorrow, June 24 at 11-1:00 > EST. Please let me know if you desire a bridge number to attend the call. > My agenda is to discuss the August IETF meeting and to get commitments > for the 3 missing H.323 annexes - GW, MC, and MP. > > Thank you, > George Kajos > VideoServer > 63 Third Avenue > Burlington, MA 01803 > tel: (781) 505-2193 > fax: (781) 505-2101 > email: gkajos(a)videoserver.com

1 0

Re: conferenceListChoice
by Stewart, Glenn 23 Jun '98

23 Jun '98

Chris, Actually I agree with you, getting a list of conferences to Join in response to a create is kind of odd... The reason this occurs is that unlike T.120 there is no initial query function in H.323 call setup for the calling terminal to find out the nature of the called terminal. In general terminals (H.323 and H.320 for that matter) provide users a simple phone call model UI. The user provides an address and the terminal calls it. In this interface (unless the terminal requires or caches information about the nature of the target) the terminal is not aware of the intent of the call. In fact the user may not be aware of the ultimate intent of the call. Much of the time the user just wants to make a simple point to point connection and so one model is that the calling terminal simply asks the called party/terminal to create a conference. If the called party does not want to create the conference it refuses the connection and provides potential information on how to proceed. One of these possible responses is a list of conferences the terminal software can present to the user allowing the user to select conference he or she would like to join. I should point out there are terminals that make the user determine a priori the nature of the call (i.e., the user must indicate they are calling an MCU (or conference service) and would like to join a conference). While obviously being technically clean and correct, I personally, find them difficult to use. The model provided above, although "strange", is actually more intuitive in my opinion. glenn > -----Original Message----- > From: Chris Purvis WVdevmt-WS [mailto:cpurvis@madge.com] > Sent: Tuesday, June 23, 1998 5:10 AM > To: gstewart(a)sonusnet.com > Cc: mbozier(a)madge.com; jim.toga(a)intel.com; gthom(a)delta-info.com; > gkajos(a)videoserver.com > Subject: RE: conferenceListChoice > > > Glenn, > > Thanks for the response. It still seems a little strange offering an > endpoint a choice of conferences to JOIN when it has asked to > CREATE a new > conference, but at least it now seems reasonably clear what > you intended. > Don't worry about lack of clarity, by the way - that's the > fault of everybody > who had a chance to comment on the text, not just the person > who submitted it > in the first place. > Would you like to squirt some clarification back out on the > reflectors? > > Jim: Can something go in the implementor's guide on this, please? > > Chris > ---------------------------------------------------- > Chris, > > The conferenceListChoice element is only to provide a list of > conferences that the calling endpoint can join. The ability of the > calling endpoint to create a conference at the MCU is a choice left to > the MCU manufacturer. Assuming the MCU will allow a "create" then use > of the supplied GCID is sufficient. > > Your second (more serious) point reveals a lack of clarity in the text > (supplied by me I'm afraid). Not explicitly stated is that the > "Facility" message is a routeCallToMC in which the MCU Call Signaling > Address and the conference list are supplied. The calling > endpoint then > sends new Setup to the supplied Call Signaling Address with > the selected > conference (see section 8.4.3.7). > > My apologies for not making this more clear in the originally supplied > text. > > glenn > > Glenn Stewart > ~~~~~~~~~~~~~~~~~~~~~~~ > gstewart(a)sonusnet.com > Sonus Networks > ~~~~~~~~~~~~~~~~~~~~~~~ > PS: Gary - I'm not sure if your still editing H.323, but I thought the > editor should have a copy of this. Can you please forward this as > appropriate? > > > -----Original Message----- > > From: Chris Purvis WVdevmt-WS [mailto:cpurvis@MADGE.COM] > > Sent: Thursday, June 18, 1998 1:07 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: conferenceListChoice > > > > > > All, > > > > H.323 version 2 states in 8.4.3.1 A2d) and 8.4.3.4 that an > MCU can use > > conferenceListChoice to give a version 2 endpoint the choice > > between a number > > of possible conferences of which one it would like to > > create(!). I have two > > points with regard to this: > > 1. Surely it would also be sensible to have a similar method > > for joining > > extant conferences (rather than just sending ReleaseComplete > > when CIDs don't > > match)? Would'nt this be an easy (no extra ASN.1!) and > > useful addition? > > 2. (more serious) I can't see how an endpoint tells the MCU > > which conference > > from the list it has chosen! > > Is it up to the endpoint to release the call and send a new > > setup message > > with the appropriate conference alias in, or does it send > > back a similar > > facility message to the one it was sent, with a single > > ConferenceList in > > rather than a sequence of same? > > > > Chris > > ---------------------------------------- > > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > > Phone:+44 1753 661359 email: cpurvis(a)madge.com >

1 0

Re: SNMP audio call
by Chris Gindel 23 Jun '98

23 Jun '98

George, Please send me a number for the call. Thanks, Chris > -----Original Message----- > From: George Kajos [SMTP:gkajos@VIDEOSERVER.COM] > Sent: Tuesday, June 23, 1998 9:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: SNMP audio call > > Hello folks, > I'm resuming the Multimedia MIB audio call tomorrow, June 24 at > 11-1:00 > EST. Please let me know if you desire a bridge number to attend the > call. > My agenda is to discuss the August IETF meeting and to get commitments > for the 3 missing H.323 annexes - GW, MC, and MP. > > Thank you, > George Kajos > VideoServer > 63 Third Avenue > Burlington, MA 01803 > tel: (781) 505-2193 > fax: (781) 505-2101 > email: gkajos(a)videoserver.com

1 0

SNMP audio call
by George Kajos 23 Jun '98

23 Jun '98

Hello folks, I'm resuming the Multimedia MIB audio call tomorrow, June 24 at 11-1:00 EST. Please let me know if you desire a bridge number to attend the call. My agenda is to discuss the August IETF meeting and to get commitments for the 3 missing H.323 annexes - GW, MC, and MP. Thank you, George Kajos VideoServer 63 Third Avenue Burlington, MA 01803 tel: (781) 505-2193 fax: (781) 505-2101 email: gkajos(a)videoserver.com

1 0

how many RTP Sessions in a call/conference?
by grm＠ZURICH.IBM.COM 19 Jun '98

19 Jun '98

I'm trying to find an answer to the question (A) "how many RTP Sessions are there for a two-party call with two-way audio?", and to the related question (B) "how many RTP Sessions are there for an n-party conference with each participant being an audio Source and an audio Sink and using distributed multi-unicast?". What I already know is that, assuming unidirectional Logical Channels, in the first case there are two Logical Channels, and in the second case there are n*(n - 1) Logical Channels. H.245 says about the sessionID: "The sessionID is a unique RTP or T.120 Session Identifier in the conference. It is used by the transmitter to refer to the session to which the logical channel applies. Only the master can create the session identification. By convention, there are three primary sessions. The first primary session with a session identification of 1 is the audio session, the second primary session with a session identification of 2 is the video session, and the third primary session with a session identification of 3 is the data session." Can I interpret this paragraph as saying that in case (A) there is only one RTP Session, and in case (B) there is only one RTP Session, too? If that is correct, then the following paragraph from H.323 section 6.2.8.2 "Logical channel signalling" comes into play: "If a corresponding reverse channel is opened for a given existing RTP session (identified by the RTP sessionID), the mediaControlChannel transport addresses exchanged by the OpenLogicalChannel process shall be identical to those used for the forward channel. Should a collision occur where both ends attempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject the conflicting attempt as described in Recommendation H.245. The rejected OpenLogicalChannel attempt may then be retried at a later time." What type of conflict does this paragraph refer to? Given there is a single RTP Session, and (multi-)unicast is used, each endpoint chooses the RTP and RTCP port it is listening on independently of the others. (The paragraph can't be talking about multicast, because it is the MCs responsibility to allocate multicast addresses.) I also made the following observation: The "primary session convention" established in the cited H.245 paragraph seems to be contradicted by the samples shown in H.323 Appendix I "Sample MC to Terminal Communication Mode Command" which uses the sessionIDs 2 and 3 differently. Maybe the convention is only meant for two-party calls? Marcel Graf IBM Zurich Research Lab

1 0

H.321/H.322
by Gary A. Thom 19 Jun '98

19 Jun '98

All, I am putting together a report on the maturity of some of the H-Series recommendations. I am trying to find out if anyone produces or plans to produce products which comply with H.321 or H.322. If you do, or if you know that someone else does, could you please drop me an e-mail. Thanks Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------

1 0

conferenceListChoice
by Chris Purvis WVdevmt-WS 18 Jun '98

18 Jun '98

All, H.323 version 2 states in 8.4.3.1 A2d) and 8.4.3.4 that an MCU can use conferenceListChoice to give a version 2 endpoint the choice between a number of possible conferences of which one it would like to create(!). I have two points with regard to this: 1. Surely it would also be sensible to have a similar method for joining extant conferences (rather than just sending ReleaseComplete when CIDs don't match)? Would'nt this be an easy (no extra ASN.1!) and useful addition? 2. (more serious) I can't see how an endpoint tells the MCU which conference from the list it has chosen! Is it up to the endpoint to release the call and send a new setup message with the appropriate conference alias in, or does it send back a similar facility message to the one it was sent, with a single ConferenceList in rather than a sequence of same? Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Proposal for Common RDC Protocol is available
by Mark Duckworth 18 Jun '98

18 Jun '98

This proposal for work on a common RDC protocol is submitted to the Q3 meeting next week in Colorado Springs. I uploaded it to: ftp://ftp.imtc-files.org/imtc-site/incoming/Common_RDC_Proposal.zip Bruce DeGrasse, please move it to ftp://ftp.imtc-files.org/imtc-site/T120-top/t120_colorado98 Summary: This proposal continues the work of recent RDC audio conferences and the Q11-14/16 meeting in Cannes. The proposed approach is to use a common RDC protocol (V.RDC) which can be carried within a T.120 APE (T.RDC) or without T.120 (H.RDC) in an H.245 logical channel. H.323 systems will use H.RDC for both point to point and multipoint, with T.RDC being optional. This paper includes the following: - suggestions for separating the common protocol from the T.120 specifics, in the current T.RDC (ftp://www.imtc.org/imtc-site/T120-top/t120_ky98/TRDCreva.doc) - changes to camera control to make it H.281 compatible - start/continue/stop - predefined device identifiers - presets - changes to camera control to make it more useful and usable - automatic pointing - coordinates in terms of field of view rather than degrees - a list of work still to do in defining the ASN.1 syntax for H.RDC Mark Duckworth

1 0

Re: GloballyUniqueID duplicates
by Douglas Clowes 17 Jun '98

17 Jun '98

At 18:43 16/06/98 -0700, you wrote: >>---------- >>From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >>On reading the text in H.225.0 describing the construction of a globally >>unique identifier, it seems to me that duplicates are possible if the clock >>has not advanced since the last identifier was generated. >That's what the clock sequence value is for. > >Paul Long >Smith Micro > Perhaps, but on my reading, it's not what the document says! Douglas Clowes OzEmail Interline

2 1

Re: GloballyUniqueID duplicates
by Paul Long 16 Jun '98

16 Jun '98

>---------- >From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >On reading the text in H.225.0 describing the construction of a globally >unique identifier, it seems to me that duplicates are possible if the clock >has not advanced since the last identifier was generated. That's what the clock sequence value is for. Paul Long Smith Micro

1 0

GloballyUniqueID duplicates
by Douglas Clowes 16 Jun '98

16 Jun '98

On reading the text in H.225.0 describing the construction of a globally unique identifier, it seems to me that duplicates are possible if the clock has not advanced since the last identifier was generated. This may occur if the clock ticks at a slow rate (say ten milliseconds), if the CPU is sufficiently fast, or there is more than one CPU. In the case of a slow clock, say ten milliseconds, this can be compensated for with the low order bits of the time field being cleared and used as a sequence number for identifiers generated in the same clock tick. In what has been called a "Carrier Class Gateway," with tens of thousands of SCN ports and more than one CPU, it may be possible to generate a duplicate identifier, for a CallIdentifier, within the same 100-nanosecond interval. In this event, a possible action is to increment the clock sequence if the time "has not advanced" rather than "has gone backward." Thus, if the current UTC is less that *or equal* to the saved value, or the saved value was lost, the clock sequence is incremented. Douglas Clowes OzEmail Interline

1 0

ITU-T Q.15/SG16 (Video) Meeting Notice
by Gary Sullivan 16 Jun '98

16 Jun '98

Video Experts, Attached is the preliminary official meeting notice for the upcoming ITU-T Q.15/SG16 meeting to be held next month (July 21-24) in Whistler, British Columbia, Canada. The meeting will be hosted jointly by TELES AG of Germany and the University of British Columbia. Please note that the hotel reservation deadline is in only one week (June 23). MAKE YOUR RESERVATIONS NOW. Contributions are hereby solicited for the meeting. Contributions should be registered with the rapporteur (garys(a)pictel.com) as soon as possible (see the meeting notice for details). Final approval to hold the meeting will be granted by SG16 based in part on having a sufficient number of pre-registered contributions. REGISTER YOUR CONTRIBUTIONS NOW. My understanding is that Q.11/SG16 currently plans to also meet at the same time in Whistler, and the two groups plan to jointly confer regarding several issues of common interest. Particular issues of joint interest include H.263+ in H.320, H.324 mobile video issues, and the proposal of MPEG-4 video for use in H.324. Best Wishes, Gary Sullivan ITU-T Advanced Video Coding (Q.15/SG16) Rapporteur PictureTel Corp. M/S 635 Tel: +1 978 623 4324 100 Minuteman Road Fax: +1 978 749 2804 Andover MA 01810 USA Email: garys(a)pictel.com begin 644 q15eT0r0.doc MT,\1X*&Q&N$ /@ # /[_"0 & ! M ) $ )0 $ #^____ ", #_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________<I6@ 5^ )! !E P MR2@ )Q$ MR4 1 M #P (X! / C@$ (X] CCT M "./0 (X] CCT !0 #H/0 ' .@] !#X M $/@ 0^ , $#X H :/@ - .@] MGD, #$ !./@ ! %(^ 6 :#X !H/@ &@^ M :#X !H/@ &@^ J4$ ( "K00 *M! M JT$ "T #800 U *Q" #4 @$, !X #/0P 6 M "=$ !U GD, CCT !H/@ M %0 6 $ " !H/@ &@^ M &@^ :#X ">0P !)! CCT "./0 M &@^ $X^ $D$ 2 M00 !)! :#X *H" "./0 &@^ CCT M !H/@ *E! " M?$E1IF] :(] : O#T M "P "./0 (X] CCT "./0 &@^ MJ4$ 200 EP !)! M M !43SH)17AP97)T<R!O;B!)5%4M5"!1+C$U M+S$V("T@061V86YC960@5FED96\@0V]D:6YG#0D@(" @(" @("AM965T:6YG M(&EN(&-O;6UO;B!L;V-A=&EO;B!W:71H(%%U97-T:6]N(#$Q*0T-1E)/33H) M1V%R>2!3=6QL:79A;B H4F%P<&]R=&5U<B!F;W(@42XQ-2\Q-BD-#5-50DI% M0U0Z"5!R96QI;6EN87)Y($%N;F]U;F-E;65N="!O9B!T:&4@1FEF=&@@365E M=&EN9R!O9B!T:&4@17AP97)T<R!'<F]U<"!F;W(-"4E452U4(%$N,34O,38@ M+2!!9'9A;F-E9"!6:61E;R!#;V1I;F<-"5=H:7-T;&5R+"!"0RP@0V%N861A M+"!*=6QY(#(Q+3(T+" Q.3DX+@T-5D524TE/3CH)2G5N92 Q-BP@,3DY. T- M5&AE('!U<G!O<V4@;V8@=&AI<R!D;V-U;65N="!I<R!T;R!P<F]V:61E(&EN M9F]R;6%T:6]N(&9O<B!T:&4@9FEF=&@@;65E=&EN9R!O9B!T:&4@17AP97)T M<R!'<F]U<"!O;B!!9'9A;F-E9"!6:61E;R!#;V1I;F<@*%$N,34O,38I('1O M(&)E(&AE;&0@:6X@5VAI<W1L97(L($)#+"!#86YA9&$L($IU;'D@(#(Q+3(T M+" Q.3DX+B @*%1H:7,@:7,@82!P<F5L:6UI;F%R>2!A;FYO=6YC96UE;G0L M(&%S('1H92!F:6YA;"!M965T:6YG(&%P<')O=F%L(&9R;VT@=&AE($E452U4 M(%-',38@:&%S(&YO="!Y970@8F5E;B!O8G1A:6YE9"XI(%1H92!M965T:6YG M(&ES(&%T('1H92!K:6YD(&EN=FET871I;VX@;V8@5$5,15,@04<@86YD('1H M92!5;FEV97)S:71Y(&]F($)R:71I<V@@0V]L=6UB:6$L(&%N9"!I<R!B96EN M9R!H96QD(&EN(&-O;FIU;F-T:6]N('=I=&@@42XQ,2X-5&AE('!R96QI;6EN M87)Y(&%G96YD82!I=&5M<R!F;W(@=&AI<R!M965T:6YG(&-O;G-I<W0@;V8@ M=&AE(&9O;&QO=VEN9SH-0V]O<F1I;F%T:6]N(&]F('9I9&5O(&-O9&EN9R!N M965D<R!W:71H(&]T:&5R(&]R9V%N:7IA=&EO;G,L(&EN8VQU9&EN9PU1+C$Q M+3$T+S$V('-T86YD87)D<RP@<&%R=&EC=6QA<FQY.@U(+C(V,RL@:6X@2"XS M,C -4E10('!A>6QO860@<&%C:V5T:7IA=&EO;B!F;W(@2"XR-C,K(&EN($@N M,C(U+C -35!%1RTT(&EN($@N,S(T#4E33R])14,@2E1#,2!30S(Y+R!71S$Q M("A-4$5'*2P@<&%R=&EC=6QA<FQY($U014<M-"!6:61E;PU)5%4M5"!31S$R M+"!P87)T:6-U;&%R;'D@3V)J96-T:79E(&%N9"!3=6)J96-T:79E(%9I9&5O M(%%U86QI='D@07-S97-S;65N= U/=&AE<B!O<F=A;FEZ871I;VYS(&%S(&%P M<')O<')I871E#5!A<G1I8W5L87(@<W1U9'D@;V8@=FED96\@8V]D:6YG(&9O M<B!P86-K970@;F5T=V]R:R!A;F0@;6]B:6QE(&%P<&QI8V%T:6]N<RP@:6YC M;'5D:6YG#51U=&]R:6%L<RP@9&5M;VYS=')A=&EO;G,L(&%N9"!S='5D:65S M(&]F(&5X:7-T:6YG(&-A<&%B:6QI=&EE<PU3=&%N9&%R9&EZ871I;VX@<')O M<&]S86QS(&9O<B!F=71U<F4@=V]R:PU%<G)O<B!C;VYC96%L;65N="!M971H M;V1S#4-H86YN96P@<F%T92!A;F0@<75A;&ET>2!S='5D:65S(&%N9"!R97%U M:7)E;65N=',-3W1H97(@<W5C:"!A<W!E8W1S(&9O<B!U;F1E<G-T86YD:6YG M(&%N9"!S=&%N9&%R9&EZ871I;VX@9F]R('1H:7,@87!P;&EC871I;VX-4W1U M9'D@;V8@2"XR-C-V,B!C87!A8FEL:71I97,@86YD(&QI;6ET<PU497-T(&UO M9&5L('-I;75L871I;VX@<W!E8VEF:6-A=&EO;B!E;FAA;F-E;65N="!F;W(@ M=7-E(&EN($@N,C8S*R!A;F0@2"XR-DP@86-T:79I=&EE<PU":71S=')E86T@ M97AC:&%N9V4@86-T:79I=&EE<PU3;V9T=V%R92!D979E;&]P;65N="!A8W1I M=FET:65S#49U<G1H97(@=&AE('=O<FL@=&]W87)D()-(+C(V,RLKE"!E>'1E M;G-I;VYS(&9O<B!F=71U<F4@9&5T97)M:6YA=&EO;BP@=VET:"!P;W-S:6)L M92!D<F%F=&EN9R!O9B!(+C(V,RLK(&5X=&5N<VEO;G,@9F]R(&%D;W!T:6]N M+"!I;F-L=61I;F<@=&AE(&ED96YT:69I960@2V5Y(%1E8VAN:6-A;"!!<F5A M<SH-1&%T82!087)T:71I;VYI;F<O4E9,0R!%<G)O<B!297-I;&EE;F-E#31X M-"!-0RM$0U0@0V]D:6YG#4%D87!T:79E(%%U86YT:7IA=&EO;@U,;VYG+51E M<FTO0F%C:V=R;W5N9"!-96UO<GD-16YH86YC960@4V-A;&%B:6QI='D-241# M5"!-:7-M871C:"!2961U8W1I;VX-1G5R=&AE<B!T:&4@=V]R:R!T;W=A<F0@ M2"XR-C-,(&QO;F<M=&5R;2!C;V1I;F<@<W1A;F1A<F0L(&YO=&EN9R!I;B!P M87)T:6-U;&%R('1H92!(+C(V3"!G=6ED:6YG(&1O8W5M96YT<R!I<W-U960@ M870@=&AE($=E;F5V82!31S$V(&UE971I;F<@;V8@2F%N+T9E8B Q.3DX.@U# M86QL(&9O<B!0<F]P;W-A;',-4VEM=6QA=&EO;B!#;VYD:71I;VYS(&9O<B!0 M<F]P;W-A;',-1&5L87D@179A;'5T:6]N($UO9&5L#5)E<75I<F5M96YT<R!$ M;V-U;65N= U#;VYS:61E<F%T:6]N(&]F('9I9&5O(&-O9&EN9R!N965D<R!F M;W(@;F]N+6-O;G9E<G-A=&EO;F%L('-E<G9I8V5S#4-O;G-I9&5R871I;VX@ M;V8@=FED96\@8V]D:6YG(&YE961S(&9O<B!U<V5R<R!O9B!S:6=N+6QA;F=U M86=E(&%N9"!L:7 M<F5A9&EN9PU-86EN=&5N86YC92!O9B!E>&ES=&EN9R!) M5%4@=FED96\@8V]D:6YG('-T86YD87)D<R H2"XQ,C L($@N,C8Q+"!(+C(V M,BP@2"XR-C,I#4-O;G-I9&5R871I;VX@;V8@=&5C:&YO;&]G>2!F;W(@8V]M M<')E<W-E9"!D:6=I=&%L+71O+61I9VET86P@=FED96\@9F]R;6%T(&)I="!R M871E(')E9'5C=&EO;@U#;VYS:61E<F%T:6]N(&]F(&]T:&5R(&)U<VEN97-S M(&%S(&YE8V5S<V%R>2!F;W(@42XQ-2\Q-@T-5&AE(&UE971I;F<@=VEL;"!B M92!O<&5N('1O(&%L;"!)5%4M5"!M96UB97)S+B @061D:71I;VYA;"!N;VX@ M2515+50@97AP97)T<R!M87D@86QS;R!P87)T:6-I<&%T92!I9B!I;G9I=&5D M(&)Y('1H92!R87!P;W)T975R+B @5&AE(')A<'!O<G1E=7(@;V8@42XQ-2!D M;V5S(&YO="!W:7-H('1O(&5X8VQU9&4@86YY;VYE('=H;R!C;W5L9"!B92!A M('9A;'5A8FQE(&-O;G1R:6)U=&]R('1O('1H92!W;W)K+"!A;F0@=&AU<R!E M>'!E8W1S('1O(&)E(&QI8F5R86P@:6X@9W)A;G1I;F<@<F5Q=65S=',@9F]R M(&EN=FET871I;VXN("!!(&]N92UP86=E(&9A>"!S96YT('1O('1H92!R87!P M;W)T975R(&ES('1H92!S=6=G97-T960@;65T:&]D(&]F(&-O;G1A8W0@9F]R M(&]B=&%I;FEN9R!S=6-H(&EN=FET871I;VYS("AH86YD+7=R:71T96X@:7,@ M9FEN92P@86YD(&)E('-U<F4@=&\@:6YC;'5D92!R971U<FX@8V]N=&%C="!P M:&]N92P@9F%X+"!A9&1R97-S(&%N9"!E;6%I;"!I;F9O<FUA=&EO;BDN#0U4 M:&4@;65E=&EN9W,@87)E(&)E:6YG(&AO<W1E9"!B>2!414Q%4R!!1RP@0F5R M;&EN+"!'97)M86YY(&%N9"!5;FEV97)S:71Y(&]F($)R:71I<V@@0V]L=6UB M:6$L(%9A;F-O=79E<BP@0D,L($-A;F%D82X@268@>6]U(')E<75I<F4@:6YF M;W)M871I;VX@;VX@=&AE(&QO9VES=&EC<R!F;W(@=&AE(&UE971I;F<L('!L M96%S92!C;VYT86-T('1H92!M965T:6YG(&AO<W0@<F5P<F5S96YT871I=F5S M(&9R;VT@5$5,15,@04<O54)#.@T-4W1E<&AA;B!796YG97(-0TE#4U(@0G5I M;&1I;F<-,C,V-B!-86EN($UA;&P-5F%N8V]U=F5R+"!"0RP@0V%N861A#58V M5" Q6C0'"U1E;#H@*S$@-#$U(#(Y-R R,#8S"T9A>#H@*S$@-C T(#@R,B U M.30Y"T5M86EL.B!S=&5W94!C<RYT=2UB97)L:6XN9&4-!P<-5&AE('9E;G5E M(&9O<B!T:&4@;65E=&EN9R!W:6QL(&)E('1H92!$96QT82!7:&ES=&QE<B!2 M97-O<G0L('=H97)E(&$@8FQO8VL@;V8@:&]T96P@<F]O;7,@:&%S(&)E96X@ M<F5S97)V960@9F]R('1H92!M965T:6YG('!A<G1I8VEP86YT<RX@(%1H92!S M;&5E<&EN9R!R;V]M(')A=&5S(&%R92 -#5-U<&5R:6]R!T,D,34P+C P("AA M<'!R;W@@55,D(#$Q,"D'!T1E;'5X90=#)#$X-2XP," H87!P<F]X(%53)" Q M,C4I!P=*=6YI;W(@4W5I=&4'0R0S.3<N,# '!T5X96-U=&EV92!3=6ET90=# M)#4T.2XP, <'#7!E<B!R;V]M+"!P97(@;FEG:'0L(&)A<V5D(&]N('-I;F=L M92!P97)S;VX@;V-C=7!A;F-Y+B @06QL('1A>&5S(&%R92!I;F-L=61E9"X@ M5&AE(')A=&5S(&%L<V\@:6YC;'5D92!A(&-O;G1I;F5N=&%L(&)R96%K9F%S M="!T;R!B92!S97)V960@:6X@=&AE(&UA:6X@;65E=&EN9R!R;V]M(&%S('=E M;&P@='=O(&-O9F9E92!B<F5A:W,@96%C:"!D87DN(%)E<V5R=F%T:6]N<R!A M="!T:&4@;65E=&EN9R!H;W1E;"!C86X@8F4@;6%D92!D:7)E8W1L>2!W:71H M('1H92!$96QT82!7:&ES=&QE<B!297-O<G0@;VX@86X@:6YD:79I9'5A;"!B M87-I<R!O;B!O<B!B969O<F4@2G5N92 R,RP@,3DY."!T;R!G=6%R86YT964@ M<F%T92!A;F0@879A:6QA8FEL:71Y+B @270@:7,@:6UP97)A=&EV92!T:&%T M(&EN9&EV:61U86QS(&EN9&EC871E('1H96ER(&=R;W5P(&%F9FEL:6%T:6]N M(&)Y('1H92!C;VUP=71E<B!C;V1E(&YA;64@1T1114=-('1O(')E8V5I=F4@ M=&AE(&=R;W5P(')A=&4N(%1O(&9A8VEL:71A=&4@<F5S97)V871I;VYS+"!A M='1E;F1E97,@<VAO=6QD(&1I86P@#2LQ(#8P-" Y,S(@,3DX,B!A;F0@87-K M(&9O<B!I;BUH;W5S92!R97-E<G9A=&EO;G,L(&9O<B!I;G1E<FYA=&EO;F%L M(" -,2 X,# @,C8X(#$Q,S,L(&9O<B!#86YA9&$@86YD('1H92!54PT-4&QE M87-E(&YO=&4L('1H870@=&AE('9E;G5E(&ES(&$@4F5S;W)T(&QO8V%T:6]N M('=I=&@@<F5S97)V871I;VX@86YD(&)O;VMI;F<@<&]L:6-I97,@9&EF9F5R M96YT(&9R;VT@=7-U86P@8VET>2!H;W1E;',N("!087)T:6-I<&%N=',@<VAO M=6QD(&)E(&%D=FES960@86)O=70@=&AE(&9O;&QO=VEN9R!R97-E<G9A=&EO M;B]C86YC96QL871I;VX@:7-S=65S.@U297-E<G9A=&EO;G,@<VAO=6QD(&)E M(&UA9&4@87,@<V]O;B!A<R!P;W-S:6)L92P@8G5T(&QA=&5S="!O;B!T:&4@ M,C-R9"!O9B!*=6YE+B @4&QE87-E(&UA:V4@>6]U<B!R97-E<G9A=&EO;B!D M:7)E8W1L>2!W:71H('1H92!H;W1E;"!M96YT:6]N:6YG('1H92!C;VUP=71E M<B!C;V1E+"!B=70@16UA:6P@;W(@9F%X('-I;6EL87(@:6YF;W)M871I;VX@ M=&\@=&AE(&UE971I;F<@:&]S=',@<F5P<F5S96YT871I=F4@<V\@=&AA="!H M92!C86X@:V5E<"!T<F%C:R!O9B!T:&4@9W)O=7 @<VEZ92!A;F0@<F5L96%S M92!B;&]C:V5D(')O;VUS(&EF(&YE8V5S<V%R>2X@($%T('1I;64@;V8@<F5S M97)V871I;VX@=&AE(&AO=&5L('=I;&P@8VAA<F=E('EO=2!F;W(@;VYE(&YI M9VAT+@U0<F4M87)R:79A;"!C86YC96QL871I;VX@:7,@;VYL>2!P;W-S:6)L M92!W:71H:6X@-R!D87ES(&)E9F]R92!T:&4@<&QA;FYE9"!A<G)I=F%L+"!O M=&AE<G=I<V4@=&AE(&AO=&5L('=I;&P@8VAA<F=E('EO=2!F;W(@=&AE(&9U M;&P@<W1A>2!O9B!Y;W5R(&]R:6=I;F%L(')E<V5R=F%T:6]N+@U!9G1E<B!C M:&5C:RUI;BP@86YY(&5A<FQY(&1E<&%R='5R97,@=VEL;"!B92!C:&%R9V5D M(&9O<B!T:&4@9'5R871I;VX@;V8@=&AE(&]R:6=I;F%L(')E<V5R=F%T:6]N M+@T-5&AE(&-L;W-E<W0@86ER<&]R="!I<R!T:&4@5F%N8V]U=F5R($%I<G!O M<G0L('=H:6-H(&ES(&%B;W5T(#(N-2!H;W5R<R!A=V%Y(&)Y(&%U=&]M;V)I M;&4N($$@<VAU='1L92!S97)V:6-E(&ES(&%V86EL86)L92!F<F]M('1H92!6 M86YC;W5V97(@06ER<&]R="!T;R!T:&4@5VAI<W1L97(@1&5L=&$@4F5S;W)T M(&9O<B!A<'!R;WAI;6%T96QY($,D.# @<F]U;F0M=')I<"X@071T96YD965S M(&-A;B!C;VYT86-T('1H92!097)I;65T97(@17AP<F5S<R!S:'5T=&QE('-E M<G9I8V4@9&ER96-T;'DL(&%T("LQ(#8P-" Y,#4@,# T,2!F;W(@87)R:79A M;"!A;F0@9&5P87)T=7)E('-C:&5D=6QE<R!T;R!A;F0@9G)O;2!T:&4@5F%N M8V]U=F5R($%I<G!O<G0N($%L<V\L('-H;W5L9"!A='1E;F1E97,@=VES:"!T M;R!V:7-I="!D;W=N=&]W;B!686YC;W5V97(@=7!O;B!A<G)I=F%L+"!A('-H M=71T;&4@<V5R=FEC92!I<R!A=F%I;&%B;&4@9G)O;2!D;W=N=&]W;B!686YC M;W5V97(@=&\@5VAI<W1L97(@9F]R(&%P<')O>&EM871E;'D@0R0R,"P@;VYE M('=A>2X@071T96YD965S(&-A;B!C;VYT86-T('1H92!-879E<FEC:R!"=7,@ M3&EN92!D:7)E8W1L>2P@870@*S$@-C T(#8V,B X,#4Q(&9O<B!A<G)I=F%L M(&%N9"!D97!A<G1U<F4@<V-H961U;&5S('1O(&%N9"!F<F]M(&1O=VYT;W=N M(%9A;F-O=79E<BX@4F5N=&%L(&-A<G,@86YD('1A>&ES(&%R92!A;'-O(&%V M86EL86)L92!A="!T:&4@5F%N8V]U=F5R($%I<G!O<G0N#0U4:&4@9F]L;&]W M:6YG(')E;&5V86YT(&1O8W5M96YT<R!W:6QL('-O;VX@8F4@879A:6QA8FQE M(&]N('1H92!1+C$U+S$V(&9T<"!S:71E("AF=' Z+R]S=&%N9&%R9"YP:6-T M96PN8V]M*2!I;B!T:&4@9&ER96-T;W)Y('9I9&5O+7-I=&4O.3@P-U]7:&D- M02!D971A:6QE9"!A9V5N9&$@*'$Q-654,2YD;V,I#4$@;&ES="!O9B!R96=I M<W1E<F5D(&-O;G1R:6)U=&EO;G,@*'$Q-64P,"YD;V,I#4$@9&]C=6UE;G0@ M=&5M<&QA=&4@9FEL92 H<3$U92YD;W0I#4$@8V]P>2!O9B!T:&ES(&UE971I M;F<@86YN;W5N8V5M96YT("AQ,35E5# N9&]C*0T-66]U(&%R92!E;F-O=7)A M9V5D('1O(&UO;FET;W(@=&AI<R!F=' @<VET92!I;B!T:&4@=7!C;VUI;F<@ M=V5E:W,@9F]R(&5L96-T<F]N:6,@8V]P:65S(&]F('1H92!V87)I;W5S(&-O M;G1R:6)U=&EO;G,N#0U#;VYT<FEB=71I;VYS(&9O<B!1+C$U('=I;&P@8F4@ M;G5M8F5R960@DU$Q-6U86),L('=H97)E(&T@:7,@82!S:6YG;&4@;&5T=&5R M(&EN9&EC871I;F<@=&AE(&UE971I;F<@;G5M8F5R+" H9F]R('1H:7,@;65E M=&EN9RP@DV63*2P@86YD(%A8('=I;&P@8F4@=&AE(&%S<VEG;F5D(&1O8W5M M96YT(&YU;6)E<BX@($9O<B!F:6QE('5P;&]A9',L('1H92!F;W)M870@:7,@ M<3$Q95A8+GIZ>BP@=VAE<F4@>GIZ('=I;&P@8F4@=&AE(&9I;&4@='EP92 H M+F1O8RP@+G!D9BP@+G1X="!E=&,N*2P@86YD($U3(%=O<F0@*'9E<G-I;VX@ M-R!O<B!E87)L:65R+"!N;W0@5V]R9#DW*2!F;W)M870@=VET:"!A("YD;V,@ M97AT96YS:6]N(&ES('!R969E<G)E9"X@3G5M8F5R<R!F;W(@=&AE(&1O8W5M M96YT<R!W:6QL(&)E(&%S<VEG;F5D(&1I<F5C=&QY(&)Y('1H92!R87!P;W)T M975R(&9O<B!1+C$U(#QG87)Y<T!P:6-T96PN8V]M/BX@(%=H96X@<F5G:7-T M97)I;F<@82!D;V-U;65N="P@<&QE87-E('!R;W9I9&4@=&AE(&9O;&QO=VEN M9R!I;F9O<FUA=&EO;CH@=&ET;&4L('-O=7)C92 H<&QE87-E('!R;W9I9&4@ M875T:&]R+"!A9F9I;&EA=&EO;BP@86YD(&-O=6YT<GD@:6YF;W)M871I;VXI M+"!S=6)J96-T(&%R96$@*&%D;6EN+"!(+C(V,RP@2"XR-C,K*RP@2"XR-DPL M('!R:6]R('-T86YD87)D<RP@;W1H97(I+"!A;F0@<'5R<&]S92 H:6YF;W)M M871I;VXL('!R;W!O<V%L+"!D<F%F="!T97AT(&9O<B!O=71P=70@9&]C=6UE M;G0L(&]R(&QI86ES;VXI+@T-270@:7,@<F5Q=65S=&5D('1H870@86QL(&1O M8W5M96YT<R!B92!U<&QO861E9"!T;R!T:&4@9G1P('-I=&4@9')O<&)O>"!A M=#H-#0E54DPZ(&9T<#HO+W-T86YD87)D+G!I8W1E;"YC;VTO=FED96\M<VET M92]D<F]P8F]X#0UA="!L96%S=" Q,"!W;W)K:6YG(&1A>7,@8F5F;W)E('1H M92!M965T:6YG+"!F;VQL;W=E9"!B>2!A;B!E;6%I;"!M97-S86=E('1O('1H M92!R87!P;W)T975R("AG87)Y<T!P:6-T96PN8V]M*2!W:&\@=VEL;"!M;W9E M('1H92!D;V-U;65N="!T;R!T:&4@5VAI<W1L97(@;65E=&EN9R!F;VQD97(N M("!!;B!E;6%I;"!M97-S86=E('-H;W5L9"!A;'-O(&)E('-E;G0@=&\@=&AE M(&5M86EL(')E9FQE8W1O<B H:71U+6%D=BUV:61E;T!L:7-T<V5R=BYI=&5R M871E9"YC;VTI('1O(&YO=&EF>2!T:&4@97AP97)T<R!G<F]U<"!O9B!T:&4@ M879A:6QA8FEL:71Y(&]F('1H92!D;V-U;65N="X-#4%L;"!D;V-U;65N=',@ M;75S="!B92!U<&QO861E9"!T;R!T:&4@9G1P('-I=&4@870@;&5A<W0@9F]U M<B!B=7-I;F5S<R!D87ES('!R:6]R('1O('1H92!M965T:6YG("AI+F4N+"!B M>2!M:61N:6=H="!086-I9FEC(%-T86YD87)D(%1I;64@;VX@5V5D;F5S9&%Y M($IU;'D@,34L(&)E:6YG(# X.C P($=-5"!4:'5R<V1A>2!*=6QY(#$V*2X@ M($QA=&4L('5N86YN;W5N8V5D(&1O8W5M96YT<R!H86YD+6-A<G)I960@=&\@ M=&AE(&UE971I;F<@=VEL;"!B92!A8V-E<'1E9"!O;FQY('=I=&@@=&AE(&-O M;G-E;G-U<R!O9B!T:&4@;65E=&EN9R!P87)T:6-I<&%N=',N#0U#;VYT<FEB M=71O<G,@;V8@9&]C=6UE;G1S(&%R92!R97%U97-T960@=&\@86QS;R!B<FEN M9R!A="!L96%S=" Q-2!P87!E<B!C;W!I97,@;V8@=&AE:7(@9&]C=6UE;G1S M(&9O<B!D:7-T<FEB=71I;VX@870@=&AE(&UE971I;F<N("!0;&5A<V4@;F]T M92!T:&%T('1H:7,@<F5Q=6ER960@;G5M8F5R(&]F(&-O<&EE<R!I<R!S=&5A M9&EL>2!D96-R96%S:6YG()8@;W5R('!R:6UA<GD@;65A;G,@;V8@9&]C=6UE M;G0@9&ES=')I8G5T:6]N(&ES(&5L96-T<F]N:6,L(&%N9"!O=7(@;65M8F5R M<R!A<F4@97AP96-T960@=&\@9&]W;FQO860@9&]C=6UE;G1S(&EN(&%D=F%N M8V4N("!);B!E>'1R86]R9&EN87)Y(&-I<F-U;7-T86YC97,@:6X@=VAI8V@@ M96QE8W1R;VYI8R!C;W!I97,@:&%V92!N;W0@8F5E;B!U<&QO861E9"!T;R!T M:&4@9G1P('-I=&4@870@;&5A<W0@=&5N(&1A>7,@<')I;W(@=&\@=&AE(&UE M971I;F<L(#(U('!A<&5R(&-O<&EE<R!S:&]U;&0@8F4@8G)O=6=H="X-#41O M8W5M96YT<R!M87D@8F4@<VAI<'!E9"!T;R!T:&4@:&]T96P@;F\@96%R;&EE M<B!T:&%N('1H<F5E(&1A>7,@:6X@861V86YC92!O9B!T:&4@;65E=&EN9RX@ M(%1H92!A9&1R97-S('-H;W5L9"!R96%D(&%S(&9O;&QO=W,Z#0U7:&ES=&QE M<B!$96QT82!297-O<G0+8R]O(&=U97-T(&YA;64+-# U,"!7:&ES=&QE<B!7 M87D-5C Y(#%"- M7:&ES=&QE<BP@0D,+0V%N861A!U1E;#H@("LQ(#8P-" Y M,S(@,3DX,@U&87@Z("LQ(#8P-" Y,S(@-S,S,@<'#4EF('EO=2!A<F4@<&QA M;FYI;F<@82!V:61E;W1A<&4@9&5M;VYS=')A=&EO;B!O9B!R96%L('1I;64@ M8V]D96-S+"!S:6UU;&%T:6]N(')E<W5L=',L(&5T8RXL('!L96%S92!C;VYT M86-T('1H92!M965T:6YG(&AO<W0@*&%T(&%D9')E<W-E<R!L:7-T960@86)O M=F4I('1O(&EN<W5R92!T:&4@<F5Q=6ER960@9F%C:6QI=&EE<R!A<F4@879A M:6QA8FQE+@U9;W4@87)E(&5N8V]U<F%G960@=&\@=7-E('1H92!-4R!7;W)D M('1E;7!L871E(&%V86EL86)L92!O;B!T:&4@42XQ-2!F=' @<VET92 H<3$U M92YD;W0I('=H96X@<')E<&%R:6YG('EO=7(@8V]N=')I8G5T:6]N<RX-#5!L M96%S92!N;W1E('1H870@=&AE<F4@:7,@82!1,3$@4F%P<&]R=&5U<BU'<F]U M<"!M965T:6YG(&9O<B!31S$V('=H:6-H(&ES(&%L<V\@=&%K:6YG('!L86-E M(&%T('1H92!S86UE('1I;64@86YD(&QO8V%T:6]N+@T-22!A;2!L;V]K:6YG M(&9O<G=A<F0@=&\@82!P<F]D=6-T:79E(&UE971I;F<@=VET:"!Y;W4@:6X@ M4&]R=&QA;F0N#0U3:6YC97)E;'D@>6]U<G,L#0TO<R\@1V%R>2!3=6QL:79A M;@U'87)Y(%-U;&QI=F%N"U)A<'!O<G1E=7(@9F]R(%-',38@475E<W1I;VX@ M,34+4&EC='5R951E;"!#;W)P+B @32]3(#8S-0LQ,# @36EN=71E;6%N(%)D M"T%N9&]V97(L($U!(# Q.#$P!PL+5&5L.B @*S$@.3<X(#8R,R T,S(T"T9A M>#H@*S$@.3<X(#<T.2 R.# T"T5M86EL.B!G87)Y<T!P:6-T96PN8V]M!P<- M4&%G92 34$%'12 4,A4-#0T-' "A 0"7 )D(I- OI> ]IJ %IZ %J(D%J6X$ MJ@ !(<' 4'AX %!T@ X7&@ ,%1D $1D@ !<?)@ *$AD #Q<> !,=) / M&2 $!P@ !@D* :)RD '"HI !@H(0 6)2$ %R4D !0@)@ 6("H %!TJ !<B M*@ 7(BH &24I !,?)0 3'20 %A\H !@A)0 8(20 &",A !4A(0 2'24 $Q\I M !0?)P 3'R4 %R(F !<B)@ 1'R4 $1\E XA) 2)2@ %RTK !,I)P 1*"0 M$RHF !$F) 1)28 %"@M !4G+@ 7*"L %B4H !@F)0 3(2 $A\= ! <' < M*BD *#,W "PW.P N.#\ 'BDQ !\L- =+30 'S ] "@]4P H/%L ,4!A #5 M8 S/E0 '"Q# "I&9 P D0T )(- "*$ (!$ .H5 #L%0 =1L M (X; "A&P M!L ,@; #2&P ^!L (< >' )AP $T< !7' M^AP = )'0 "AT %$= !2'0 6AT %P= "D'0 KAT +8= "Y M'0 #!X \> 0'@ %AX ),> "C'@ )" % @ "O( OR #HA M !=(0 KR$ +,A +(@ 8"( "(C Q(P 9R, !TD G) LR0 M ,(D !9)0 <R4 'TE "K)0 K"4 -8E #R)@ ^B8 +8H "W* MO"@ +TH #"* PR@ ,0H #%* R"@ ,DH #G* _?G] /WV_?/] M\_WS_?/]\_WS_?/]\_WS_?/]\_WS_?#]\/WS_?/]\_WS_?#]\_WS_?/L_?/] M .H _0#]\_T Z.+@XMSB #: M M G4! 90$P!A 0 U 3 MU 40$ % 3 -C& "5H$ !U6!5H%= @ % M5H%= @ %58%= @ %70( : $&70( 8Q8 -= @ 2 # U P ; , &T# M ": P FP, .L# 2! .P0 #P$ !3! 5 0 H& !2!@ F08 M +T& #-!@ _08 /4 9 D\ #U &0)/ ]0 !D"3P /4 9 D\ #U &0 M)/ ]0 !D"3P /4 9 D\ #U &0)/ ]0 !D"3P /4 9 D\ #U &0)/ M]0 %D"3P /$ 9 D\ #- &0)/ J0 !D"3P (4 9 D\ !A &0)/ M(P " $-"Q&\!A/D_A4H PT_P$ " 0 $ &P$ "W M (P " $-"Q&[!A/E_A4H PT M_P$ " 0 $ &P$ "W M (P " $-"Q'K Q/E_A4H PT_P$ " 0 $ &P$ M "W (P " $-"Q$W M A/E_A4H PT_P$ " 0 $ &P$ "W M P %2@ * S 0\. 0X!* %" =P" M 1_08 T' !'!P D@< +4' ," 3 @ '8( "0" P@@ ! ) M Y"0 W !D"3P +@ 9 D\ "X &0)/ N !D"3P )0 9 D\ "X &0 M)/ N !D"3P +@ 9 D\ "X &0)/ <0 !D"3P $T 9 D\ M ", @!#0L1-P(3Y/X5* ,-/\! @ M $ ! !L! MP M "( T+$>P#$^3^%2@ ##3_ 0 ( ! 0 ; 0 +< M C ( 0T+$3<"$^7^%2@ M##3_ 0 ( ! 0 ; 0 +< M C ( 0T+$>L#$^7^%2@ ##3_ 0 ( ! 0 ; 0 M +< C ( 0T+ M$;P&$^3^%2@ ##3_ 0 ( ! 0 ; 0 +< M LY"0 D D *X) #."0 ?@H *8* "X M"@ S@H .H* #_"@ W !D"3P -P 9 D\ "Y &0)/ E0 "D"3P '$ M 9 D\ !Q &0)/ <0 !D"3P $T 9 D\ !- &0)/ M (P " $- M"Q&\!A/D_A4H PT_P$ " 0 $ &P$ "W M (P " $-"Q&[!A/E_A4H PT_P$ " M 0 $ &P$ "W M (P " $-"Q$W A/E_A4H PT_P$ " 0 $ &P$ "W M (@ #0L1[ ,3Y/X5* , M-/\! @ $ ! !L! MP M ", @!#0L1[ ,3Y/X5* ,-/\! @ $ ! !L! M MP "?\* 7"P MM0L ,@+ #L"P @P !@, !<# JPP /L, !9#0 W0 !D"3P +D M I D\ "5 &0)/ E0 !D"3P )4 9 D\ #= &0)/ <@ !D"3P '( 9 D M\ "Y &0)/ 3@ !D"3P M ", @!#0L1. (3Y/X5* ,-/\! @ $ ! !L! M MP "( T+ M$3<"$^7^%2@ ##3_ 0 ( ! 0 ; 0 +< M C ( 0T+$;L&$^7^%2@ ##3_ 0 ( ! M 0 ; 0 +< M C ( 0T+$3<"$^7^%2@ ##3_ 0 ( ! 0 ; 0 +< M B -"Q&[!A/E_A4H PT M_P$ " 0 $ &P$ "W M *60T )(- "3#0 D@\ ),/ ")$ BA )D0 "H$ MMQ ,T0 #5$ '1$ !X1 ?$0 (!$ ,@1 #)$0 TA$ .P1 #M M$0 ]!$ X2 /$@ '!( "42 F$@ -A( -T 9 D]P#2 &0)/ MT@ %D"3P -( 9 D\ #" .0)/ P@ !D"3P +X 3T*\ "^ $]"O O@ ! M/0KP +X 3T*\ "^ $]"O O@ $D0OP +X 9$+\ "R &1"_ JP !D"3P M *@ I D\ "H &0)/ O@ !P@KP +X 1P+\ "7 $<"_ O@ !P@KP +X M 1P+\ "7 $<"_ O@ !P@KP +X 1P+\ "7 $<"_ O@ !P@KP 0 8 M 1D!N&P NPD "0 ) D "0 ) +X( *N!D@2/!X @ ,P$ !A ,P$/!@+@ M$, A + 8 1D!M@$ N&L O@@ I7_J H/%P # S 1@! \ #,!#Q< M!S@$H 4(!W (E!$*%%@@ @ "@ ,P$/#@ $. 2@!0@'< @ M "( T+$3<"$^3^%2@ ##3_ 0 ( ! 0 ; 0 +< M !LV$@ /Q( $ 2 !!$@ :10 M + 4 #6% UQ0 *45 H%P T!< #,8 T& (QL "0; "U&P M_ !' OP .L 1P+\ #H &0)/ Z &D"3P ,( 9 D\ "< &0)/ Z ! MD"3P .@ I D\ !Z 20)/ >@ "D"3P 'H 9 D\ #H &0)/ Z (D"3P M &\ 9 D\ !O *0)/ M * S 0\. 0X! @'E!%8( ( M(0 #0L1&P$3Y?XS 0PT_P$ " 0 $ &P$ "W M E -"A%H 1.8_C,!##0 $( ! M@ @!H 0 "X M#P4 6@! )0 #0H1: $3F/XS 0PT !" 8 $ : $ N M \% %H 0 ( #,! M ! !@!&0&X; "["0 ) D "0 ) D O@@ JX&2!(\'@ # S 1@!#[4; M #4&P !!P "@< !9' 6AP - < #1' T1\ -(? =( 'B M %$@ !2( H"$ *$A #B(@ XR( -8D #7) 6"4 -8 9 D\ "L M &0)/ @@ !D"3P (( 9 D\ !W &0)/ =P "D"3P '< 9 D\ !W B0 M)/ =P !D"3P '< 9 D\ !W &0)/ =P !D"3P '< 9 D\ !W 20)/ M=P !D"3P '< !) D\ !W &0)/ <P %D"3P ' 9 D\ !P *0)/ @ M,P$ P %7@ * S 0\. 0X! @'E!%8( ( *0 #0H1&P$3Y?XS M 0PT !" 8 , &P$ N M \. 0X! @'E!%8( ( *0 #0H1&P$3Y?XS 0PT ! M" 8 ( &P$ N M \. 0X! @'E!%8( ( *0 #0H1&P$3Y?XS 0PT !" 8 M $ &P$ N \. M 0X! @'E!%8( (46"4 %DE "0)0 K"4 ,(E #7)0 V"4 -DE M "C)@ 'R< " G "<)P G2< . G #A)P \B< /,G %* <"@ M +4H "V* MR@ ,8H #'* R"@ ,DH #] &0)/ ^0 #!@CP /D M P8(\ #Y $&"/ ^0 !!@CP .T 08(\ #B &0)/ X@ "D"3P -X I D M\ #B &0)/ X@ "D"3P .( 9 D\ #B &0)/ X@ !D"3P .( 9 D\ #B M &0)/ UP !D"3P ,\ !341\ #/ 4U$? Q %-1'P .( 9 D\ # M O@ +X #B &0)/ M M ! Q( !0$S M 0 * 8 1D!N&P O@@ I3_H1&N(P !P ,P$8 0\% %($@ 8 #,! M#P4 4@2 P %7@ * S 0\. 0X!* %" =P" "P & $9 M ;8! +AK +X( *5_W$(31$ P ,P$8 0 " S 1D. !8 " ! $L #P M ' 0/'_ @ < 9.;W)M86P ! #, P!A"00 M (@!!0/+_H0 B !9$969A=6QT(%!A<F%G<F%P:"!&;VYT M @ /Y/ 0#R " "4EN9&5N=#(K,@ " / !$< A,Z_P ( #^3P$ M @$@ 9(96%D97( # 0 \( +@$, A 0( %H _D\! !(!6@ (0G5L;&5T M,#$ 0 1 T+$1L!$^7^##3_ 0 ( " 0 ; 0 +< M P!= @ ( #^3P$ (@$@ 9&;V]T M97( # 2 \( +@$, A 0( !P _D^B #$!' +4&%G92!.=6UB97( , M8Q0 !X _D^B $$!'@ )2'EP97)L:6YK ' %X!8@)C% ( @0 $ 4@$@ M 9&;V]T97( # 5 \( *X$7 C 0( #))0 P#)* #_____ M! $(?__ 0 (/__ @ $(/__ P (/__! & D #87 #9(@ R24 M 1 $ [0 ( R@ , #.!@ N"4 ,DE "> M!@ 8 $ !, P YR@ !4 , /T& Y"0 _PH M %D- V$@ M1L %@E #)* %@ 7 !@ &0 : !L ' = ,DE % M"P T 3 $R&4_Y6 !? 7P &< !G : M &H !X @ (( ", 2P$ $P! !2 0 4@$ (," ) P M"@, )(* '"P $0L !@+ B"P W L .8+ !&#@ 1@X $P. !, M#@ 50X %4. #:#@ ZPX /P. -#P B1 (L0 #_$0 !Q( .@2 M #L$@ ,Q4 #,5 !U& CA@ + 8 "Q& S1@ ,X8 G&0 6!D M /D9 #Z&0 4!H %$: !5&@ 61H *0: "D&@ MAH +D: #/&@ MSQH - : #1&@ TAH -4: #8&@ VQH -X: #A&@ YAH .<: G M&P *AL $,; #0' $1T !@= D'0 4!T *,= "M'0 KQT +0= M "_'0 .AX %T> #9'@ W1X .,? #6(0 HR, !\D ! ) 2B0 M )HD "=) _"0 0E *)0 $B4 !,E =)0 ,R4 #TE ![)0 M?24 ) E "2)0 I"4 +0E "Y)0 ! ' 0 !P $ < ! ' !P !P < M < ! ' 0 !P $ < ! ' !P !P < < ' ' 0 !P $ < ! ' 0 M!P $ < ! ' 0 !P $ < ! ' !P !P $ < ! ' 0 !P $ < ! ' M 0 !P $ < ' ' 0 !P $ < ' ' !P !P < < ! ' !P !P $ < M' ' !P !P $ < ! < < ' ' 0 !P $ < ! ' !P !P $ < ' ' M !P !P < < ' ' 0 !P $ < ' ' )< $D1R+B!3=&5P:&%N(%=E;F=E M<A]#.EQ724Y$3U=37$1%4TM43U!<<3$U950P<C N9&]C#4=A<GD@4W5L;&EV M86X30SI<=&UP7%$Q-454,%(P+D1/0PU'87)Y(%-U;&QI=F%N,4,Z7&=A<GES M7$=A<GD@4VAA<F5<.3@P-U]Q,357:&ES=&QE<EQQ,35E5#!R,"YD;V/_0$A0 M($QA<V5R2F5T(#10 $Q05#$Z $A04$-,-4U3 $A0($QA<V5R2F5T(#10 $A0 M($QA<V5R2F5T(#10 0!!)0 0 #9P & 0 ! M /X ?P $ 0!8 @$ 0!8 @0 M 8! " M ! $ 35-51$X#2% @3&%S97)*970@-% M #D 0 #L! 0 9 * 2% @3&%S97)*970@-% M ! $$E ! -G 8! $ _@!_ 0 ! %@" M 0 ! %@"! M !@$ ( $ M0 !-4U5$3@-(4"!,87-E<DIE=" T4 .0! M .P$ ! !D H #@ $ )1( "42 ' $ 0 E$@ "42 M Q !46D $ %1I;65S($YE=R!2;VUA;@ ,%I ! @!3>6UB;VP "R:0 0 M07)I86P (@ $ $(B!@ - " "I 0 !:5"9F+8,F1C)4)F8$ !\ !T M!0 &1\ 0 #P 0 Q!" $ $ ! "$# M '4 !+5$\Z7U-',38@17AP97)T<R!O;B!)5%4M5"!1=65S=&EO;G,@ M,3$M($-I<F-U:70@4W=I=&-H960@3F5T=V]R:R!M=6QT:6UE9&EA "51O M;2!'96%R>0U'87)Y(%-U;&QI=F%N $9FD0!*8I 4U^5 %-< ME0!&6Y( /%N0 #MCE [8Y@ 06*A $!>GP \6I, /5^5 #QBF ^9IH 0FJ; M $1KGP!&::$ 1&:B $-HH@ T6(X 26F: $9DE0!!6Y< /U:4 #5,A Y48L M/V"? $AKKP!$9*L 26FP $IPL !);:T 4W&R $]MK@!,;Z< 4W:U %5WPP!: M>\0 4'2B "M9B0!<G>@ +%^H #=!:0!/3V< 0EMO "U37P V8UH 2H" %^A MQ >68H 0&*& $%;>0!(:H( .G)] ".#> !TU\, N_[O +_UZ "X]^< SO_Y M -#V\ #(Z_4 D;[@ $%OGP Z8I( 2F*& )&2G #X[OH S\GR (F9O0"KY^$ MK>;H 'R*OP!\ALP A;;H &^LU " K]L I,K_ &6(R@!(:ZT 5'FK &6(H@!Q MCXH S-C2 //@^0#!K., =GW4 &*!U@"5S/\ 0 ( # ! 4 M & !P @ ) "@ L , #0 X / $ M !$ 2 $P !0 5 %@ !< 8 &0 !H ; M' !T > 'P " A (@ /[____]____)P /[___\O M _O_________________________________________^____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M__________________________________________________________]2 M &\ ;P!T " 10!N '0 <@!Y M %@ % ?__________ 0 ) @ P M $8 P+[\U9*8O0& M?$E1IF] 28 ! _____U< ;P!R &0 M1 !O &, =0!M &4 ;@!T ____________________________________ M______________\: (! @ , #_____________________________ M________________________ )Q$ #_____ 0!# &\ ;0!P $\ 8@!J M ________________________________________________________ M_____Q( @'__________________________________________P M :@ /____\% %, =0!M &T 80!R 'D 20!N &8 M;P!R &T 80!T &D ;P!N __^U_______T?______MO______?O___* " M ?____\$ ________________________________ M ( , @ _____P$ #^____ P 0 % !@ < ( M "0 H #^____# T . #P /[_________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________ 0#^_P,* #_____ M D" # 1A@ !-:6-R;W-O9G0@5V]R9"!$;V-U;65N= * M 35-7;W)D1&]C ! !7;W)D+D1O8W5M96YT+C8 ]#FR<0 M -#/$>"AL1KA #^_P ! " M ! X(6?\OE/:!"KD0@ *R>SV3 #< 0 $@ $ "8 M @ * # ] 0 0 !0 !0! & ( $ < L M 0 " $ ! ) 6 $ !( !D 0 "@ (P! + F $ P M "D 0 #0 + ! . O $ \ #$ 0 $ ,P! 3 U $ M ( #D! '@ $P !43SI?4T<Q-B!%>'!E<G1S(&]N($E452U4(%%U M97-T:6]N<R Q,2T@0VER8W5I="!3=VET8VAE9"!.971W;W)K(&UU;'1I;65D M:6$ '@ $ 640 '@ H !4;VT@1V5A<GD > 0 M0 > 0 &0 > "P $YO<FUA;"YD;W0 !X . 1V%R M>2!3=6P% $0 ;P!C '4 ;0!E &X = !3 '4 ;0!M &$ <@!Y $D ;@!F &\ M<@!M &$ = !I &\ ;@ . " /_______________P M L L 0 M M ________________ M M M #_______________\ M M M /_______________P M /[_ $ ( M $ "U<W5G"X;$).7" K+/FN, /P ( 0 $@ / M4 0 !P !0 '@ & @ L "( $ ) , M F ( #D! '@ !< !2;V-K=V5L;"!396UI8V]N9'5C=&]R M # &( , !" P \ + L #! M ( > 3 %1/.E]31S$V($5X<&5R=',@;VX@2515+50@475E<W1I M;VYS(#$Q+2!#:7)C=6ET(%-W:71C:&5D($YE='=O<FL@;75L=&EM961I80 # M !DL- 4)# #1@@ !$;(@ 3)"$ $"$= !,C' 0'1L &2(E !0< M(P 3(2< $!\B X?' 6)"( %" @ X;'0 ,&QX #A\B !(E* *(2, !B4D M TK+ <,3D ,$54 "%#4P ?/E, *#A/ "LS2@ ?+SP (S([ "DY/P N/4 M(3 S !XK,P 3'2X )S)( ",P1@ H-DD &B,Q "4N. H,CD '"HP ! H+@ 7 M,C8 'S8X !PP-0 @,3X &"D\ \@.@ B.5, )$A@ != 5@ 605( %#I, !HV M3@ =,E$ (#9: "$V7 E/6$ (#13 !HI/ .&"D &R,T "(P0@ D.U$ )T)< M "](8@ M16, ,$9J #A1>0 I37, +E)Z "Y3>0 X6($ .%!^ #U7A@ S5X4 M-EV* #=;BP X68H /EV0 #U<D0 \6Y 0E^8 $AEG@!.:J< 2F:F $UHJP!* M:JP 46^V %!RN !=?L< 47; $YSO0!2><, 5GO% %E\Q@!:>L4 6W[' &"& MS@!>BM$ 5H3+ %6%S0!=BM0 7(;1 &B/W0!BB=@ 9X_A &&.WP!;B=T 5X;: M &&-X !$;+0 /ER= $59DP V0'8 -S]N #,Z90 Q/6$ )#-4 "$S4@ C,E( M'RU) "<R30 M.TX )C1' "LZ5 N05P *D9> "E"7 E.E8 -$1H #%(;@ U M3G@ *DQW "1":P =-5D )CE< #A*:0!"578 -TQL "U 80 U0U\ -D)> "D] M7 U2VX -4QR #M3?0 T4'D +4IV "]2?0 M37@ -4MU #Q/>@ Y57X .55^ M #E0?0 Z4'H .U5] #A:?@ K57H +5E^ #5;?@ Y67T 1F"% $A>B !%7(H M0E>. $!5D@!08J, 5V.E %%;FP!589L 66:: %IIEP!/7) 2E>; %1@K@!( M5Z 1%29 %!CG !J>ZX 7FR< %5@F0!>:K( 6&6S %EMM !19Z$ 46R1 %-L MF !4;;, 56J[ %YXNP!3<:H .6>0 "M4:P!,7ET 7VAU (N@UP!C@L< .F*2 M $EQC0!$:&@ 16EO '6GRP!'AJP 8;6[ (73V@!2AJL -5^" $)]>0":U\, MR_WK -'_]0# ^_, G>3H %&GO0!<L<L I./Q *+;]0! @;X 5J+3 )SRZ@"S M^MD XO_H /+_\P#+[.@ L+[0 .+![@#@O^L T>7P -#X\P#B_/8 SNGW &>2 MPP!AB,8 >HBX 'Z G@#N\?8 VO#N )K;XP"4X_@ A\GR 'FWYP![P.< G./_ M )G<_0":S>$ Z/[Y /K_\ #^_O( _O[R /C^ZP#\_^\ _O_M /__[P#__^\ M___O /__[P#__^\ ___O /__[P#__^\ ___O /__[P#__^\ ___O /__[P#_ M_^\ ___O /__[P#__^\ ___O /__[P#__^\ ___O /__[P#__^\ ___O /__ M[P#__^\ ___O /[^[@#___ _O[N /CXZ 9(A\ &B,@ !LD(0 9(A\ %2 > M !<B( 5(2$ #AH: X;'0 1'B "1@; H9' *&B #Q\E !0G+ 8*"X M'RTS !PH+@ 5("0 $ATA !(;'P 4'2$ %!\C !4@) 7(RD $AXD !,B)0 , M&QX %"0C 86%0 3(AX $2(> !(G'@ 7+"D '"\V ",P0 ;(30 $Q4G !(8 M(P 4'", 'B0I !L>)@ K+#H )RHX L5'P 0'R( $20; !@G'P 4'AX #Q@< M T<'P -(", $RLI <D(0 %)", "B4I "$Q/0 Q15< ($5; !]%70 K/U@ M+3Q/ !LN.P 9+SH (#I& !PT0 E.40 'S$\ "0U0@ D-$0 )#1$ "<T0@ ? M*3 )2LP "PR-P G+S8 &24Q !HE,P C+#8 (2LU !HN,P 8*S( &BDR "0P M/ C,3T 'S(Z !\Y/P 9,SD 'S4[ !\Q/ @+D &2@[ !,L/ 0+3L $S8Z M !@U.@ ;*C, '"8W !\Q2 4*T4 +4-< "U"7@ [37( -DET #)2>P P4WL M-UN! #53? _584 .$^! #A:B W6XD -E>( #E8BP!"890 1629 $5DF0!* M9Z 3&FB $]KJ !-::D 1V*E $YKK@!-:J\ 6':] %1RN0!5=;X 5G;! %-Z MR !0=\8 5WO) %9WQ@!8>\4 8H?1 %^(T0!8@\P 5X++ %F!S !:@LT 78+2 M &*)V !AB=P 8(_A %6'V0!4C=P 3'W! "=#<@ M.U\ +CM5 "TY40 H.U8 M*SY9 "<U3 M.E +#I- "LY3P K/%< *CA5 "LR4P M-E< (CA4 " Y4P M M/%8 ,D)9 "I 60 F/UD 'SM: "Q%9P L1&@ ,$9I "M%8P O1V, +D-? #%% M9 K1&0 ,$EK #A-; R1F4 -TAI #-':@ T4G4 +DYR #90> N2' -%-Z M #13>@ X4G8 /%1X #]5> !"5GD 055X $%3> [3GD 0%!^ $14@@!.7HP M3&*, $EABP!29Y0 5V:7 %IBG0!G:JX 8FBU &AQP0!K=\D :G7% 'E\QP!W M>< ?('& (:,SP")B,P C8G0 'EWPP"(C=@ @9+5 '^.TP",AM< B7C/ (EY MS0"/>=$ FH+@ )9\V@"JEN\ M)CR *J WP"IA=\ IZ#I 'R'P0!-68D -$E? M #%10 !QEHP AK#5 %A\L@!)9HL ,5%N #QNB@ _=Y0 48BC %!\F0!E@:, MJ;_I '*-Q0 \8H4 3X=R ++JP0#=_^@ R_3L *SK^0!UJ,D 4E:) %I8A@"H MRMH B;W* $!QF0 V<), ,X6& )KAT #@_>8 _/_L /__[0#___$ __SR /SZ M\ #Q_O TO7Q )_D]0!7FKD 78.F &*!H !VJKL C]#8 *WX^@"2XND ;;K4 M '7#YP!UQND ;K_E &FZX !^S_ B^3O +3U]@#D^_8 __[T /__\@#__ND M___C /__YP#__^P ___O /__[P#__^\ ___O /__[P#__^\ ___O /__[P#_ M_^\ ___O /__[P#__^\ ___O /__[P#__^\ ___O /__[P#__^\ ___O /__ M[P#__^\ ___O /__[P#__^\ ___O /__[P#__^\ _O[N /__\ #^_NX ^/CH M !,?(P 5(24 &"0H !DE*0 9)2D '2DM !LG*P 4("0 $1TA !,?(P 0'" M#!@< P8' 0'" &R@J !PH+ =*2T &24K !DD* 6(24 %" B !(>( 3 M'R$ %R,E !,B)0 4(R8 #1XA !$B)0 /'QX #Q\> !(A'0 1(AX #2$< !,G M* <+CD )"]# " B.@ 6%"H &1DI !P>*0 B)2T ("$K #(Q00 Q,4, %1TJ M !LF+@ 7)20 %2(@ X='P -'!\ $!\B \>(0 5)R8 $B(A !(A(P 2("8 M&2<S "4Y2P A05@ ($%; "-"60 E/E( '#1 !\S/@ L/$P *#5% "DP/P L M,T( *C1% #(^4 I-TD +SQ, "(N. ;*# (C,\ "L_2@ >-$ $"8R !0H M,P 5+S8 !RTO PU. 2-3D #2DP !<L- ;+#4 %R<N "(R.0 3)BX &"@T M !\H-@ D*#H (B0V "8I. ?*S< (RTW "$I, 5&20 (2@[ !\J0 Z2%X M,T1> $14> \3G< /E: $%:A@ ]5W\ 0EN' #9.@@ Z5(H -5*% #E9B@ Y M5HD .E>* $1@E@!)99L 2V:> $]JHP!/:J, 4&FG $QGIP!/::P 3FBK %5N MM !1:K( 67*Z %=PN@!C?\P 6'W- %%VR@!;?= 6WO. %U^S0!EB=< 88C3 M %Z&T0!8@,L 6X'/ %V#T0!>@-, 78+4 %N U0!=B=T 6(+; $=PS T3Z4 M*#)R #X\< [-V /3QC #([8 M.5T +SI8 #$\5P F-$H 'B]$ " U2P D M-4\ *C9. #(]6 @,TX (31/ #(\5 R.E$ +C]4 "D[4@ D.50 *CQ9 "T_ M7@ H.%4 (31/ "X_60 Q0EP -D=B "Y#8@ P0V0 -41E #I#90 X06, /TEK M "]%: X47, -4UQ #90= T5WD ,UAZ #58>0 U5G< -5=T #E9=@ Y6W, M.%9S #]:?P X5G\ .V.- $!JE _:90 16J6 $IMF0!0=*0 47JQ %Z*R0!? MC-4 :)3A &F4XP!FDM\ ;Y_G &ZBY0!TJ.H =JGH '^NZP",N/4 C+'O )6\ M\P"0Q.T ;&EV86X 0 > @ #0 .34> '@ $UI8W)O<V]F="!7 M;W)D(&9O<B!7:6YD;W=S(#DU 0 !ZI50$ 0 ",<U6QE+T! M0 !DZ5RVE+T!0 .#!I&F;T! P 0 # = 4 , 9 M'P P #0SQ'@H;$:X0 ^ , _O\) 8 M $ D _O\ 0 @ 0 M +5S=6<+AL0DY<( "LL^:XP _ @ ! 2 \ !0 M! ' % > 8 " "P (@ 0 D P "8 M @ .0$ > %P %)O8VMW96QL(%-E;6EC;VYD=6-T;W( , M 8@ P $( # #P L "P ,$ @ M !X !, 5$\Z7U-',38@17AP97)T<R!O;B!)5%4M5"!1=65S=&EO;G,@ M,3$M($-I<F-U:70@4W=I=&-H960@3F5T=V]R:R!M=6QT:6UE9&EA , 7 T,\1X*&Q&N$ !T end

1 0

?
by L. Goegebeur 16 Jun '98

16 Jun '98

A: INTERNET--IBMMAIL De: Laurent GOEGEBEUR Alcatel Espace DSPS/DESR Tel: 05.34.35.65.87 E-mail: goegebeur(a)bigfoot.com --------------------------------------------------------------- Objet: help Salutations. //// Laurent Goegebeur. (. .) ---------------------------oOO-(_)-OOo-------------------------

1 0

Any H.323 Terminal application with RAS channel?
by Vincent S.H. Chen 15 Jun '98

15 Jun '98

Dear All, Are there any H.323 Terminal application which supports RAS channel can be downloaded? Thanks! Best Regards, Vincent Chen Visual Communication Software Department Application Software Development Div. Acer Inc.

1 0

Report of the Cannes meeting
by Sakae OKUBO 13 Jun '98

13 Jun '98

Dear Q.12-14/16 experts, The Cannes meeting has successfully been finished. As I cannot edit the meeting report (APC-1425) in a neat form during the next week, I have uploaded Can_rept.zip at ftp://standard.pictel.com/avc-site/Incoming/Can_rept.zip which contains the reports of Q.12/16 (TD-20.doc), Q.13/16 (TD-21.doc) and Q.14/16 (Td-22r1.doc). This is attached to this message. Other TDs will be uploaded early next week by the meeting host. 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

informal comments on Liaison to SG16 Q.13 re T.38 Annex B (Toga, Kumar read)
by Dale L. Skran 12 Jun '98

12 Jun '98

David, Herman: Unfortunately, we received your liaison near the end of the day Thursday, which is the last day of the meeting. Although the document was quickly repproduced, it was determined that given the late hour (after 6 PM) that it was too complex to respond to completely. It was decided to send an official liaison that had been previously prepared, with a few minor modifications, to SG8. You should have received this already. It discusses some but not all of your concerns. I also announced my intention to send one or more informal messages to you concerning the questions raised. You can also expect a formal liaison to be generated by the SG16 meeting in September. Keep in mind that I wrote this at 3 AM, so I have probably blundered at least once. Dale Skran Rapporteur, Q13 SG16 WP2 For those who attended the Cannes meeting, these comments refer to TD-29. <bold>Sec 2: Changes needed in Annex D </bold> a)It is not 100% clear exactly what changes are referred to in para 1, but Vineet and I will undertake to look over Annex D for anything that needs to be changed. b)With regard to the two data rate management questions, it is not completely clear why Mgt method 2 is not allowed with TCP. Wouldn't it work in a well managed, high QoS network? c)The liaison from Q13 you have received covers TCP vs UDP in considerable depth. I would like to add some thoughts Mr. Ott and I had since then. We are under the impression that Q3 believes that by using UDP without a back-off mechanism, delay-intolerant fax relay implementations that do not locally generate TCF can be used, while with TCP they cannot be used. Our thought is that if the network is bad enough that the delay caused by the back-off exists, it is probbly a sufficiently bad network that fax relay will not work in any case. d)I believe the sufficient time exists to standardize or adopt a UDP back-off mechanism before decision, so this option should be given serious consideration. <bold>Sec. 3.1 - RAS </bold> a)RAS is the easiest part of H.323 to implement, and has the simplist definition (with the other parts being H.255.0 call signaling, H.245, and RTP/RTCP media processing.) Mandatory elements are clearly identified and are not so numerious. Once you've taken the leap to using ASN.1, the value of RAS easily justifies implementing it. b)The major impact of not supporting RAS is as follows: i)The terminal must use the well known port or support an alternate protocol for getting a dynamic address. ii)The terminal cannot make use of the H.323 E.164 to IP address translation network element, the Gatekeeper. As large H.323 networks are established, this will require establishing a seperate address server for the fax terminals using some other means to achieve the same feature operation. iii)Since network operators and MIS managers use the Gatekeeper to manage bandwidth, they may (and probably will) ban non-RAS compliant terminals and devices. This could limit the market for non-RAS devices. iv)It sharply limits the meaning of H.323 interoperability for the Annex B terminal. v)RAS is the basis for call accounting in H.323 systems. Customers are not likely to purchase equipment that cannot be billed for. There are probably more agruments, but the direction is clear. Keep in mind that the *use* of RAS is always optional, i.e. the user can always enter a full IP address, or maintain a local directory of IP addresses. However, as noted in (v) this prevents call accounting, and thus will not meet the needs of many customers. <bold>Sec. 3.2 Ports & Firewalls: </bold> I invite Mr. Toga at intel to address the subject of H.323 and firewalls in general. Intel has a paper on this topic; also in the H.323 V2 implementors guide we have just added a section dealing with NAT and with some other firewall related topics. As soon as Mr. Toga incorporates this material, I invite him to send you both a copy. With regard to the use of 1 port for both call setup and T.38 messages, the main issues are: a)Distinguishing between the H.225.0 messages and the T.38 messages is difficult since there is no common system of headers b)If a header is added, this is overhead c)For systems that may wish to use a TCP link for call setup, and UDP for T.38, having a single port seems problematic [maybe I'm confused on this one] d)Switching from fax to voice is more complex as a new port needs to be opened for voice; mixing voice and call signaling does not seem like a good idea. There are more agruments that we have presented in past liaisons, perhaps Mr. Kumar could supply them. <bold>Section 3.3 - Facility message </bold> This is mandatory. Suggest adding language pointing to table in H.225.0 of required messages - Table 4/H.225.0 is the reference. <bold>Sec. 3.4 - Flow Control when using UDP </bold> The formal liaison comments on maxBitRate. This represents the maximum (peak) fax bit rate that the unit can absorb, and should not be exceeded over a period of time. It is interesting that you are concerned about UDP flow control as this is a major issue with UDP. TCP can be relied on to throttle a high-speed internet fax device to match a 4.8 kbps G3 device, but with UDP it is unclear how this will happen. maxBitRate can be changed by using H.245 negotation. It is mainly a signal to the sender to not exceed this rate. In the example above, a complient 1 Mbps terminal would note that it is sending to a 4800 bps terminal, and only send 4800 bps. Of course, there are no "standards police" to enforce this. Compliant terminals should not need a UDP throttle. <bold>Sec. 3.5 - ASN.1 </bold> We'll look at it by September. <bold> Sec 4 - Editorial </bold> Seems Ok; Kumar will look at in detail. <bold>Sec 5 Annex D change</bold>s Covered in formal liaison. <bold>Sec 6 - other issues </bold> 1)PIP/PIN and voice switch - I need to think about this more 2)The way fast connect works, you offer the modes you can receive(in this case, TCP and UDP). The receiver of the call picks a mode and this is the mode used. 3)Order indicates preference (it's late, but I think this is true), so a well-behaved terminal should use the cap in the first OLC, thus allowing the transmitter to pick the mode. However, I don't believe this is binding, so in effect the receive picks the mode. [Toby, others, keep me honest here] 4)H.323 call termination - usually calls are terminated with RELEASE COMPLETE, which includes either the Q.931 CAUSE value or <bold>the releaseCompleteReason</bold>. 5)Optional features can be included in OLCs in the Setup message. 6)Issues related to large GWs and using seperate ports - we don't see any. 7)The formal liaison discusses the issue of voice vs fax BW. Plese comment on it, and then we can proceed.

2 1

subscribe
by gatepin 10 Jun '98

10 Jun '98

Dear all, Thanks for adding my name to your e-mail reflector. -- E-mail: Philippe GATEPIN <gatepin(a)lep.research.philips.com> Laboratoires d'Electronique Philips Phone : (33 1) 01 45 10 69 20 B.P. 15 - 22, Av. Descartes Fax : (33 1) 01 45 10 69 60 94453 Limeil-Brevannes Cedex / France

1 0

APC-1410
by Tom-PT Taylor 06 Jun '98

06 Jun '98

APC-1410 has been uploaded to the Incoming directory. Tom Taylor E-mail: taylor(a)nortel.ca (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

APC 1404, 1405 and 1406 Uploaded
by Bhasker, Narjala 05 Jun '98

05 Jun '98

Documents APC-1404, APC-1405, APC-1406 have been uploaded to the incoming directory. Narjala Bhasker Intel

1 0