| Summary: | ASTERISK-12357: Memory segmentation fault on T.38 pass through | ||
| Reporter: | Bastian Schern (schern) | Labels: | |
| Date Opened: | 2008-07-10 08:17:53 | Date Closed: | 2009-03-10 14:25:51 |
| Priority: | Blocker | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/T.38 |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 20090210__bug13050__DEBUG.diff.txt ( 1) 20090210__bug13050__Makefile.diff.txt ( 2) 20090211__bug13050__2.diff.txt ( 3) 20090211__bug13050.diff.txt ( 4) 20090212__bug13050.diff.txt ( 5) asterisk-1.4-r174282M_valgrind_04.txt ( 6) asterisk-1.6.0.4-rc1_malloc-debug_01.txt ( 7) asterisk-1.6.0.4-rc1_valgrind_01.txt ( 8) full.log ( 9) gdb.t38_crash_DONT_OPTIMIZE.txt (10) gdb.t38-crash.DONT_OPTIMIZE.2.log (11) gdb.txt (12) t38_failure.pcap | |
| Description: | I tried to use the chan_sip with T.38 pass through. An Fax is coming via T.38 from the Carrier an should go to a Linksys SPA2102 (T.38 enabled). Short after starting UDPL traffic I got a segmentation fault. The crash is 100% reproducible. Outbound T.38 is no problem at all. ****** STEPS TO REPRODUCE ****** 1. Send a fax via SIP carrier with T.38 to Asterisk and pass through T.38 to ATA connected via SIP. Fax -> PSTN -> SIP Carrier -> Asterisk -> ATA ****** ADDITIONAL INFORMATION ****** Asterisk 1.4.21.1 | ||
| Comments: | By: Leif Madsen (lmadsen) 2008-07-10 08:38:38 schern: Please provide a backtrace after enabling DONT_OPTIMIZE in the compiler flags menu of menuselect, then perform a 'make install', restart Asterisk, and reproduce the issue. Once you have a non-optimized backtrace, please post it here. Thanks! By: Bastian Schern (schern) 2008-07-10 13:35:51 Recompiled with DONT_OPTIMIZE. Backtrace and core file attached: gdb.t38_crash_DONT_OPTIMIZE.txt core.t38_crash_DONT_OPTIMIZE.bz2 By: Leif Madsen (lmadsen) 2008-07-10 13:51:20 Hi schern, The backtrace you posted still appears to have the values optimized out, which means the code didn't get compiled with the DONT_OPTIMIZE flag. You may need to run a 'make distclean' in order to clean out the modules and such, then you can perform your configuration and installation again. Give this a shot: cd /usr/src/asterisk-src make distclean ./configure make menuselect -- configure as appropriate and enable DONT_OPTIMIZE -- make install asterisk -rx "restart now" Then try reproducing the crash and exporting the backtrace. Be sure you're not seeing any <value optimized out>'s in your backtrace, as that means the backtrace won't be usable in tracking down the crash issue. Also, I've removed the core file as that is only usable on the system it was created on. Thanks! By: Bastian Schern (schern) 2008-07-10 18:39:49 Clean rebuild with the following Compiler Flags: DEBUG_THREADS DONT_OPTIMIZE See: gdb.t38-crash.DONT_OPTIMIZE.2.log No more <value optimized out> are inside the backtrace log. Regrads Bastian By: haggard (haggard) 2008-09-02 10:16:51 Hi, I can also reproduce this behavior with the same carrier-hardware (Ascotel CVX) and asterisk in all versions from 1.4.18. to 1.4.21 on both i386 and x86_64 platforms. The last line from udpl debug before segfault shows a receiving packet from the CVX with immense length. Got UDPTL packet from 10.10.0.18:21290 (type 0, seq 0, len 21) Got UDPTL packet from 10.10.0.18:21290 (type 0, seq 0, len 6) Sent UDPTL packet to 192.168.1.20:7078 (type 0, seq 35, len 23) Got UDPTL packet from 10.10.0.18:21290 (type 0, seq 0, len 6) Got UDPTL packet from 10.10.0.18:21290 (type 0, seq 0, len 450) That's exactly the point where * crashes each time. GDB output while loading corefiles: #0 0x080f94a8 in init_manager () at manager.c:3162 3162 fcntl(asock, F_SETFL, flags | O_NONBLOCK); I hope to find time to send over all collected informations the next days. Hope that was a little helpful Regards Haggard By: Tilghman Lesher (tilghman) 2008-11-07 15:44:20.000-0600 It appears that your stack is corrupt. Please read doc/valgrind.txt and follow those instructions, please. Note that it may not crash while running valgrind, but the information generated is still helpful to us. By: rayjay (rayjay) 2008-11-07 15:44:44.000-0600 We have also been hit by this one a few times since starting to route fax t.38 traffic through our Asterisk platforms. I'm not sure 'normal' priority is the right thing for this bug as a seg fault resulting in us dropping dozens of in-progress calls is pretty serious for us! We have had dozens of crashes now but here are 3 examples below if these are helpful? I will try and get more debug: CRASH 1 ------- Program terminated with signal 11, Segmentation fault. #0 0x080fce57 in ast_udptl_write (s=0x0, f=0x0) at udptl.c:514 514 switch (s->error_correction_scheme) (gdb) bt full #0 0x080fce57 in ast_udptl_write (s=0x0, f=0x0) at udptl.c:514 seq = <value optimized out> res = <value optimized out> buf = "\000\b\207\235\036\aý\206ê\005\005é\201å\a\031\221\206×\001\020\236\207z\006i\205\205j\001|\207\236\022\006Û\207\220\030\aæ\206ï\004\032\224\206ð\a\022\233\230\034\004ê\206r\006M\206í\004\020\205\230\034\004\224\206{\006@\206â\006\021\205\231\037\004\227\207f\006]\206à\a\021\204\236\037\004\226\206`\006Ö\206æ\a\027\204\232\024\006|\207\236\035", '\0' <repeats 289 times> __PRETTY_FUNCTION__ = "ast_udptl_write" #1 0x00000000 in ?? () No symbol table info available. CRASH 2 ------- Program terminated with signal 11, Segmentation fault. #0 0x080fc5c5 in ast_udptl_read (udptl=0x0) at udptl.c:330 330 if (seq_no - i >= s->rx_seq_no) { (gdb) bt full #0 0x080fc5c5 in ast_udptl_read (udptl=0x0) at udptl.c:330 res = 1555 sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"} len = 0 __PRETTY_FUNCTION__ = "ast_udptl_read" #1 0x00000000 in ?? () No symbol table info available. CRASH 3 ------- Program terminated with signal 11, Segmentation fault. #0 0x080fc5c5 in ast_udptl_read (udptl=0x0) at udptl.c:330 330 if (seq_no - i >= s->rx_seq_no) { (gdb) bt full #0 0x080fc5c5 in ast_udptl_read (udptl=0x0) at udptl.c:330 res = 2065 sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"} len = 0 __PRETTY_FUNCTION__ = "ast_udptl_read" #1 0x00000000 in ?? () No symbol table info available. By: Tilghman Lesher (tilghman) 2008-11-07 16:23:56.000-0600 No, valgrind output is going to be far more useful to us. By: Bastian Schern (schern) 2009-01-22 01:45:23.000-0600 The problem is also related to Asterisk 1.6.0.3. Currently it is possible to kill every Asterisk by sending inbound T.38 traffic. Has someone an idea how to fix this? By: Bastian Schern (schern) 2009-01-22 06:21:31.000-0600 The problem is also related to Asterisk 1.4.23. By: Leif Madsen (lmadsen) 2009-01-22 14:48:30.000-0600 schern: if you can reproduce, could you get us the valgrind output so that we could move this issue forward? See the doc/valgrind.txt file in your asterisk source for how to get that. Once you can reproduce it, then upload the file to this bug. Note that asterisk may not crash while running in valgrind, so just do as you would normally do to reproduce the bug, then stop the valgrind process and upload the output, as it may still be useful even if it prevents a crash. Thanks! By: Bastian Schern (schern) 2009-01-23 09:43:25.000-0600 I added the valgrind output: asterisk-1.6.0.4-rc1_valgrind_01.txt By: Tilghman Lesher (tilghman) 2009-02-09 14:24:02.000-0600 I believe this is already fixed. Please upgrade to an SVN 1.4 checkout which exceeds revision number 168603 and try again. By: Bastian Schern (schern) 2009-02-09 14:52:51.000-0600 I upgraded to SVN the version. But Asterisk is still crashing. *CLI> core show version Asterisk SVN-branch-1.4-r174282M built by root @ dev-gw1 on a x86_64 running Linux on 2009-02-09 20:42:51 UTC By: Bastian Schern (schern) 2009-02-09 15:04:35.000-0600 See 'asterisk-1.4-r174282M_valgrind_04.txt' for crash details. By: Tilghman Lesher (tilghman) 2009-02-10 13:27:56.000-0600 Okay, you can stop posting valgrind output for the time being. Please patch your system with the uploaded patch, and reproduce the crash, if possible. If it doesn't crash, please upload the 5 minutes from the logs when you attempted to get it to crash and it didn't. If it does crash, please run gdb and get the output of the command "p last_function". Due to the stack corruption, all other gdb and valgrind output are useless, at this point. By: Tilghman Lesher (tilghman) 2009-02-10 16:15:24.000-0600 I've uploaded an additional patch for the Makefile, which may help us figure out where the function that is overflowing the stack is located. Please apply both patches. By: Bastian Schern (schern) 2009-02-11 07:03:16.000-0600 gdb output after crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1075951968 (LWP 19740)] 0x0000000000000000 in ?? () (gdb) p last_function $1 = "udptl_debug_test_addr\000daddr", '\0' <repeats 52 times> (gdb) The Makefile-Patch is not working. After applying I'm unable to compile Asterisk: make[1]: Entering directory `/usr/src/Asterisk/1.4/asterisk-1.4-svn/main' [CC] udptl.c -> udptl.o [LD] abstract_jb.o acl.o aescrypt.o aeskey.o aestab.o alaw.o app.o ast_expr2.o ast_expr2f.o asterisk.o astmm.o astobj2.o audiohook.o autoservice.o callerid.o cdr.o channel.o chanvars.o cli.o config.o cryptostub.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o enum.o file.o fixedjitterbuf.o frame.o fskmodem.o global_datastores.o http.o image.o indications.o io.o jitterbuf.o loader.o logger.o manager.o md5.o netsock.o pbx.o plc.o privacy.o rtp.o say.o sched.o sha1.o slinfactory.o srv.o stdtime/localtime.o strcompat.o tdd.o term.o threadstorage.o translate.o udptl.o ulaw.o utils.o editline/libedit.a db1-ast/libdb1.a -> asterisk udptl.o: In function `__register_file_version': /usr/src/Asterisk/1.4/asterisk-1.4-svn/main/udptl.c:20: undefined reference to `__stack_chk_guard' /usr/src/Asterisk/1.4/asterisk-1.4-svn/main/udptl.c:20: undefined reference to `__stack_chk_guard' /usr/src/Asterisk/1.4/asterisk-1.4-svn/main/udptl.c:20: undefined reference to `__stack_chk_fail' udptl.o: In function `__unregister_file_version': /usr/src/Asterisk/1.4/asterisk-1.4-svn/main/udptl.c:20: undefined reference to `__stack_chk_guard' /usr/src/Asterisk/1.4/asterisk-1.4-svn/main/udptl.c:20: undefined reference to `__stack_chk_guard' /usr/src/Asterisk/1.4/asterisk-1.4-svn/main/udptl.c:20: undefined reference to `__stack_chk_fail' udptl.o: In function `init_empty_mutex': /usr/src/Asterisk/1.4/asterisk-1.4-svn/include/asterisk/lock.h:215: undefined reference to `__stack_chk_guard' /usr/src/Asterisk/1.4/asterisk-1.4-svn/include/asterisk/lock.h:217: undefined reference to `__stack_chk_guard' /usr/src/Asterisk/1.4/asterisk-1.4-svn/include/asterisk/lock.h:217: undefined reference to `__stack_chk_fail' udptl.o: In function `ast_free': [...] collect2: ld returned 1 exit status make[1]: *** [asterisk] Fehler 1 make[1]: Leaving directory `/usr/src/Asterisk/1.4/asterisk-1.4-svn/main' make: *** [main] Fehler 2 By: GERD GERD (gerd1000) 2009-02-11 09:04:49.000-0600 @schern "udptl debug" so we can see the len If it as large as we see in the debug from haggard then the bufferlen shall be enlarged. By: GERD GERD (gerd1000) 2009-02-11 09:09:32.000-0600 i.e. #define LOCAL_FAX_MAX_DATAGRAM 1000 and additionally there have to be some checks against accessing memory beyond. By: Tilghman Lesher (tilghman) 2009-02-11 10:08:13.000-0600 This patch should more or less fix the issue. By: Atis Lezdins (atis) 2009-02-11 10:19:33.000-0600 Tilghman, i see you patched encode_open_type, but i've seen some fixes also on decode_open_type (i assume passtrough uses both). What i have in my hands is GPLed so i can't submit, but perhaps it's worth taking a look at that function too? By: Atis Lezdins (atis) 2009-02-11 11:10:58.000-0600 schern, you could try patches i'm using for Asterisk 1.4.19 (some of them could be already commited in 1.4.21). There are included GPLed patches from Callweaver, which i can't legally submit to Digium, but perhaps they fix your issues. [[[unlicensed patch deleted]]] By: Tilghman Lesher (tilghman) 2009-02-11 11:13:52.000-0600 atis: please don't have him testing patches that we can't put back in Asterisk. We're trying to fix this for everybody. By: Atis Lezdins (atis) 2009-02-11 11:29:10.000-0600 Sorry, this trial-and-error issue just seemed to be quite hard to debug. I was just giving pointers - where to look :) If something like that would help, you would just have to figure way how to fix affected function without breaking that license. By: Bastian Schern (schern) 2009-02-11 11:39:13.000-0600 Before changing LOCAL_FAX_MAX_DATAGRAM to 1000 Asterisk crashes independently from settings in udptl.conf (T38FaxMaxDatagram): --- snip --- [...] Got UDPTL packet from 62.180.55.10:20710 (type 0, seq 0, len 21) Got UDPTL packet from 62.180.55.10:20710 (type 0, seq 0, len 6) Sent UDPTL packet to 212.87.38.44:59184 (type 0, seq 34, len 16) Got UDPTL packet from 62.180.55.10:20710 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:20710 (type 0, seq 0, len 251) Sent UDPTL packet to 212.87.38.44:59184 (type 0, seq 35, len 259) Got UDPTL packet from 62.180.55.10:20710 (type 0, seq 0, len 251) Sent UDPTL packet to 212.87.38.44:59184 (type 0, seq 0, len 502) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1075951968 (LWP 20201)] 0x0000000000000000 in ?? () (gdb) p last_function $1 = "udptl_debug_test_addr\000daddr", '\0' <repeats 52 times> (gdb) --- snap --- After changing LOCAL_FAX_MAX_DATAGRAM to 1000 Asterisk is not crashing any longer but the fax calls are always incomplete: --- snip --- [...] Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 78, len 16) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 79, len 199) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 80, len 382) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 81, len 567) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 82, len 752) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 83, len 752) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 84, len 752) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 85, len 752) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 111) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 86, len 672) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 87, len 487) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 88, len 302) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 89, len 302) Got UDPTL packet from 62.180.55.10:21982 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63690 (type 0, seq 90, len 382) == Spawn extension (incoming, 030346499198, 3) exited non-zero on 'SIP/in-px1-008f8480' [Thread 1075951968 (zombie) exited] --- snap --- By: Bastian Schern (schern) 2009-02-11 11:51:31.000-0600 After applying the patch 20090211__bug13050.diff.txt from Corydon76 Asterisk is also not crashing anymore but inbound fax calls are still incomplete: --- snip --- UDPTL Debugging Enabled *CLI> [New Thread 1075951968 (LWP 25777)] [...] -- Called 00043551198 -- SIP/00043551198-0076dc60 is ringing -- SIP/00043551198-0076dc60 answered SIP/in-px1-00758270 Got UDPTL packet from 212.87.38.44:63874 (type 0, seq 0, len 8) Sent UDPTL packet to 62.180.55.10:21258 (type 0, seq 1, len 8) [...] Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 6) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 34, len 16) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 6) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 35, len 259) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 36, len 502) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 37, len 747) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) [Feb 11 18:44:07] ERROR[25777]: udptl.c:257 encode_open_type: Buffer overflow detected (245 + 747 > 800) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) [Feb 11 18:44:07] ERROR[25777]: udptl.c:257 encode_open_type: Buffer overflow detected (245 + 747 > 800) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) [Feb 11 18:44:07] ERROR[25777]: udptl.c:257 encode_open_type: Buffer overflow detected (245 + 747 > 800) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 251) [Feb 11 18:44:08] ERROR[25777]: udptl.c:257 encode_open_type: Buffer overflow detected (245 + 747 > 800) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 153) [Feb 11 18:44:08] ERROR[25777]: udptl.c:257 encode_open_type: Buffer overflow detected (245 + 649 > 800) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 6) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 38, len 747) [...] Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 129, len 752) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 130, len 752) Got UDPTL packet from 62.180.55.10:21258 (type 0, seq 0, len 191) Sent UDPTL packet to 212.87.38.44:63874 (type 0, seq 131, len 752) == Spawn extension (incoming, 030346499198, 3) exited non-zero on 'SIP/in-px1-00758270' [Thread 1075951968 (zombie) exited] --- snap --- I don't understand why there are buffer overflows because T38FaxMaxDatagram is set to 1000 in udptl.conf. By: GERD GERD (gerd1000) 2009-02-11 11:56:51.000-0600 @schern: try other firmware, 5.2.3, 5.1.12 or 5.1.10. I did not check since 6 months if there is newer firmware available and haven't checked if this model is still available or replaced by some other model from cisco. Changing the value of LOCAL_FAX_MAX_DATAGRAM was a quick hack which worked for me. It seems that there are several enhancements now available (unlicensed patch and the one from 2009-02-11 10:07). "T38FaxMaxDatagram is set to 1000 in udptl.conf" Maybe it is not used in the way we are thinking of... Next, I've seen esp. one device which sends larger packets than advertised from asterisk, i.e. asterisk says maximum length is 400 and device sends 508 or so. We are using asterisk 1.6 beta 9 germany based carrier ? (245 + 747 > 800): 2x400=800 ;-) Try LOCAL_FAX_MAX_DATAGRAM 1000. Try other ATA. Do you see which equipment your carrier uses (sip debug) ? By: Bastian Schern (schern) 2009-02-11 11:58:54.000-0600 If it helps I can forward the SIP/UDPTL-Traffic directly to a machine at your side. I can also provide a PSTN number for testing. By: Tilghman Lesher (tilghman) 2009-02-11 12:17:30.000-0600 The parameter T38FaxMaxDatagram has a maximum of the static buffer size in the code. Perhaps it would help if we made that buffer dynamic. By: Tilghman Lesher (tilghman) 2009-02-11 12:34:47.000-0600 Well, looks like making the buffer dynamic isn't possible. However, I don't think increasing it to 1400 would be a problem at all, as long as we don't exceed the MTU. By: Bastian Schern (schern) 2009-02-11 15:39:53.000-0600 No success with Linksys SPA2100, SPA2102 5.2.3, SPA2102 5.2.5. But it works with a Grandstream HT-502 1.0.1.21 also if LOCAL_FAX_MAX_DATAGRAM is set to 400. By: Bastian Schern (schern) 2009-02-11 17:48:46.000-0600 @gerd1000: Yes it is a German based carrier and in the SIP header I can see that he is using AASTRA equipment: CVX_SS7_Gateway/CSG.6.0.b192o.E By: GERD GERD (gerd1000) 2009-02-12 07:00:33.000-0600 I tested with CVX_SS7_Gateway/CSG.6.0.b192o.E, too, and confirm that in this case I never got this SPA working (in May, 2008) although this carrier claimed having a working T.38 implementation. The carrier I tested with is now migrating from AASTRA to other NGN and if completed I probably test again. Interesting that HT-502 is working. By: GERD GERD (gerd1000) 2009-02-12 07:16:30.000-0600 I tested with AASTRA CVX_SS7_Gateway/CSG.6.0.b192o.E, too, and never got it working. The carrier I tested with is/has migrated to a new NGN platform and I will retest this SPA when Asterisk 1.6.1 is released. I think that there is some incompatibility with some media gateway. I tested with other ATA which did not work, too. Interesting that Grandstream is working. SPA is working with other carriers like DT.. which uses Vocaltec. Your carrier is B. ? By: Bastian Schern (schern) 2009-02-12 08:09:05.000-0600 @gerd1000: Yes our carrier is B. ;-) And I'm also very interested to see if the compatibility will be improved after migration to the NGN platform which is IMHO made by Siemens and unofficially called NGN EWSD. By: Tilghman Lesher (tilghman) 2009-02-12 10:08:12.000-0600 schern: have you tried with the latest patch? This has the largest buffer possible. By: Bastian Schern (schern) 2009-02-12 11:49:05.000-0600 The patch is not working: make[1]: Entering directory `/usr/src/Asterisk/1.4/asterisk-1.4-svn/main' [CC] udptl.c -> udptl.o udptl.c: In function ‘ast_udptl_reload’: udptl.c:1272: warning: no previous prototype for ‘ast_udptl_init’ udptl.c:1275: error: expected declaration or statement at end of input udptl.c:1275: error: expected declaration or statement at end of input make[1]: *** [udptl.o] Fehler 1 make[1]: Leaving directory `/usr/src/Asterisk/1.4/asterisk-1.4-svn/main' make: *** [main] Fehler 2 By: Tilghman Lesher (tilghman) 2009-02-12 12:24:47.000-0600 Oops, typo. Fixed in latest patch. By: Bastian Schern (schern) 2009-02-12 13:30:32.000-0600 Patch works fine now. Success with Grandstream HT-502 but still no success witch Linksys ATAs. By: GERD GERD (gerd1000) 2009-02-12 13:57:10.000-0600 I don't think that this a is problem of udptl.c but a problem of one of the media gateways (either linksys and/or carrier side) or FAX G3 itself. So, from my point of view, this bug could be closed as it seems to be an interoperability problem. Try national call (B. said to me that the network in Germany is more recent). You may try different settings of error correction, although I dont believe it helps. From my experience I have to say, some devices work, some not, some firmware works, some not, even not every G3 device works with other G3 devices. If they say they support T.38, O.K., lets check ;-) Sorry for being off-topic, may I ask if you have a relation to FOKUS ? By: Digium Subversion (svnbot) 2009-02-12 15:19:48.000-0600 Repository: asterisk Revision: 175311 U branches/1.4/main/udptl.c ------------------------------------------------------------------------ r175311 | tilghman | 2009-02-12 15:19:48 -0600 (Thu, 12 Feb 2009) | 9 lines Fix crashes when receiving certain T.38 packets. Also, increase the maximum size of T.38 packets and warn users when they try to set the limits above those maximums. (closes issue ASTERISK-12357) Reported by: schern Patches: 20090212__bug13050.diff.txt uploaded by Corydon76 (license 14) Tested by: schern ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175311 By: Digium Subversion (svnbot) 2009-02-12 15:25:29.000-0600 Repository: asterisk Revision: 175334 _U trunk/ U trunk/main/udptl.c ------------------------------------------------------------------------ r175334 | tilghman | 2009-02-12 15:25:29 -0600 (Thu, 12 Feb 2009) | 16 lines Merged revisions 175311 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175311 | tilghman | 2009-02-12 15:19:40 -0600 (Thu, 12 Feb 2009) | 9 lines Fix crashes when receiving certain T.38 packets. Also, increase the maximum size of T.38 packets and warn users when they try to set the limits above those maximums. (closes issue ASTERISK-12357) Reported by: schern Patches: 20090212__bug13050.diff.txt uploaded by Corydon76 (license 14) Tested by: schern ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175334 By: Digium Subversion (svnbot) 2009-02-12 15:27:09.000-0600 Repository: asterisk Revision: 175342 _U branches/1.6.1/ U branches/1.6.1/main/udptl.c ------------------------------------------------------------------------ r175342 | tilghman | 2009-02-12 15:27:09 -0600 (Thu, 12 Feb 2009) | 23 lines Merged revisions 175334 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r175334 | tilghman | 2009-02-12 15:25:14 -0600 (Thu, 12 Feb 2009) | 16 lines Merged revisions 175311 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175311 | tilghman | 2009-02-12 15:19:40 -0600 (Thu, 12 Feb 2009) | 9 lines Fix crashes when receiving certain T.38 packets. Also, increase the maximum size of T.38 packets and warn users when they try to set the limits above those maximums. (closes issue ASTERISK-12357) Reported by: schern Patches: 20090212__bug13050.diff.txt uploaded by Corydon76 (license 14) Tested by: schern ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175342 By: Digium Subversion (svnbot) 2009-02-12 15:28:01.000-0600 Repository: asterisk Revision: 175347 _U branches/1.6.0/ U branches/1.6.0/main/udptl.c ------------------------------------------------------------------------ r175347 | tilghman | 2009-02-12 15:28:01 -0600 (Thu, 12 Feb 2009) | 23 lines Merged revisions 175334 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r175334 | tilghman | 2009-02-12 15:25:14 -0600 (Thu, 12 Feb 2009) | 16 lines Merged revisions 175311 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175311 | tilghman | 2009-02-12 15:19:40 -0600 (Thu, 12 Feb 2009) | 9 lines Fix crashes when receiving certain T.38 packets. Also, increase the maximum size of T.38 packets and warn users when they try to set the limits above those maximums. (closes issue ASTERISK-12357) Reported by: schern Patches: 20090212__bug13050.diff.txt uploaded by Corydon76 (license 14) Tested by: schern ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175347 | ||