Summary:	ASTERISK-11355: bridging chan_h323 and chan_sip
Reporter:	pj (pj)	Labels:
Date Opened:	2008-02-01 10:08:14.000-0600	Date Closed:	2011-06-07 14:07:56
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/Channels
Versions:		Frequency of Occurrence
Related Issues:
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. ****** ADDITIONAL INFORMATION ******    -- 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$192.168.40.7:51656/237' to signed linear format (write)    -- SIP/xxx-gw-0822d978 is making progress passing it to H323/ip$192.168.40.7:51656/237
Comments:	By: pj (pj) 2008-02-01 10:21:49.000-0600 core show channel H323/ip$192.168.40.7:51980/239  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 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=103955 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 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113840 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 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113841 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 https://origsvn.digium.com/svn/asterisk/trunk ........ 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 Patches:      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 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113872 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$192.168.40.7:53027/563 [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$192.168.40.7:53027/563 was locked [Apr 10 11:16:18] DEBUG[28098] channel.c: ::::==== Unlocking AST channel H323/ip$192.168.40.7:53027/563 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 doc/rtp-packetization.txt 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.