| Summary: | ASTERISK-11826: chan_h323 doesn't respect rtp packetization settings | ||
| Reporter: | pj (pj) | Labels: | |
| Date Opened: | 2008-04-10 17:01:43 | Date Closed: | 2009-04-22 14:45:33 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_h323 |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 2009012200_h323packetization.diff.txt ( 1) cm-ast-dump.pcap ( 2) cm-ciscogw-dump.pcap ( 3) debug-ast-ciscogw.txt ( 4) debug-ast-ipcomm.txt ( 5) h323-trace.txt | |
| 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 ****** ADDITIONAL INFORMATION ****** it seems, that side effect of this is, that p2p bridging isn't working between sip and h323 channels (even if both is using g729 codec), more details reported in bugreport ASTERISK-1183901 | ||
| Comments: | By: dea (dea) 2008-04-10 18:44:13 The packetization feature in Asterisk allow it to choose what it should send. It does not effect what the client chooses to send. The client MIGHT choose to honor the requested framing, or it might just stick to what it prefers. As you have discovered, both parties need to use the same codec and same framing (packetization) to allow P2P bridging. By: pj (pj) 2008-04-11 01:30:43 Dan, it's very unlikely, that phone (connected to callmanager and then to asterisk) will request to receive 160ms frames, and send itself 20ms frames, that is current situation. When I call to asterisk (phone says receiving 160ms frames, sends 20ms). When I call from same phone to cisco gateway, packetization is symetric (20ms rx and 20ms tx). I will continue to try discover more. By: dea (dea) 2008-04-11 11:44:39 I have a CCM cluster, but I used chan_ooh323 and not chan_h323. I wondered about that '160' in your report. That appears to be samples and not ms. I am going out on a limb and assume the CCM connected phone is a 7940/7960 and you can use the call statistics feature on those phones. Are you seeing the 160ms reported on the phone during a call? By: dea (dea) 2008-04-11 12:09:01 I see a bit of code that looks a bit off to me in channels/h323/ast_h323.cxx Near line 1753 : ms = remoteCapabilities[i].GetTxFramesInPacket() * format.inc_ms; Can you add a could debugging statements? cout << "Format increment: " << format.inc_ms << endl; /* this should return 10 for G729 */ cout << "GetTxFramesInPacket reports " << remoteCapabilities[i].GetTxFramesInPacket() << " frames" << endl; For the system to actually send 160ms of audio, GetTxFramesInPacket() must be returning 16, which is just odd. You might also have some luck just setting ms = format.cur_ms in place of the line: ms = remoteCapabilities[i].GetTxFramesInPacket() * format.inc_ms; By: pj (pj) 2008-04-11 13:31:03 Dan, I added lines, that you suggest, I'm getting following output, in call between cisco phone (ip communicator) and asterisk (tried both directions, same result): Format increment: 10 GetTxFramesInPacket reports 16 frames when I call from asterisk to cisco gw Format increment: 10 GetTxFramesInPacket reports 2 frames In all cases above, I don't see that p2p bridging was activated :( By: dea (dea) 2008-04-11 13:40:32 The second result is what you should see. The 16 frames is just odd. A debug trace of the H.323 exchange would be handy to see what the negotiation looks like. Do you have bridging turned on in your h323.conf? Can you provide a console log with verbose 3 and debug 1? I am curious if you are getting core or native bridging when P2P does not engage. By: pj (pj) 2008-04-11 14:02:43 uploading two debugs, one when call asterisk to ciscogw, another when call from ip communicator (via callmanager) to asterisk. in second case (this is case, when cisco phone statistics shows receiving 160ms samples and sending 20ms samples), I can see: rtp.c: Cannot packet2packet bridge - packetization settings prevent it in first case asterisk to cisco gw (20ms samples) I don't see any messages about packet2packet bridge activating. my h323.conf is really simple: [general] port = 1720 bindaddr = 192.168.40.4 disallow=all allow=g729 fastStart=no context=from-ccm [ccm-gw] type=peer host=192.168.40.7 [ccm] type=user host=192.168.40.7 context=from-ccm By: pj (pj) 2008-04-11 14:51:58 I must correct my previous notice: I see p2p bridging now, when I call between asterisk and cisco gateway (20ms frames) -- Packet2Packet bridging SIP/bill-gw-b6e25e38 and H323/ccm-gw-6 in previous debug, I don't answered call, and only heard early messages, this was probably reason, why I previously don't saw Packet2Packet bridging. By: dea (dea) 2008-04-11 15:38:20 I am not sure how to generate it with chan_h323, but we need the ASN.1 call setup trace. During the H.323 call setup, the endpoint first exchange their maximum packetization capabilities, then they attempt to exchange the desired packetization. It appears, and I have not dug through the OpenH323 code to confirm this, that the framing is being detected and based on the maximum capability for a given codec and not the preferred framing. If you have access to the CCM, can you check to see what the preferred G729 framing is set to under 'Service Parameters'/'Call Manager Service'? What happens if you replace the line : ms = remoteCapabilities[i].GetTxFramesInPacket() * format.inc_ms; with ms = format.cur_ms; By: pj (pj) 2008-04-11 16:02:05 if I replace line with ms = format.cur_ms; I got p2p bridging, but phone statistics still shows 160ms received and 20ms send, and sound clicking/pops periodically in interval about 3-5s (after every this click rx/tx packet counter on phone statistic resets (it counts up to about 200 packets, then restarts from null). I will post packet capture between asterisk and callmanager. Format increment: 10 GetTxFramesInPacket reports 16 frames -- Packet2Packet bridging H323/ip$192.168.40.7:53700/687 and SIP/ipbx-gw-08209b60 == Spawn extension (from-ccm, 968, 1) exited non-zero on 'H323/ip$192.168.40.7:53700/687' By: dea (dea) 2008-04-11 16:04:59 It was worth a shot. This will require someone who is more familiar with the code in chan_h323 and H323 libraries. AT least we narrowed the search down just a bit. By: pj (pj) 2008-04-11 16:30:38 uploading cm-ast-dump.pcap packet dump between callmanager, asterisk and phone. (cm: 192.168.40.7, ast: .40.4, phone .102.2) if I look at this correctly, phone/callmanager offers in capability set codecs: g729 (16), asterisk offer is: g729 (2) from your previous question, I have cm parameters in default, i.e. 20ms packet size for g729. I would also notice, that other phones like wifi 7921 received 60ms payload from asterisk (and sends 20ms), probably same 60ms payload is also on 7940/60. By: dea (dea) 2008-04-11 16:45:17 Can you try chan_sip? I suspect the issue is that chan_h323 is using the max capability (16 frames in this case) and not the desired. I cannot read your capture, so what we are looking for is in the openlogicalchannel section of the exchange. You should have seen the 16/2 capabilities early in the setup and then repeated in during the open logical channel phase. If the 16 is still in the open logical channel phase of the exchange, then the problem is not in chan_h323, but with your CCM. By: pj (pj) 2008-04-12 15:38:43 Dan, you can open supplied packet dump with free packet analyzer wireshark. Anyway, I investigated packed dump again... seems, that you are right, that asterisk probably using (in channel from ast to phone) max capability (16 frames), that is offered at beginning of call setup from phone/cm to asterisk (g729:16) in capability exchange message. asterisk then using this value in open logical channel message back from asterisk to phone/cm. I don't think, this is bug in callmanager, because when I call from same phone to cisco gw (via exactly configured h323 trunk), rx/tx directions are established using 20ms frames, regardless, that initial offer is exactly same, as I wrote above, ie. from phone/cm to gateway is offered g729:16 (but OLC send back from gw to phone is setup with 20ms frames). I can't try sip trunk between callmanager and asterisk, because cm4.x support only g711 on sip trunks:( By: pj (pj) 2008-04-12 15:48:48 uploading cm-ciscogw-dump.pcap, packet dump when call phone/cm (192.168.40.7) to cisco gw (.40.5) By: dea (dea) 2008-04-13 01:58:43 PJ, I forget that not everyone was as quick to CCM 6.X as I was. I was thinking a test even with G.711 would be worthwhile. I am sure the problem is not with CCM. The issue is 99.9% likely that chan_h323 is setting up the packetization too early in the call setup. It should not be pulling the max framing value, but should compare the local configuration against the remotes endpoints advertised max. The correct time to setup the packetization is in the openlogicalchannel phase. I am familiar with the concepts from adding packetization support to chan_ooh323, but I do not know my way around the chan_h323 code. By: dea (dea) 2008-04-13 02:19:50 Actually the problem may well be in function MyH323Connection::SetCapabilities inside channels/h323/ast_h323.cxx around line 1867 There are a couple problems in here. But they all basically boil down to the code choosing to use the maximum allowable packetization for every codec except ulaw/alaw. A quick test would be to change the two calls under the G729 case to use frames_per_packet instead of max_frames_per_packet By: pj (pj) 2008-04-13 04:30:36 tests with ip communicator: cm-asterisk with sip trunk (g711): call is established with 20ms/20ms cm-asterisk with h323 trunk (g711): call is established with 150ms/20ms samples cm-asterisk with h323 trunk (g729): call is established with 160ms/20ms samples when I try call asterisk from cm and phone type 7960/7921 it receives 60ms frames from asterisk (phone sending always 20ms). By: dea (dea) 2008-04-13 14:22:34 OK, the SIP test proves the issue is in chan_h323. I hate to keep throwing out tests, but I have no way to test the code myself. So your patience is greatly appreciated. In addition to the change from max_frames_per_packet to frames_per_packet can you comment out the call to ast_codec_pref_setsize(). There is only one instance of this function in ast_h323.cxx. This call overrides the configured value and sets it to the max capability sent by the remote peer. The preferences By: pj (pj) 2008-04-13 14:44:31 I commented out line 1757 ast_codec_pref_setsize(&prefs, ast_codec, ms); now, I see p2p bridging on asterisk console, but phone statistic still shows g729 receiving 160ms, sending 20ms frames. It also clicks periodically and received/send packets counters on phone are reset after reaching every about 200 packets. By: dea (dea) 2008-04-13 14:46:51 Can you post a short section of the output from rtp debug during a call? Five to ten lines will be enough. By: pj (pj) 2008-04-13 14:52:39 cisco phone has ip 192.168.102.17 -- SIP/ipbx-gw-08230128 answered H323/ip$192.168.40.7:52944/11 Format increment: 10 GetTxFramesInPacket reports 16 frames Got RTP packet from 192.168.102.17:24576 (type 18, seq 000041, ts 3670665752, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000042, ts 3670665912, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000043, ts 3670666072, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000044, ts 3670666232, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000045, ts 3670666392, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000046, ts 3670666552, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000047, ts 3670666712, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000048, ts 3670666872, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000049, ts 3670667032, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000050, ts 3670667192, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000051, ts 3670667352, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000052, ts 3670667512, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000053, ts 3670667672, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000054, ts 3670667832, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000055, ts 3670667992, len 000020) Got RTP packet from 192.168.102.17:24576 (type 18, seq 000056, ts 3670668152, len 000020) -- Packet2Packet bridging H323/ip$192.168.40.7:52944/11 and SIP/ipbx-gw-08230128 Sent RTP P2P packet to 193.179.38.20:17094 (type 18, len 000020) Sent RTP P2P packet to 193.179.38.20:17094 (type 18, len 000020) Sent RTP P2P packet to 192.168.102.17:24576 (type 18, len 000020) Sent RTP P2P packet to 193.179.38.20:17094 (type 18, len 000020) Sent RTP P2P packet to 193.179.38.20:17094 (type 18, len 000020) By: dea (dea) 2008-04-13 15:03:02 That output shows that it is sending 20ms framing to the phone. So now the question become is the RPT core wrong about what it is sending, or is chan_h323 still mis-representing what it is trying to send. I see in the chan_h323 code that it supports both debug and H323 stack tracing. Can you post the CLI after setting: h323 set trace 5 h323 set debug By: pj (pj) 2008-04-13 15:28:33 uploading h323-trace, interesting part is here, that shows still about g729:16 request openLogicalChannel { forwardLogicalChannelNumber = 101 forwardLogicalChannelParameters = { dataType = audioData g729 16 By: Private Name (falves11) 2008-04-13 23:45:40 I am affected by this bug as well. The bridging at the packet level between H323 and SIP is "business critical". By: pj (pj) 2008-08-17 13:57:11 can we continue to look at this issue? It still persist in current Asterisk SVN-trunk-r138482 I think we are close to find source of this issue and because chan_h323 is only one h323 channel supported by asterisk (chan_ooh323 is unsupported now), we should to try to remove this ugly bug. I'm ready to help with testing/debugging/packet capturing :o) By: Private Name (falves11) 2008-08-17 14:00:25 I also want to vote for this issue. SIP and H323 Interop is business critical. By: Leif Madsen (lmadsen) 2008-12-11 15:34:21.000-0600 Changing this status to acknowledged as it looks like pj and DEA have done some extensive testing and debugging on this issue to acknowledge it. Unfortunately I have no one I can assign this issue to right now, but it is acknowledged and will be dealth with once someone familiar with chan_h323 code can step up. Thanks! By: dea (dea) 2008-12-16 01:43:15.000-0600 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. By: tursiops (tursiops) 2009-01-21 17:33:49.000-0600 We had the same H323 packetization issue here when we attempted to switch from Asterisk 1.2 to 1.4.22. Our provider requires us to use 20ms. Using DEAs suggestion, I changed ast_h323.cxx and commented out the max_frames_per_packet test alltogether and just added g729aCap->SetTxFramesInPacket(frames_per_packet); g729Cap->SetTxFramesInPacket(frames_per_packet); to the code. Made a test call (allow=g729:20 in my h323.conf) and it worked right away. Tried again with allow=g729 (without :20) and that worked as well. Just to make sure I also tested allow=g729:30, which did not work (as expected). Note that we are using G729 only, so I did not make any changes/tests in regards to the other codecs. By: Michiel van Baak (mvanbaak) 2009-01-22 16:12:11.000-0600 Can you try this patch ? If it breaks compiling hit me. At the moment I dont have h323 on my devlaptop so will test it tomorrow. But with the tips from DEA and Tursiops I created this patch By: tursiops (tursiops) 2009-01-22 18:28:49.000-0600 I've tried patching using the wget command, but it failed. Apparently a version difference, as there is no "AST_FORMAT_G726_AAL2" in mine at all (which came with Asterisk 1.4.22) So I had to remove the non-matching lines from the G726 line downward and update the Hunk #2 header line or whatever it is called (sorry, not a coder/patcher) from '@@ -1934,43 +1933,35 @@' to '@@ -1934,35 +1933,28 @@'. After that the patch worked for me as well. Compiling gave me a warning though: ast_h323.cxx: In member function âvoid MyH323Connection::SetCapabilities(int, int, void*, int)â: ast_h323.cxx:1852: warning: unused variable âmax_frames_per_packetâ So I removed the offending "int max_frames_per_packet;" line causing it and the warning disappeared. Testcalls worked fine. But as mentioned before, we're using G729 only (requirement by our provider), so I can't test the other codecs. Thanks for the patch! By: Michiel van Baak (mvanbaak) 2009-01-23 01:24:57.000-0600 Yeah sorry, I created the patch against trunk. Thanks for the feedback. Can anyone using G711 test this as well ? By: pj (pj) 2009-01-23 14:02:14.000-0600 Hi, I'm original reporter of this issue, but because of lack development in chan_h323, I abadoned h323 from my asterisk. Sorry, I can't give any further feedback about chan_h323, because currently I haven't any suitable device to test h323. Thank you for understanding. By: Michiel van Baak (mvanbaak) 2009-01-23 14:31:05.000-0600 pj: no problem. I can understand that. Let's hope my patch helps someone that actually understands h323 :) By: Private Name (falves11) 2009-01-23 14:49:00.000-0600 I will test it. I am using h323 a lot. F.Alves By: Tusar Ahmed (tusar) 2009-03-17 03:22:24 SIP(UA)-->(SIP)Asterisk(H323)-->H323GW h323.conf ========= disallow=all allow=g729:40 With patch "2009012200_h323packetization.diff.txt" , it is working as expected :-) . //Tusar\\ By: Leif Madsen (lmadsen) 2009-03-18 08:48:19 Marking this issue as ready for review since we have a report of a patch working for a reporter. Thanks! By: Leif Madsen (lmadsen) 2009-03-18 08:49:08 Assigning this to jpeeler for initial review, then perhaps he can put it up on reviewboard for peer review. Thanks! By: Leif Madsen (lmadsen) 2009-03-30 22:10:42 falves11: you indicated you could test this patch; any update? By: Private Name (falves11) 2009-03-30 22:59:42 I applied it and H323 works, but my carriers do not accept any variation on the codec bytes. If somebody else wants to help, I can send a call via h323 and he/she can answer. By: Digium Subversion (svnbot) 2009-04-22 14:20:54 Repository: asterisk Revision: 189991 U branches/1.4/channels/chan_h323.c U branches/1.4/channels/h323/ast_h323.cxx U branches/1.4/channels/h323/chan_h323.h ------------------------------------------------------------------------ r189991 | jpeeler | 2009-04-22 14:20:53 -0500 (Wed, 22 Apr 2009) | 15 lines Make chan_h323 respect packetization settings Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. (closes issue ASTERISK-11826) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189991 By: Digium Subversion (svnbot) 2009-04-22 14:22:12 Repository: asterisk Revision: 189992 _U trunk/ ------------------------------------------------------------------------ r189992 | jpeeler | 2009-04-22 14:22:11 -0500 (Wed, 22 Apr 2009) | 21 lines Blocked revisions 189991 via svnmerge ........ r189991 | jpeeler | 2009-04-22 14:20:53 -0500 (Wed, 22 Apr 2009) | 15 lines Make chan_h323 respect packetization settings Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. (closes issue ASTERISK-11826) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189992 By: Digium Subversion (svnbot) 2009-04-22 14:23:50 Repository: asterisk Revision: 189993 U trunk/channels/chan_h323.c U trunk/channels/h323/ast_h323.cxx U trunk/channels/h323/chan_h323.h ------------------------------------------------------------------------ r189993 | jpeeler | 2009-04-22 14:23:49 -0500 (Wed, 22 Apr 2009) | 18 lines Make chan_h323 respect packetization settings and fix small reload issue. Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. Also, an unrelated config reload issue has been fixed in the case of the config file not changing. (closes issue ASTERISK-11826) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189993 By: Digium Subversion (svnbot) 2009-04-22 14:33:08 Repository: asterisk Revision: 189995 _U branches/1.6.0/ U branches/1.6.0/channels/chan_h323.c U branches/1.6.0/channels/h323/ast_h323.cxx U branches/1.6.0/channels/h323/chan_h323.h ------------------------------------------------------------------------ r189995 | jpeeler | 2009-04-22 14:33:07 -0500 (Wed, 22 Apr 2009) | 22 lines Merged revisions 189993 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r189993 | jpeeler | 2009-04-22 14:23:49 -0500 (Wed, 22 Apr 2009) | 18 lines Make chan_h323 respect packetization settings Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. (closes issue ASTERISK-11826) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189995 By: Digium Subversion (svnbot) 2009-04-22 14:41:11 Repository: asterisk Revision: 189996 _U branches/1.6.1/ U branches/1.6.1/channels/chan_h323.c U branches/1.6.1/channels/h323/ast_h323.cxx U branches/1.6.1/channels/h323/chan_h323.h ------------------------------------------------------------------------ r189996 | jpeeler | 2009-04-22 14:41:11 -0500 (Wed, 22 Apr 2009) | 22 lines Merged revisions 189993 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r189993 | jpeeler | 2009-04-22 14:23:49 -0500 (Wed, 22 Apr 2009) | 18 lines Make chan_h323 respect packetization settings Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. (closes issue ASTERISK-11826) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189996 By: Digium Subversion (svnbot) 2009-04-22 14:45:30 Repository: asterisk Revision: 189997 _U branches/1.6.2/ U branches/1.6.2/channels/chan_h323.c U branches/1.6.2/channels/h323/ast_h323.cxx U branches/1.6.2/channels/h323/chan_h323.h ------------------------------------------------------------------------ r189997 | jpeeler | 2009-04-22 14:45:30 -0500 (Wed, 22 Apr 2009) | 25 lines Merged revisions 189993 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r189993 | jpeeler | 2009-04-22 14:23:49 -0500 (Wed, 22 Apr 2009) | 18 lines Make chan_h323 respect packetization settings and fix small reload issue. Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. Also, an unrelated config reload issue has been fixed in the case of the config file not changing. (closes issue ASTERISK-11826) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189997 | ||