Summary:ASTERISK-11355: bridging chan_h323 and chan_sip
Reporter:pj (pj)Labels:
Date Opened:2008-02-01 10:08:14.000-0600Date Closed:2011-06-07 14:07:56
Versions:Frequency of
Environment:Attachments:( 0) coredebug.txt
( 1) coredebug2.zip
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.


   -- SIP/xxx-gw-0822d978 is ringing
[Feb  1 15:50:08] WARNING[19297]: channel.c:2968 set_format: Unable to find a codec translation path from g729 to slin
[Feb  1 15:50:08] WARNING[19297]: indications.c:122 playtones_alloc: Unable to set 'H323/ip$' to signed linear format (write)
   -- SIP/xxx-gw-0822d978 is making progress passing it to H323/ip$
Comments:By: pj (pj) 2008-02-01 10:21:49.000-0600

core show channel H323/ip$

 NativeFormats: 0x100 (g729)
   WriteFormat: 0x100 (g729)
    ReadFormat: 0x100 (g729)
WriteTranscode: No
 ReadTranscode: No

core show channel SIP/xxx-gw-0821e2e8
 NativeFormats: 0x100 (g729)
   WriteFormat: 0x100 (g729)
    ReadFormat: 0x100 (g729)
WriteTranscode: No
 ReadTranscode: No

By: Digium Subversion (svnbot) 2008-02-20 16:26:18.000-0600

Repository: asterisk
Revision: 103955

U   trunk/channels/chan_h323.c

r103955 | file | 2008-02-20 16:26:17 -0600 (Wed, 20 Feb 2008) | 4 lines

Try to do Packet2Packet bridging with chan_h323 if reinviting isn't enabled.
(closes issue ASTERISK-11355)
Reported by: pj



By: pj (pj) 2008-02-22 14:08:58.000-0600

I think, that issue was not resolved, at least, still I don't see any 'Packet2Packet bridging...' message, when bridge between sip and h323 channels (using same codecs on both).

By: Jason Parker (jparker) 2008-03-20 13:50:07

Well, what does the log say it's doing?

By: Joshua C. Colp (jcolp) 2008-03-20 13:51:33

Yes, please provide the complete log with core debug enabled and a core show channel on each side.

By: pj (pj) 2008-03-20 14:33:56

coredebug.txt attached
call h323->sip, answer call, hungup, both channels with g729 only enabled,
other outputs, like core show channels, I posted in my first message to this bugreport.

By: Digium Subversion (svnbot) 2008-04-09 13:00:58

Repository: asterisk
Revision: 113840

U   trunk/channels/chan_h323.c

r113840 | file | 2008-04-09 13:00:56 -0500 (Wed, 09 Apr 2008) | 4 lines

Enable enough RTP bridging to allow P2P to work.
(closes issue ASTERISK-11355)
Reported by: pj



By: Digium Subversion (svnbot) 2008-04-09 13:01:53

Repository: asterisk
Revision: 113841

_U  branches/1.6.0/

r113841 | file | 2008-04-09 13:01:52 -0500 (Wed, 09 Apr 2008) | 11 lines

Blocked revisions 113840 via svnmerge

r113840 | file | 2008-04-09 15:05:40 -0300 (Wed, 09 Apr 2008) | 4 lines

Enable enough RTP bridging to allow P2P to work.
(closes issue ASTERISK-11355)
Reported by: pj




By: Digium Subversion (svnbot) 2008-04-09 13:27:37

Repository: asterisk
Revision: 113872

_U  team/group/codec_bits/
U   team/group/codec_bits/channels/chan_h323.c
U   team/group/codec_bits/channels/chan_skinny.c
U   team/group/codec_bits/contrib/scripts/astcli
U   team/group/codec_bits/main/pbx.c

r113872 | tilghman | 2008-04-09 13:27:35 -0500 (Wed, 09 Apr 2008) | 44 lines

Merged revisions 113834,113836,113838,113840 via svnmerge from

r113834 | qwell | 2008-04-09 12:41:09 -0500 (Wed, 09 Apr 2008) | 7 lines

