Summary:ASTERISK-05440: [patch] packetization patch for ooh323c channel driver
Reporter:dea (dea)Labels:
Date Opened:2005-11-03 13:21:03.000-0600Date Closed:2006-09-20 16:31:02
Versions:Frequency of
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

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

Thanks for update patch. I will try to apply it soon.

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.