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