[itu-sg16] H.323 Annex I

Paul E. Jones paulej at packetizer.com
Tue Sep 29 12:26:59 EDT 2009



I noted a couple of mistakes, so I'll try to fix those with the upcoming
submission.  We'll iron out any others at the meeting, though hopefully they
are all just syntactical issues.


As for the content going forward, this can definitely be expanded.  You
might recall, the intent several years ago was to describe more generally
communication over error prone channels.  The content was narrowed
substantially, but the scope of the document was not.  So, it is reasonable
to expand this document as it makes sense in order to describe how to
communicate over error prone channels.


That does raise a question: do we structure the document now to allow for
other material, or do we re-structure sections later as new material is
added?  My preference would be that, given how short this text is, we
restructure the text in the future if we do add additional content and leave
the current, simple structure in place.  But, I welcome your comments on




From: Sasha Ruditsky [mailto:sasha at radvision.com] 
Sent: Tuesday, September 29, 2009 10:28 AM
To: Paul E. Jones; itu-sg16 at lists.packetizer.com
Cc: Adam Li
Subject: RE: [itu-sg16] H.323 Annex I


Hi Paul,


I want to mention that one area which requires attention in this document is
ASN.1 syntax.

It does have quite a few syntactical mistakes.


Now, probably not for this meeting, I wonder what is the real scope of this

Should it cover for example non-parity types of FEC, such as Reed-Solomon?

Should it allow using H.323 with fecframe (IETF newest framework for FEC)?





From: itu-sg16-bounces at lists.packetizer.com
[mailto:itu-sg16-bounces at lists.packetizer.com] On Behalf Of Paul E. Jones
Sent: Wednesday, September 23, 2009 6:14 PM
To: itu-sg16 at lists.packetizer.com
Cc: 'Adam Li'
Subject: [itu-sg16] H.323 Annex I


Q2 Experts,


Please review the text for H.323 Annex I:



This document did not get sufficient review at the last Rapporteur meeting,
but I would nonetheless like to consent this text at the upcoming meeting.


Annex I was substantially re-written, but it is relatively short and the
focus of the document is not changed: it defines the signaling procedures
necessary to implement FEC as defined in IETF RFC 5103, which obsoletes the
former FEC method detailed in RFC 2733.  Going forward, the intent would be
that if we want to document anywhere how H.323 devices ought to behave in
order to overcome issues with error-prone channels, we might add additional
material to this annex (perhaps even restructuring it if necessary).


In any case, I would kindly like to request that you review this document.
I will make an effort to re-submit it to this meeting unchanged as it appear
here.  However, if you have any comments on the text, let me know this week
or early next week and I'll try to make revisions and share those with the
Experts before I submit the text.


Of course, you are definitely welcome to submit a contribution related to
this text for review at the meeting.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20090929/76036516/attachment-0004.html>

More information about the sg16-avd mailing list