[asterisk-bugs] [Asterisk 0011901]: bridging chan_h323 and chan_sip

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=11901 
====================================================================== 
Reported By:                pj
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   11901
Category:                   Core/Channels
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 101746 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             02-01-2008 10:08 CST
Last Modified:              04-10-2008 10:52 CDT
====================================================================== 
Summary:                    bridging chan_h323 and chan_sip
Description: 
even if I using same codec (disallow=all, allow=g729) on both channels, I
never see 'Packet2Packet bridging...' message, like in sip-sip, sip-skinny,
skinny-skinny bridging.
I think, that h323 is using same RTP subsystem, so Packet2Packet bridging
should be possible to avoid RTP go through asterisk core, like in other
cases.

also some unnecessary warnings about codecs are displayed when calling
h323->sip, reverse direction sip->h323 is without warnings.
since both my ends supports g729, I have no g729 installed and expecting,
that asterisk will do simple passthrough. In general it works, but imho, it
should work better, with Packet2Packet bridging and avoid warnings below.

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

---------------------------------------------------------------------- 
 file - 04-10-08 10:52  
---------------------------------------------------------------------- 
Closed per reporter's statement that the issue is actually being caused by
packetization issues. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-10-08 10:52  file           Status                   assigned => resolved
04-10-08 10:52  file           Resolution               reopened => no change
required
04-10-08 10:52  file           Note Added: 0085306                          
======================================================================