Move all messages wrapped in skinnydebug from debug to verbose.

(closes issue ASTERISK-11651)
Reported by: DEA
     chan_skinny-debug-log.txt uploaded by DEA (license 3)

r113836 | mmichelson | 2008-04-09 12:48:33 -0500 (Wed, 09 Apr 2008) | 14 lines

There was a subtle logical difference between 1.4 and trunk with regards to how timeouts
were handled. In 1.4, if the absolute timeout were reached on a call, no matter what
the return value of ast_spawn_extension was, the pbx would attempt to go to the 'T'
extension or hangup otherwise. The rearrangement of this function in trunk made this check
only happen in the case that ast_spawn_extension returned 0. If ast_spawn_extension returned
1, then the fact that the timeout expired resulted in a no-op, and would cause an infinite
loop to occur in __ast_pbx_run. This change fixes this problem. Now timeouts will
behave as they did in 1.4

(closes issue ASTERISK-11038)
Reported by: pj
Tested by: putnopvut

r113838 | qwell | 2008-04-09 12:56:07 -0500 (Wed, 09 Apr 2008) | 2 lines

Fix a small file handle "leak" pointed out by jjshoe on #asterisk.

r113840 | file | 2008-04-09 13:05:40 -0500 (Wed, 09 Apr 2008) | 4 lines

Enable enough RTP bridging to allow P2P to work.
(closes issue ASTERISK-11355)
Reported by: pj




By: pj (pj) 2008-04-10 05:37:00

reopening this issue, because still no 'Packet2Packet' message is shown on console when bridging sip and h323 (enabled is only g729, and no transcoding is used), actually nothing changed in this, uploading coredebug2.zip

also weird is, that debug core at level 3 generates 1Mb log size (for one call processed), it's full with this messages....

[Apr 10 11:16:18] DEBUG[28098] channel.c: ::::==== Channel SIP/ipbx-gw-08229240 was locked
[Apr 10 11:16:18] DEBUG[28098] channel.c: ::::==== Unlocking AST channel SIP/ipbx-gw-08229240
[Apr 10 11:16:18] DEBUG[28098] channel.c: ::::==== Channel SIP/ipbx-gw-08229240 was unlocked
[Apr 10 11:16:18] DEBUG[28098] channel.c: ====:::: Trying to lock AST channel H323/ip$
[Apr 10 11:16:18] DEBUG[28098] channel.c: :::=== Now have 1 locks (recursive)
[Apr 10 11:16:18] DEBUG[28098] channel.c: ::::==== Channel H323/ip$ was locked
[Apr 10 11:16:18] DEBUG[28098] channel.c: ::::==== Unlocking AST channel H323/ip$

By: Joshua C. Colp (jcolp) 2008-04-10 08:55:00

I can't reproduce this with ulaw on both sides, and don't have the stuff to try g729 on both sides.

By: pj (pj) 2008-04-10 09:21:49

I will try to change to g711 and will report.

By: pj (pj) 2008-04-10 10:29:12

I probably found source of issue, it's rtp packetization settings:
when I set 'allow=g729:60' on SIP side, Packet2Packet bridging between SIP and H323 is working. When I leave simply 'allow=g729' on both SIP and H323 side p2p bridging is not working.
Setting 'allow=g729:20' on H323 side (to be same as is by default for g729 on sip side) has no affect, because h323 end device still reports, that is receiving 60ms samples.
Seems, that something is broken with rtp packetization settings on for h323 channel.

By: Joshua C. Colp (jcolp) 2008-04-10 10:33:26

I do not believe chan_h323 has support for packetization settings... that would be a separate issue. So P2P does indeed work when the conditions are right and I can close this out?

By: pj (pj) 2008-04-10 10:39:54

OK please close this ticket, I will open some new for this, because
says, that chan_h323 should support rtp packetization settings,
(at least should leave default 20ms packetization, and not change to 60ms). thanks

By: Joshua C. Colp (jcolp) 2008-04-10 10:52:12

Closed per reporter's statement that the issue is actually being caused by packetization issues.