Summary:	ASTERISK-05440: [patch] packetization patch for ooh323c channel driver
Reporter:	dea (dea)	Labels:
Date Opened:	2005-11-03 13:21:03.000-0600	Date Closed:	2006-09-20 16:31:02
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_ooh323-11252005.diff ( 1) chan_ooh323-packetization-295.dff ( 2) chan_ooh323-packetization-frames.diff
Description:	Port of the RTP packetization feature from bugid 5162 for the ooh323c channel driver. I do not have a way to test users, but peers and global settings have been verified. I found it a little hard to extract the implemenation details from chan_sip, but the code for the ooh323c channel driver was very easy to understand.  I think I have the packetization implemented correctly, per the patch in 5162. I do not have a disclaimer on file, but will try to get one in today.
Comments:	By: dea (dea) 2005-11-03 13:28:42.000-0600 Disclaimer faxed. By: Objective Systems (objsys) 2005-11-07 16:38:49.000-0600 DEA - Thanks for the patch. I think it is missing corresponding H.323 changes though. H.323 exchanges frames per packet(different way of saying ms of audio per packet)for each capability during call establishment. I assume the packetization config parameter you have added represents ms of audio to be sent per packet. H.323 frames per packet should change as per this config then. So, if you are sending 30 ms of audio in each rtp packet(packetization=30), this means: 1. For G711 - 30 frames per packet   (H.323 assumes frame being 8 samples in samples based codecs) 2. For G729a - 3 frames per packet 3. For g723.1 - 1 frame per packet Correct me if you think I am wrong on this, otherwise I will add support for this and then include your patch to CVS. By: dea (dea) 2005-11-07 18:08:55.000-0600 This patch depends on the patch in 005162, which sets up a tables that translates the ms duration into a frames count. IIRC it adds a lookup API to rtp.[ch] and returns the number of frames to be encoded based on the packetization duration. This patch basically extends the proof-of-concept submitted in 005162, and cannot be merged if 005162 is not merged.  All of the heavy lifting is in 005162 and I just added the API support to chan_h232. I may have missed something, but testing with a pair of Cisco 7960s, one SIP and registered to * and one SCCP registered to CCM, and Cisco gateways, I have confirmed that the resulting streams were properly 'packetized'. By: dea (dea) 2005-11-23 11:30:37.000-0600 Please delete chan_h323.txt, it has whitespace damage and cannot be applied. The version from 112305 should apply to the version included in addons version 1.2.0. By: dea (dea) 2005-11-25 17:57:47.000-0600 Uploaded a new version that makes an attempt to handle the H323 negotiation. I have some questions about tx and rx sizing.  It appears that in ooh323cDriver that 20ms is assumed, and that is what gtxframes is set to. Why is grxframes set to 240?  In the case of G729, why is rxframes set to 24? Oh, and in ooh323c_set_capability_for_call txframes for G729 is set to 6 on line 188.  That one had me going for awhile.  Only one Cisco endpoint noticed, and I thought it was a Cisco bug. Bugmarshall- please delete chan_h323.txt and chan_h323-112305.diff By: Matt O'Gorman (mogorman) 2006-01-09 12:58:24.000-0600 Hi... what is the current status regarding this issue?  Is it resolved or still a problem. Could objsys or DEA comment or close this bug By: dea (dea) 2006-01-09 15:19:55.000-0600 To my knowledge the patch has not received close review due to the uncommitted and uncertain nature of 5162.  It looks like 5162 might be moving forward, so I will continue to maintain this patch until Obj-Sys can consider it. By: Matt O'Gorman (mogorman) 2006-03-02 11:32:38.000-0600 ping objsys get a chance to look at this? By: dea (dea) 2006-03-02 12:11:03.000-0600 Bug 5162 has a burst of discussion a month ago that looked like it would be moving forward, allowing this patch to be considered. Since then it has been too quiet.  I wish I could grok the concepts discussed in that bug so I could attempt to address the issues/ideas proposed my Mark and Anthm. I've also shared the code with Obj-Sys over their development mailing list, and as-is the patch is close.  There is some clean-up needed in the H323 backend, but not much.  So 5162 needs to get some love before this one can move forward. By: Objective Systems (objsys) 2006-03-06 11:32:41.000-0600 This feature request is related to 5162 request. As it is using the function requested in 5162 changes. Once the 5162 is closed, we will be able to incorporate this suggested changes. Thank you for your patience. Avin Patel Objective Systems Inc By: Clod Patry (junky) 2006-04-11 22:47:19 objsys: any updates here? By: dea (dea) 2006-07-07 16:41:58 This patch still applies to svn version 243, with a little fuzz, but no rejects. Tested against Asterisk trunk-r37291 with no issues. By: dea (dea) 2006-08-11 16:13:12 Updated to SVN 276, and new architecture layout out in bug 5162. By: Serge Vecher (serge-v) 2006-09-19 08:58:24 Dan, since 5162 was merged in, let's get this patch updated and committed as well. Thanks. By: dea (dea) 2006-09-19 11:11:48 The previous patch applied with minor fuzz and one housekeeping reject. The -295 patch should apply cleanly. By: Objective Systems (objsys) 2006-09-19 12:11:50 Hi DEA, Thanks for update patch. I will try to apply it soon. Regards, Avin Patel By: Jason Parker (jparker) 2006-09-20 16:31:00 Committed to revision 296 in asterisk-addons. DEA, in the future, please ensure that the patch has unix formatting.  I was having issues applying it, until I did a dos2unix on it.