[asterisk-bugs] [Asterisk 0012415]: chan_h323 doesn't respect rtp packetization settings

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Dec 16 01:43:16 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12415 
====================================================================== 
Reported By:                pj
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12415
Category:                   Channels/chan_h323
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 113980 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-04-10 17:01 CDT
Last Modified:              2008-12-16 01:43 CST
====================================================================== 
Summary:                    chan_h323 doesn't respect rtp packetization settings
Description: 
chan_h323 ignores codecs payload settings eg. 'allow=g729:20'
h323 trace, when I call from h323 endpoint to asterisk:
Found peer capability G.729 <1>, Asterisk code is 256, frame size (in ms)
is 160

If I call from asterisk to another endpoing (eg. cisco gw), trace shows,
that is using 20ms g729 frame size, but still doesn't invoke p2p bridging
between sip and h323 channel

sip--->(g729/chan_sip)-asterisk-(chan_h323/g729)--->callmanager/(cisco gw
or cisco phone)
only g729 is allowed in h323 and sip config

====================================================================== 

---------------------------------------------------------------------- 
 (0096434) DEA (reporter) - 2008-12-16 01:43
 http://bugs.digium.com/view.php?id=12415#c96434 
---------------------------------------------------------------------- 
It has been awhile since I looked at this code.  I still cannot test or
use this channel, but the problem looks fairly obvious.

This is based on 1.6.0.1, yet I suspect other versions will be similar.
in ast_h323.cxx find-
case AST_FORMAT_ULAW

Change the format.cur_ms that follows to frames_per_packet
Change the two instances of format.max_ms to frames_per_packet

This might not be the final solution, but the call to
SetTxFramesInPacket() using the max allowed framing is not likely
what we want here.

In chan_ooh323 we set the capabilities to the current desired
packetization, yet here in chan_h323 we are setting it to the
codecs maximum allowed.

So while we likely need/want the call to SetTxFramesInPacket, it
probably should be called with the current frames_per_packet based
on the current packetization configured.  If that is the case, the
tests for max_frames_per_packet or format.max_ms in this function
are not needed either.

It appears that all codecs in this function suffer the same error, but
the ULAW case is easiest to test. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-16 01:43 DEA            Note Added: 0096434                          
======================================================================




More information about the asterisk-bugs mailing list