*** to those experts who are concerned with Annex K to H.324 ***

Subject: RE: ITU-T H.324 Proposed Annex K submission Date: Wed, 31 May 2006 17:31:36 -0700 Thread-Topic: ITU-T H.324 Proposed Annex K submission Thread-Index: AcaA6ryG5fbBsGL2Tzqg559dE4T8agD0jQiAABKT+CA= From: "Ralph Neff" <neff@pv.com> To: "Sebestyen, Istvan" <istvan.sebestyen@siemens.com>,"Brody Kenrick" <brody.kenrick@dilithiumnetworks.com>,<Stephan.Wenger@nokia.com>, "Sasha Ruditsky" <sasha@radvision.com>,"???/MS??????" <chanmin@ktf.com>,"Wu Jim-JIMWU1" <jian.j.wu@motorola.com>,"Nikolai Leung" <nleung@qualcomm.com>, <bo.burman@ericsson.com>,"Patrick Luthi" <patrick.luthi@tandberg.net> Cc: "Marwan Jabri" <marwan.jabri@dilithiumnetworks.com>,<simao.campos@itu.int>, "Varga, Imre" <imre.varga@siemens.com>,Pierre-AndrH Probst <probst-pa@bluewin.ch>,"OKUBO Sakae" <okubo@mxz.mesh.ne.jp> X-Biglobe-VirusCheck: Thu, 01 Jun 2006 09:31:45 +0900 X-Biglobe-spamcheck: 0.00%

Istvan,

There has been a bit more work on the draft since Brody sent the previous version for review, and I think the first two points you mention have already been addressed. I'll attach the latest draft, in case anyone would like to make comments on it. This one has the change marks (vs. TD 271/plen), so it will be much easier to verify that all of the changes are editorial. Brody and I have tried to be very conservative on the changes, so we would appreciate feedback if you or anyone else believes that any of the changes would be problematic.

I believe Brody is planning to submit this revised document tomorrow, unless anyone points out problems with it.

Regarding Istvan's latter two points:

1. My presentation slides from the workshop highlight what I think will be the common MONA-to-MONA connection scenarios, but the presentation falls short of stating what the minimum requirements for a MONA terminal would be. (Istvan clearly realized this at the workshop, since it prompted him to ask the question :)

Is the spec clear about the minimum requirements? I think it is, but (being one of the authors) I'm probably not the best judge of this. If any of the technical reviewers on this thread would like to zoom in to check this issue, I'll provide a hint on how you can check it. Here is the summary Istvan gave from our discussion at the workshop, along with some links to where the points can be verified in the MONA spec:

> Ralph told me, that on both the Sender's and Receiver side > A2P is always mandatory and thus the common Fall back,

This is stated up front in the intro (Clause K.2, last sentence) though the real requirement comes out of the negotiation algorithm described in Clause K.7. Start with the text that says:

"At this point the channel negotiation behaviour of the terminal is determined as follows:"

Then follow the bullet points underneath this statement. The first two bullets provide paths where SPC is chosen as the negotiation method. The local terminal can't guarantee that either of these two paths are followed (suppose the remote terminal doesn't support SPC...) so the local terminal must provide support for the path followed in the third bullet:

"In all other cases the terminal shall establish the missing outgoing media channels for each media type using one of the following procedures:"

The first sub-bullet provides a path where a missing channel can be established using MPC. However, this one is a conditional step, and the local terminal can't guarantee that this path can be followed in all cases. In particular the remote terminal might not announce receive capability for the MPC codecs that the local terminal would need to complete the outgoing A/V session. In such cases, MPC is not an option for the outgoing channel.

The second sub-bullet (using A2P to establish one or more missing channels) is the only one that is not presented in a conditional way. Thus this one must be supported for establishment of outgoing codecs. Also, because the A2P sub-bullet is presented as a choice that the remote terminal can make to establish the missing outgoing channel, the local terminal must support A2P for establishment of incoming channels as well.

> while MPC and SPC are only optional, but on the Receiver > side at least one of them has to be implemented.

This should be clear from Clause K.6.2, specifically this text:

"Terminals shall support at least one Preconfigured Channel receive capability.

NOTE: This requirement may be met by setting SPC to 1, or by setting at least one non-zero bit within MPC-RX."

One caveat: SPC is bidirectional, so if you set SPC to 1 it means you can setup the media channels using the SPC (i.e. receive capability for SPC implies as well a transmit capability for SPC).

If there is any need to clarify the minimum terminal requirements beyond what is currently in the spec, we can do this during AAP. We can get some input from the current thread to get an idea of whether this is needed.

2. I think as well that the diagrams need some attention, perhaps some accompanying text to explain them. This also should be handled during the technical review.

-Ralph

