Please Review corrections for H.225.0v4 and H.323v4
Experts,
As you know, I have posted a document to this list a number of times seeking comments on corrections that need to be applied to H.323v4 and H.225.0v4. I was given permission by the TSB to make these changes, but before such changes are made, I want to give you one last opportunity to comment. To this date, every comment that I have received has been one of agreement-- I have heard no objections.
The ASN.1 found in this document is the same as that which has been posted to the Packetizer web-site and I know that several companies have already grabbed that ASN.1 for implementation purposes.
I don't believe there should be any contentious issues in this document, but I wanted to give you one last opportunity to review and comment.
Please send comments directly to me and/or post them to this list. If I hear no objections, I will forward this document to the TSB for inclusion in the final published H.225.0v4 and H.323v4.
Thanks, Paul
Folks,
I have attached what I hope is the final revision of the changes to H.225.0v4 and H.323v4. The additional changes are in response to e-mails I have received.
The changes from the last revision include new sections 1.5, 1.9, and 2.2. There are no additional ASN.1 changes.
These changes were necessary in order to align the text between H.323v4 and H.225.0v4.
Please give me any comments by the end of the business day Tuesday.
Thanks, Paul E. Jones Q.2/16 Rapporteur
Dear Experts,
Please give me any comments by the end of the business day Tuesday.
I found possible bugs in H.245 Generic Parameter when I was checking EVRC RTP payload format defined in H.225.0 version 4. I started checking because a complete different RTP payload format was proposed and discussed in the last IETF AVT WG meeting.
I believe that each H.245 Generic Parameter should clearly be identified as collapsing or non-collapsing because ASN.1 syntax treats differerently. But, Annex F (Logical Channel Bit Rate Management), Annex J (TDMA ACELP), K (TDMA US1), L (CDMA EVRC) and Example of H.261 do not have any description on collapsing or non-collapsing.
The bug may cause an interoperability problem between different implementations because transmitter side can encode a parameter as either collapsing or non-collapsing, and there is no explicit decoding rule for receiver side.
Has anyone there implemented TDMA or CDMA codec into H.323?
Best regards,
Hideh
Hidenobu Harasaki harasaki@bq.jp.nec.com (harasaki@ccm.cl.nec.co.jp) Senior Manager Computer & Communication Media Research NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Hidenobu Harasaki -
Paul E. Jones