Fwd:RE: ITU-T H.324 Proposed Annex K submission
OKUBO Sakae
okubo at mxz.mesh.ne.jp
Wed May 31 22:18:39 EDT 2006
*** 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 at pv.com>
>To: "Sebestyen, Istvan" <istvan.sebestyen at siemens.com>,"Brody
>Kenrick"
><brody.kenrick at dilithiumnetworks.com>,<Stephan.Wenger at nokia.com>,
>"Sasha Ruditsky" <sasha at radvision.com>,"???/MS??????"
><chanmin at ktf.com>,"Wu Jim-JIMWU1" <jian.j.wu at motorola.com>,"Nikolai
>Leung" <nleung at qualcomm.com>, <bo.burman at ericsson.com>,"Patrick
>Luthi" <patrick.luthi at tandberg.net>
>Cc: "Marwan Jabri"
><marwan.jabri at dilithiumnetworks.com>,<simao.campos at itu.int>, "Varga,
>Imre" <imre.varga at siemens.com>,Pierre-AndrH Probst
><probst-pa at bluewin.ch>,"OKUBO Sakae" <okubo at 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 at siemens.com]
>Sent: Wednesday, May 31, 2006 7:58 AM
>To: Brody Kenrick; Ralph Neff; Stephan.Wenger at nokia.com; Sasha
>Ruditsky; ???/MS??????; Wu Jim-JIMWU1; Nikolai Leung;
>bo.burman at ericsson.com; Patrick Luthi
>Cc: Marwan Jabri; simao.campos at 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 at siemens.com
>
>
>
>
>Von: Brody Kenrick [mailto:brody.kenrick at dilithiumnetworks.com]
>Gesendet: Freitag, 26. Mai 2006 19:35
>An: Ralph Neff; Stephan.Wenger at 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 at 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 at dilithiumnetworks.com>Brody.Kenrick at 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"
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: H.324 proposed Annex K - 2006x05x31(WTC).zip
Type: application/zip
Size: 291966 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20060601/df5088ba/attachment-0003.zip>
More information about the sg16-avd
mailing list