-----Original Message----- From: Sebestyen, Istvan [mailto:istvan.sebestyen@siemens.com] Sent: Wednesday, May 31, 2006 7:58 AM To: Brody Kenrick; Ralph Neff; Stephan.Wenger@nokia.com; Sasha Ruditsky; ???/MS??????; Wu Jim-JIMWU1; Nikolai Leung; bo.burman@ericsson.com; Patrick Luthi Cc: Marwan Jabri; simao.campos@itu.int; Varga, Imre; Pierre-AndrH Probst; OKUBO Sakae Subject: AW: ITU-T H.324 Proposed Annex K submission

Brody,

many thanks for this.

A few things:

1) We have to make it really sure that at this stage we have only editorial changes, as the document" is frozen. Once we start the AAP any technical comment can/may come in, that has to be dealth with within the framework of the A.8 AAP process. I think so far this principle has been obeyed, but yet it would be good also to have a document with change marks vis-a-vis the TD 271 Plenary document. E.g. it needs explanation why in a few Tables e.g. Table K.6 now we have "TBD" Values and not "2" or "1" anymore, and what then the TBD values actually should be?

2) I think there are still a few typos in the document. e.g. the numbering of the Tables seem to have problems. On page 19 you start with again with Table "7" (instead of "16") etc... until the last Table. This could be corrected before the Consent.

Regarding the content (to anybody from the Annex K gurus...):

This is of course for a possible text improvent after a possible "Consent" (of course if this is felt to be needed...):

1) Regarding what is "mandatory" and what is "optional" on the sender and receiver side is still confusing to me, as I think I have heard two different stories from Ralph and Stephan in San Diego. Ralph's story can be found on the slides of the Workshop (so basically with one common mode in fall back) ttp://www.itu.int/ITU-T/worksem/h325/200605/presentations/s5p5-neff.pdf. Ralph told me, that on both the Sender's and Receiver site A2P is always mandatory and thus the common Fall back, while MPC and SPC are only optional, but on the Receiver side at least one of them has to be implemented. In Stephan's Version there was no common mandatory mode, no Common Fall back, but everything had to be implemented on the receiver side, but only at least one method on the sender's side. Such basic philosophy, however, determins the complexity of the solution and also the IPR licensing strategy. So, it would be good, if there would be a unified answer and view to this question, or at least if there was a common view, only I did not understand it correctly, what is it?

2) Along the very same line I simply do not understand the symbols of the flow charts on Figure K1 and K2. Before trying to understand the details I need some general guidance, of what is the difference between a "Boxed" text and a "naked" text? Also for the decision boxes, where are the "decision questions" (as "naked" text next to the "entry of the "decision" box)?

Thanks in advance.

Kind regards, Istvan

Dr. Istvan Sebestyen SIEMENS AG COM GCM PS Standards Hofmannstr. 51 81359 M[nchen Germany Tel: +49 89 722 47230 Mobile: +49 171 55 16216 Fax: +49 89 722 28139 e-mail: Istvan.sebestyen@siemens.com

Von: Brody Kenrick [mailto:brody.kenrick@dilithiumnetworks.com] Gesendet: Freitag, 26. Mai 2006 19:35 An: Ralph Neff; Stephan.Wenger@nokia.com; Sasha Ruditsky; $B%1%l%D�;(B $B%[(B/MS$B%7%e%3�?%3!<%&%1%K%?(B; Wu Jim-JIMWU1; Nikolai Leung; Sebestyen, Istvan; bo.burman@ericsson.com; Patrick Luthi Cc: Marwan Jabri Betreff: ITU-T H.324 Proposed Annex K submission

People interested in proposed Annex K of H.324,

A brief notification that I have just submitted the Editor's draft of Annex K to TSB for next month's WP2 meeting. I have attached it for your reference for the few days it may take to appear on TIES.

Please do not hesitate to contact Ralph or myself if you wish to obtain an Editor's copy with track changes turned on, or if you have any other queries.

Best regards, Brody

Brody Kenrick Principal Engineer Advanced Products and Technologies Dilithium Networks, Inc. TEL: +1 707 792-3908 MBL: +1 415 299-9042 FAX: +1 707 792-3744 <mailto:Brody.Kenrick@dilithiumnetworks.com>Brody.Kenrick@dilithiumnetworks.com <http://www.dilithiumnetworks.com/>www.dilithiumnetworks.com

Communications for a Borderless World

This electronic message contains information from Dilithium Networks, Inc. which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

Content-Type: application/x-zip-compressed;name="H.324 proposed Annex K - 2006x05x31(WTC).zip" Content-Description: H.324 proposed Annex K - 2006x05x31(WTC).zip Content-Disposition: attachment;filename="H.324 proposed Annex K - 2006x05x31(WTC).zip"