From: Ellen A. <ell...@go...> - 2012-08-03 12:21:09
|
Hello again. OpenBTS works but sometimes if I want to make a call I get following Error message and Asterisk crashes. If I make a call from console to 6202, 6202 answers and 6101 also try to call 6202 I get following message: modules.conf > [modules] > autoload=yes > load => chan_lcr.so > load => chan_alsa.so > noload => chan_oss.so > noload => chan_console.so > server*CLI> console dial 6202 > -- Executing [6202@local:1] Macro("ALSA/default", "dialGSM, > IMSI123456789101112@127.0.0.1:5062") in new stack > -- Executing [s@macro-dialGSM:1] Dial("ALSA/default", "SIP/ > IMSI123456789101112@127.0.0.1:5062") in new stack > == Using SIP RTP CoS mark 5 > -- Called SIP/IMSI123456789101112@127.0.0.1:5062 > -- SIP/127.0.0.1:5062-00000000 is ringing > -- SIP/127.0.0.1:5062-00000000 is ringing > -- SIP/127.0.0.1:5062-00000000 is ringing > -- SIP/127.0.0.1:5062-00000000 answered ALSA/default > << Console call has been answered >> > == Using SIP RTP CoS mark 5 > -- Executing [6202@sip-external:1] > Macro("SIP/IMSI262032761936993-00000001", "dialGSM, > IMSI123456789101112@127.0.0.1:5062") in new stack > -- Executing [s@macro-dialGSM:1] > Dial("SIP/IMSI262032761936993-00000001", "SIP/ > IMSI123456789101112@127.0.0.1:5062") in new stack > == Using SIP RTP CoS mark 5 > -- Called SIP/IMSI123456789101112@127.0.0.1:5062 > == Spawn extension (macro-dialGSM, s, 1) exited non-zero on > 'SIP/IMSI262032761936993-00000001' in macro 'dialGSM' > == Spawn extension (sip-external, 6202, 1) exited non-zero on > 'SIP/IMSI262032761936993-00000001' > *[Aug 3 13:48:57] WARNING[9817]: chan_sip.c:3641 retrans_pkt: > Retransmission timeout reached on transmission 1101619299@127.0.0.1 for > seqno 450 (Critical Response) -- See > https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions* > Packet timed out after 6400ms with no response > == Spawn extension (macro-dialGSM, s, 1) exited non-zero on > 'ALSA/default' in macro 'dialGSM' > == Spawn extension (local, 6202, 1) exited non-zero on 'ALSA/default' > << Hangup on console >> > If I want to call 6202 again from console this happens: server*CLI> console dial 6202 > -- Executing [6202@local:1] Macro("ALSA/default", "dialGSM, > IMSI123456789101112@127.0.0.1:5062") in new stack > -- Executing [s@macro-dialGSM:1] Dial("ALSA/default", "SIP/ > IMSI123456789101112@127.0.0.1:5062") in new stack > == Using SIP RTP CoS mark 5 > -- Called SIP/IMSI123456789101112@127.0.0.1:5062 > *[Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable > * *[Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable* > [Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable > ... > ... > ... > [Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable > [Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable > [Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable > [Aug 3 13:50:59] ERROR[9984]: chan_alsa.c:481 alsa_read: Read error: > Resource temporarily unavailable > server*CLI> > Disconnected from Asterisk server > Executing last minute cleanups > If I use chan_oss instead of chan_alsa: [modules] autoload=yes load => chan_lcr.so noload => chan_alsa.so load => chan_oss.so noload => chan_console.so *CLI> console dial 6202 > [Aug 3 14:15:06] WARNING[11174]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- Executing [6202@default:1] Macro("Console/dsp", "dialGSM, > IMSI123456789101112@127.0.0.1:5062") in new stack > -- Executing [s@macro-dialGSM:1] Dial("Console/dsp", "SIP/ > IMSI123456789101112@127.0.0.1:5062") in new stack > == Using SIP RTP CoS mark 5 > -- Called SIP/IMSI123456789101112@127.0.0.1:5062 > -- SIP/127.0.0.1:5062-00000000 is ringing > [Aug 3 14:15:07] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- SIP/127.0.0.1:5062-00000000 is ringing > [Aug 3 14:15:08] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- SIP/127.0.0.1:5062-00000000 is ringing > [Aug 3 14:15:09] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- SIP/127.0.0.1:5062-00000000 is ringing > [Aug 3 14:15:10] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- SIP/127.0.0.1:5062-00000000 is ringing > [Aug 3 14:15:11] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- SIP/127.0.0.1:5062-00000000 is ringing > [Aug 3 14:15:13] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > -- SIP/127.0.0.1:5062-00000000 answered Console/dsp > << Console call has been answered >> > [Aug 3 14:15:14] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > .... > ... > [Aug 3 14:15:27] WARNING[11296]: chan_oss.c:489 setformat: Unable to > re-open DSP device /dev/dsp: No such file or directory > == Spawn extension (macro-dialGSM, s, 1) exited non-zero on > 'Console/dsp' in macro 'dialGSM' > == Spawn extension (default, 6202, 1) exited non-zero on 'Console/dsp' > << Hangup on console >> > I didn't find the reason for this error yet but perhaps one of you know this issue. In the internet wasn't much what helped me so I hope you can help me. Regards Ellen On Thu, Aug 2, 2012 at 10:52 AM, Ellen Apolinar < ell...@go...> wrote: > Hey Kurtis, > > yes, you are right. Thank you. I should have read that. > > Now it works and seems to be stable. > > Best regards. > Ellen > > == Using SIP RTP CoS mark 5 >> -- Executing [6202@sip-external:1] >> Macro("SIP/IMSI262032761936993-00000003", "dialGSM, >> IMSI123456789101112@127.0.0.1:5062") in new stack >> -- Executing [s@macro-dialGSM:1] >> Dial("SIP/IMSI262032761936993-00000003", "SIP/ >> IMSI123456789101112@127.0.0.1:5062") in new stack >> >> == Using SIP RTP CoS mark 5 >> -- Called SIP/IMSI123456789101112@127.0.0.1:5062 >> -- SIP/127.0.0.1:5062-00000004 is ringing >> -- SIP/127.0.0.1:5062-00000004 is ringing >> -- SIP/127.0.0.1:5062-00000004 is ringing >> -- SIP/127.0.0.1:5062-00000004 answered >> SIP/IMSI262032761936993-00000003 >> -- Remotely bridging SIP/IMSI262032761936993-00000003 and >> SIP/127.0.0.1:5062-00000004 >> == Spawn extension (macro-dialGSM, s, 1) exited non-zero on >> 'SIP/IMSI262032761936993-00000003' in macro 'dialGSM' >> == Spawn extension (sip-external, 6202, 1) exited non-zero on >> 'SIP/IMSI262032761936993-00000003' >> > > > > Regards > Ellen > > > On Tue, Jul 31, 2012 at 7:47 PM, Kurtis Heimerl <khe...@cs...> > wrote: > > It looks like it's working now. We added remote CLI support, so you > > need to run OpenBTSCLI after starting openbts. > > > > On Tue, Jul 31, 2012 at 4:47 AM, Ellen Apolinar > > <ell...@go...> wrote: > >> Hey Kurtis, > >> > >> I have the following version: > >> > >> OpenBTS> version > >>> > >>> release P2.8TRUNK built May 16 2012 > >> > >> > >> I decided to make an update, but now I receive an error message. I made > the > >> update on the following way: > >> > >> svn update > >>> > >>> Updated to revision 3961. > >> > >> > >> svn log | head > >>> > >>> > ------------------------------------------------------------------------ > >>> r3925 | kurtis.heimerl | 2012-07-24 07:55:51 +0200 (Di, 24 Jul 2012) | > 1 > >>> line > >>> > >>> Set state to fail instead of throwing a timeout in MOSMSWaitForSubmit > >>> > ------------------------------------------------------------------------ > >>> r3923 | kurtis.heimerl | 2012-07-24 07:29:37 +0200 (Di, 24 Jul 2012) | > 1 > >>> line > >>> > >>> Fixed null pointer in MOSMSSubmit. > >>> > ------------------------------------------------------------------------ > >>> r3918 | kurtis.heimerl | 2012-07-22 07:09:00 +0200 (So, 22 Jul 2012) | > 1 > >>> line > >>> svn: Write error: Broken pipe > >> > >> > >> https://wush.net/trac/rangepublic/wiki/UpdateOpenBTS > >> As svn fetch didn't work I chose to make svn update. I am not sure if > that > >> was really right. > >> > >> Now I get following error message, when I start OpenBTS: > >>> > >>> 1343733566.156621 3074680528: > >>> Starting the system... > >>> > >>> system ready > >>> > >>> use the OpenBTSCLI utility to access CLI > >>> > >>> rm: cannot remove `/var/run/command': No such file or directory > >> > >> > >> (Sometimes there is the last line, sometimes not. If it isn't my phone > is > >> connected with OpenBTS but I can't use OpenBTS with the terminal > because it > >> hangs. > >> > >> Using gdb OpenBTS before update > >>> > >>> GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 > >>> Copyright (C) 2011 Free Software Foundation, Inc. > >>> License GPLv3+: GNU GPL version 3 or later > >>> <http://gnu.org/licenses/gpl.html> > >>> This is free software: you are free to change and redistribute it. > >>> There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > >>> and "show warranty" for details. > >>> This GDB was configured as "i686-linux-gnu". > >>> For bug reporting instructions, please see: > >>> <http://bugs.launchpad.net/gdb-linaro/>... > >>> Reading symbols from /etc/openbts/trunk/apps/OpenBTS...done. > >>> (gdb) bt > >>> No stack. > >>> (gdb) r > >>> Starting program: /etc/openbts/trunk/apps/OpenBTS > >>> [Thread debugging using libthread_db enabled] > >>> [New Thread 0xb7c8cb70 (LWP 13703)] > >>> cannot find configuration value [Thread 0xb7c8cb70 (LWP 13703) exited] > >>> GSM.Radio.ARFCNs > >>> terminate called after throwing an instance of > >>> 'ConfigurationTableKeyNotFound' > >>> > >>> Program received signal SIGABRT, Aborted. > >>> 0xb7fdf424 in __kernel_vsyscall () > >>> (gdb) > >> > >> > >> Using gdb OpenBTS after update: > >>> > >>> 1343733676.193887 3083396816: > >>> Starting the system... > >>> [New Thread 0xb7461b70 (LWP 19632)] > >>> [New Thread 0xb7c8cb70 (LWP 19633)] > >>> [New Thread 0xb7420b70 (LWP 19635)] > >>> [New Thread 0xb73dfb70 (LWP 19640)] > >>> [New Thread 0xb739eb70 (LWP 19641)] > >>> [New Thread 0xb735db70 (LWP 19645)] > >>> [New Thread 0xb731cb70 (LWP 19646)] > >>> [New Thread 0xb72dbb70 (LWP 19647)] > >>> [New Thread 0xb729ab70 (LWP 19648)] > >>> [New Thread 0xb7259b70 (LWP 19649)] > >>> [New Thread 0xb7218b70 (LWP 19650)] > >>> [New Thread 0xb71d7b70 (LWP 19651)] > >>> [New Thread 0xb7196b70 (LWP 19652)] > >>> [New Thread 0xb7155b70 (LWP 19653)] > >>> [New Thread 0xb6fffb70 (LWP 19654)] > >>> [New Thread 0xb6fbeb70 (LWP 19655)] > >>> [New Thread 0xb6f7db70 (LWP 19656)] > >>> [New Thread 0xb6f3cb70 (LWP 19657)] > >>> [New Thread 0xb6efbb70 (LWP 19658)] > >>> [New Thread 0xb6ebab70 (LWP 19659)] > >>> [New Thread 0xb6e79b70 (LWP 19660)] > >>> [New Thread 0xb6e38b70 (LWP 19661)] > >>> [New Thread 0xb6df7b70 (LWP 19662)] > >>> [New Thread 0xb6db6b70 (LWP 19663)] > >>> [New Thread 0xb6d75b70 (LWP 19664)] > >>> [New Thread 0xb6d34b70 (LWP 19665)] > >>> [New Thread 0xb6cf3b70 (LWP 19666)] > >>> [New Thread 0xb6cb2b70 (LWP 19667)] > >>> [New Thread 0xb6c71b70 (LWP 19668)] > >>> [New Thread 0xb6c30b70 (LWP 19669)] > >>> [New Thread 0xb6befb70 (LWP 19670)] > >>> [New Thread 0xb6baeb70 (LWP 19671)] > >>> [New Thread 0xb6b6db70 (LWP 19672)] > >>> [New Thread 0xb6b2cb70 (LWP 19673)] > >>> [New Thread 0xb6aebb70 (LWP 19674)] > >>> [New Thread 0xb6aaab70 (LWP 19675)] > >>> [New Thread 0xb6a69b70 (LWP 19676)] > >>> [New Thread 0xb6a28b70 (LWP 19677)] > >>> [New Thread 0xb69e7b70 (LWP 19678)] > >>> [New Thread 0xb69a6b70 (LWP 19679)] > >>> [New Thread 0xb6965b70 (LWP 19680)] > >>> [New Thread 0xb6924b70 (LWP 19681)] > >>> [New Thread 0xb68e3b70 (LWP 19682)] > >>> [New Thread 0xb68a2b70 (LWP 19683)] > >>> [New Thread 0xb6861b70 (LWP 19684)] > >>> [New Thread 0xb6820b70 (LWP 19685)] > >>> [New Thread 0xb67dfb70 (LWP 19686)] > >>> [New Thread 0xb679eb70 (LWP 19687)] > >>> [New Thread 0xb675db70 (LWP 19688)] > >>> [New Thread 0xb671cb70 (LWP 19689)] > >>> [New Thread 0xb66dbb70 (LWP 19690)] > >>> [New Thread 0xb669ab70 (LWP 19691)] > >>> [New Thread 0xb6659b70 (LWP 19692)] > >>> [New Thread 0xb6618b70 (LWP 19693)] > >>> [New Thread 0xb65d7b70 (LWP 19694)] > >>> [New Thread 0xb6596b70 (LWP 19695)] > >>> [New Thread 0xb6555b70 (LWP 19696)] > >>> [New Thread 0xb6514b70 (LWP 19697)] > >>> [New Thread 0xb64d3b70 (LWP 19698)] > >>> [New Thread 0xb6492b70 (LWP 19699)] > >>> [New Thread 0xb6451b70 (LWP 19700)] > >>> [New Thread 0xb6410b70 (LWP 19701)] > >>> [New Thread 0xb63cfb70 (LWP 19702)] > >>> [New Thread 0xb638eb70 (LWP 19703)] > >>> [New Thread 0xb634db70 (LWP 19704)] > >>> [New Thread 0xb630cb70 (LWP 19705)] > >>> [New Thread 0xb62cbb70 (LWP 19706)] > >>> [New Thread 0xb628ab70 (LWP 19707)] > >>> [New Thread 0xb6249b70 (LWP 19708)] > >>> [New Thread 0xb6208b70 (LWP 19709)] > >>> [New Thread 0xb61c7b70 (LWP 19710)] > >>> [New Thread 0xb6186b70 (LWP 19711)] > >>> [New Thread 0xb6145b70 (LWP 19712)] > >>> [New Thread 0xb6104b70 (LWP 19713)] > >>> [New Thread 0xb60c3b70 (LWP 19714)] > >>> [New Thread 0xb6082b70 (LWP 19715)] > >>> [New Thread 0xb6041b70 (LWP 19716)] > >>> [New Thread 0xb6000b70 (LWP 19717)] > >>> [New Thread 0xb5fbfb70 (LWP 19718)] > >>> [New Thread 0xb5f7eb70 (LWP 19719)] > >>> [New Thread 0xb5f3db70 (LWP 19720)] > >>> [New Thread 0xb5efcb70 (LWP 19721)] > >>> [New Thread 0xb5ebbb70 (LWP 19722)] > >>> [New Thread 0xb5e7ab70 (LWP 19723)] > >>> [New Thread 0xb5e39b70 (LWP 19724)] > >>> [New Thread 0xb5df8b70 (LWP 19725)] > >>> [New Thread 0xb5db7b70 (LWP 19726)] > >>> [New Thread 0xb5d76b70 (LWP 19727)] > >>> > >>> system ready > >>> > >>> use the OpenBTSCLI utility to access CLI > >> > >> > >> > >> So it would be appreciated if someone can help me. When I search in > google I > >> read that it is an error with the SIP Registration. Actually I have: > >> > >> OpenBTS.db: > >> INSERT INTO "CONFIG" VALUES('SIP.Local.IP','127.0.0.1',1,0,'IP address > of > >> the OpenBTS machine as seen by its proxies. If these are all local, > this > >> can be localhost. Static.'); > >> INSERT INTO "CONFIG" VALUES('SIP.Local.Port','5062',1,0,'IP port that > >> OpenBTS uses for its SIP interface. Static.'); > >> INSERT INTO "CONFIG" VALUES('SIP.MaxForwards','5',0,0,'Maximum allowed > >> number of referrals.'); > >> INSERT INTO "CONFIG" > >> VALUES('SIP.Proxy.Registration','127.0.0.1:5064',0,0,'The IP host and > port > >> of the proxy to be used for registration and authentication. This > should > >> normally be the subscriber registry SIP interface, not Asterisk.'); > >> INSERT INTO "CONFIG" VALUES('SIP.Proxy.SMS','127.0.0.1:5063',0,0,'The > IP > >> host and port of the proxy to be used for text messaging. This is > smqueue, > >> for example.'); > >> INSERT INTO "CONFIG" VALUES('SIP.Proxy.Speech','127.0.0.1:5060',0,0,'The > IP > >> host and port of the proxy to be used for normal speech calls. This is > >> Asterisk, for example.'); > >> ... > >> INSERT INTO "CONFIG" > VALUES('SubscriberRegistry.Manager.Title','Subscriber > >> Registry',0,0,'Title of subscriber registry database manager web > page.'); > >> INSERT INTO "CONFIG" > >> VALUES('SubscriberRegistry.Manager.Url',' > http://127.0.0.1/cgi/srmanager.cgi',0,0,'URL > >> of the subscriber registry database manager.'); > >> INSERT INTO "CONFIG" > >> VALUES('SubscriberRegistry.Manager.VisibleColumns','name username type > >> context host',0,0,'Field names in subscriber registry visible in the > >> database manager.'); > >> INSERT INTO "CONFIG" > >> > VALUES('SubscriberRegistry.db','/var/lib/asterisk/sqlite3dir/sqlite3.db',0,0,'The > >> location of the sqlite3 database holding the subscriber registry.'); > >> INSERT INTO "CONFIG" VALUES('SubscriberRegistry.Port','5064',0,0,'Port > used > >> by the SIP Authentication Server. NOTE: In some older releases > (pre-2.8.1) > >> this is called SIP.myPort.'); > >> > >> But sipauthserve starts withour errors. Also Asterisk and smqueue. > >> > >> The one thing I changed (before the update) was > >> 'SIP.Proxy.Registration','127.0.0.1:5064' to > >> 'SIP.Proxy.Registration','127.0.0.1:5060' for making calls from > Asterisk > >> over OpenBTS to my phones. > >> > >> Regards > >> Ellen > >> > >> > >> On Mon, Jul 30, 2012 at 7:26 PM, Kurtis Heimerl < > khe...@cs...> > >> wrote: > >>> > >>> Make sure you have the most recent version of the code. > >>> > >>> Then run OpenBTS in gdb and give us the stack trace. We must have a > >>> null pointer floating around somewhere. > >>> > >>> On Mon, Jul 30, 2012 at 8:44 AM, Ellen Apolinar > >>> <ell...@go...> wrote: > >>> > Nobody who has an idea? > >>> > > >>> > > >>> > > >>> > > >>> > On Fri, Jul 27, 2012 at 1:17 PM, Ellen Apolinar > >>> > <ell...@go...> wrote: > >>> >> > >>> >> Hey all, > >>> >> > >>> >> I have a problem with calls between two mobile phones. > >>> >> > >>> >> I am able to > >>> >> > >>> >> - send sms from CLI to both phones > >>> >> - make calls from CLI to each phone > >>> >> > >>> >> What doesn't work: > >>> >> > >>> >> - send SMS between the phones > >>> >> - make calls between the phones > >>> >> > >>> >> What could be the problem: > >>> >> Since two days my internet connection isn't stable so perhaps only > this > >>> >> is > >>> >> the problem. But I don't think so. Perhaps you can see an error in > my > >>> >> configs so I can fix it. The next time I can try a call between the > >>> >> both > >>> >> phones is on monday. > >>> >> > >>> >> > >>> >> In the moment I can make a call from one phone to the other phone > but > >>> >> after a few seconds OpenBTS crashes. > >>> >> > >>> >> call: > >>> >> - 6101 -> 6202 > >>> >> - 6202 was ringing > >>> >> - 6202 answered > >>> >> - I didn't cancel the call, then it crashed > >>> >> > >>> >> OpenBTS shows: > >>> >>> > >>> >>> OpenBTS> Segmentation fault > >>> >> > >>> >> > >>> >> Asterisk shows: > >>> >>> > >>> >>> == Using SIP RTP CoS mark 5 > >>> >>> -- Executing [6202@sip-external:1] > >>> >>> Macro("SIP/IMSI262032761936993-00000000", > >>> >>> "dialGSM,IMSI123456789101112@127.0.0.1:5062") in new stack > >>> >>> -- Executing [s@macro-dialGSM:1] > >>> >>> Answer("SIP/IMSI262032761936993-00000000", "") in new stack > >>> >>> -- Executing [s@macro-dialGSM:2] > >>> >>> Dial("SIP/IMSI262032761936993-00000000", > >>> >>> "SIP/IMSI123456789101112@127.0.0.1:5062") in new stack > >>> >>> == Using SIP RTP CoS mark 5 > >>> >>> -- Called SIP/IMSI123456789101112@127.0.0.1:5062 > >>> >>> -- SIP/127.0.0.1:5062-00000001 is ringing > >>> >>> -- SIP/127.0.0.1:5062-00000001 is ringing > >>> >>> -- SIP/127.0.0.1:5062-00000001 is ringing > >>> >>> -- SIP/127.0.0.1:5062-00000001 is ringing > >>> >>> -- SIP/127.0.0.1:5062-00000001 is ringing > >>> >>> -- SIP/127.0.0.1:5062-00000001 is ringing > >>> >>> -- SIP/127.0.0.1:5062-00000001 answered > >>> >>> SIP/IMSI262032761936993-00000000 > >>> >>> -- Remotely bridging SIP/IMSI262032761936993-00000000 and > >>> >>> SIP/127.0.0.1:5062-00000001 > >>> >>> [Jul 27 11:53:35] WARNING[15143]: chan_sip.c:3641 retrans_pkt: > >>> >>> Retransmission timeout reached on transmission 722236644@127.0.0.1for > >>> >>> seqno > >>> >>> 102 (Critical Request) -- See > >>> >>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > >>> >>> Packet timed out after 6399ms with no response > >>> >>> [Jul 27 11:53:35] WARNING[15143]: chan_sip.c:3670 retrans_pkt: > Hanging > >>> >>> up > >>> >>> call 722236644@127.0.0.1 - no reply to our critical packet (see > >>> >>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions). > >>> >>> == Spawn extension (macro-dialGSM, s, 2) exited non-zero on > >>> >>> 'SIP/IMSI262032761936993-00000000' in macro 'dialGSM' > >>> >>> == Spawn extension (sip-external, 6202, 1) exited non-zero on > >>> >>> 'SIP/IMSI262032761936993-00000000' > >>> >> > >>> >> //After it crashed: > >>> >>> > >>> >>> [Jul 27 11:54:01] WARNING[15143]: chan_sip.c:3641 retrans_pkt: > >>> >>> Retransmission timeout reached on transmission > >>> >>> 3994188817905fe5063ec3627903c8f8@127.0.0.1:5060 for seqno 103 > >>> >>> (Critical > >>> >>> Request) -- See > >>> >>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > >>> >>> Packet timed out after 32001ms with no response > >>> >> > >>> >> > >>> >> > >>> >> I have tried OpenBTS with different configurations, with > >>> >> SIP.Proxy.Registration = 5060, 5063 and with 5064. But there was no > >>> >> difference between these as I tried to send SMS between the phones. > >>> >> > >>> >> my OpenBTS.sql: > >>> >>> > >>> >>> 'SIP.Proxy.Registration','127.0.0.1:5060' > >>> >>> 'SIP.Proxy.SMS','127.0.0.1:5063' > >>> >>> 'SIP.Proxy.Speech','127.0.0.1:5060' > >>> >> > >>> >> > >>> >> > >>> >> Here what Asterisk shows when debugging is enabled: > >>> >> (The hole message is in the attached file Asterisk_debugging.txt, > here > >>> >> I > >>> >> show the parts which could be important.) > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> INVITE sip:6101@127.0.0.1 SIP/2.0 > >>> >>> Via: SIP/2.0/UDP 127.0.0.1:5062 > ;branch=z9hG4bKobts286a5180917c22f7a2 > >>> >>> From: IMSI123456789101112 > >>> >>> <sip:IMSI123456789101112@127.0.0.1>;tag=wbrkhicwygxbgpfa > >>> >>> To: <sip:6101@127.0.0.1> > >>> >>> > >>> >>> --- (12 headers 7 lines) --- > >>> >>> Sending to 127.0.0.1:5062 (NAT) > >>> >>> Using INVITE request as basis request - 820887910@127.0.0.1 > >>> >>> Found peer 'IMSI123456789101112' for 'IMSI123456789101112' from > >>> >>> 127.0.0.1:5062 > >>> >>> > >>> >>> <--- Transmitting (no NAT) to 127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> INVITE sip:6101@127.0.0.1 SIP/2.0 > >>> >>> <--- Transmitting (no NAT) to 127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 180 Ringing > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 200 OK > >>> >>> > >>> >>> <--- Reliably Transmitting (no NAT) to 127.0.0.1:5062 ---> > >>> >>> SIP/2.0 200 OK > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> ACK sip:6101@127.0.0.1 SIP/2.0 > >>> >>> Via: SIP/2.0/UDP 127.0.0.1:5062 > ;branch=z9hG4bKobts287941ba2d45482293 > >>> >>> From: IMSI123456789101112 > >>> >>> <sip:IMSI123456789101112@127.0.0.1>;tag=wbrkhicwygxbgpfa > >>> >>> To: <sip:6101@127.0.0.1>;tag=as76b341ee > >>> >>> Call-ID: 820887910@127.0.0.1 > >>> >>> CSeq: 383 ACK > >>> >>> User-Agent: OpenBTS P2.8TRUNK Build Date May 16 2012 > >>> >>> Max-Forwards: 5 > >>> >>> Content-Length: 0 > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #1 (no NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI123456789101112@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #2 (no NAT) to 127.0.0.1:5062: > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #1 (NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI262032761936993@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #3 (no NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI123456789101112@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #2 (NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI262032761936993@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #4 (no NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI123456789101112@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #5 (no NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI123456789101112@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #3 (NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI262032761936993@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #6 (no NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI123456789101112@127.0.0.1:5062 SIP/2.0 > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> [Jul 27 12:19:31] WARNING[15893]: chan_sip.c:3641 retrans_pkt: > >>> >>> Retransmission timeout reached on transmission 820887910@127.0.0.1for > >>> >>> seqno > >>> >>> 102 (Critical Request) -- See > >>> >>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > >>> >>> Packet timed out after 6400ms with no response > >>> >>> [Jul 27 12:19:31] WARNING[15893]: chan_sip.c:3670 retrans_pkt: > Hanging > >>> >>> up > >>> >>> call 820887910@127.0.0.1 - no reply to our critical packet (see > >>> >>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions). > >>> >>> Scheduling destruction of SIP dialog > >>> >>> '440247964f8493ba50863d2f69cf3fd8@127.0.0.1:5060' in 32000 ms > (Method: > >>> >>> INVITE) > >>> >>> Really destroying SIP dialog '820887910@127.0.0.1' Method: ACK > >>> >>> Retransmitting #4 (NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI262032761936993@127.0.0.1:5062 SIP/2.0 > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Really destroying SIP dialog > >>> >>> '79c56285544d34e737bf9d3c308e4afa@127.0.0.1:5060' Method: OPTIONS > >>> >>> Really destroying SIP dialog > >>> >>> '3a368c890fc148b206d43b3073dfe9d4@127.0.0.1:5060' Method: OPTIONS > >>> >>> Retransmitting #5 (NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI262032761936993@127.0.0.1:5062 SIP/2.0 > >>> >>> <--- SIP read from UDP:127.0.0.1:5062 ---> > >>> >>> SIP/2.0 100 Trying > >>> >>> <-------------> > >>> >>> --- (9 headers 0 lines) --- > >>> >>> Retransmitting #6 (NAT) to 127.0.0.1:5062: > >>> >>> INVITE sip:IMSI262032761936993@127.0.0.1:5062 SIP/2.0 > >>> >>> --- > >>> >>> [Jul 27 12:19:56] WARNING[15893]: chan_sip.c:3641 retrans_pkt: > >>> >>> Retransmission timeout reached on transmission > >>> >>> 440247964f8493ba50863d2f69cf3fd8@127.0.0.1:5060 for seqno 103 > >>> >>> (Critical > >>> >>> Request) -- See > >>> >>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > >>> >>> Packet timed out after 32000ms with no response > >>> >>> Really destroying SIP dialog > >>> >>> '440247964f8493ba50863d2f69cf3fd8@127.0.0.1:5060' Method: INVITE > >>> >>> > >>> >>> Reliably Transmitting (no NAT) to 127.0.0.1:5060: > >>> >>> OPTIONS sip:127.0.0.1 SIP/2.0 > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5060 ---> > >>> >>> OPTIONS sip:127.0.0.1 SIP/2.0 > >>> >>> <-------------> > >>> >>> --- (13 headers 0 lines) --- > >>> >>> Looking for s in default (domain 127.0.0.1) > >>> >>> <--- Transmitting (NAT) to 127.0.0.1:5060 ---> > >>> >>> SIP/2.0 404 Not Found > >>> >>> <------------> > >>> >>> Scheduling destruction of SIP dialog > >>> >>> '42973b0f0cdf3a184dbefc2511404b14@127.0.0.1:5060' in 32000 ms > (Method: > >>> >>> OPTIONS) > >>> >>> <--- SIP read from UDP:127.0.0.1:5060 ---> > >>> >>> SIP/2.0 404 Not Found > >>> >>> <-------------> > >>> >>> --- (11 headers 0 lines) --- > >>> >>> Really destroying SIP dialog > >>> >>> '42973b0f0cdf3a184dbefc2511404b14@127.0.0.1:5060' Method: OPTIONS > >>> >>> Reliably Transmitting (no NAT) to 127.0.0.1:5060: > >>> >>> OPTIONS sip:127.0.0.1 SIP/2.0 > >>> >>> > >>> >>> User-Agent: Asterisk PBX 1.8.13.0 > >>> >>> Date: Fri, 27 Jul 2012 10:20:04 GMT > >>> >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, > >>> >>> INFO, > >>> >>> PUBLISH > >>> >>> Supported: replaces, timer > >>> >>> Content-Length: 0 > >>> >>> > >>> >>> <--- SIP read from UDP:127.0.0.1:5060 ---> > >>> >>> OPTIONS sip:127.0.0.1 SIP/2.0 > >>> >>> <-------------> > >>> >>> --- (13 headers 0 lines) --- > >>> >>> Looking for s in default (domain 127.0.0.1) > >>> >>> <--- Transmitting (NAT) to 127.0.0.1:5060 ---> > >>> >>> SIP/2.0 404 Not Found > >>> >>> <------------> > >>> >>> Scheduling destruction of SIP dialog > >>> >>> '613033092538fae56013b0b2660084a4@127.0.0.1:5060' in 32000 ms > (Method: > >>> >>> OPTIONS) > >>> >>> <--- SIP read from UDP:127.0.0.1:5060 ---> > >>> >>> SIP/2.0 404 Not Found > >>> >>> <-------------> > >>> >>> --- (11 headers 0 lines) --- > >>> >>> Really destroying SIP dialog > >>> >>> '613033092538fae56013b0b2660084a4@127.0.0.1:5060' Method: OPTIONS > >>> >> > >>> >> > >>> >> In the error messages there was a link to this site: > >>> >> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > >>> >> > >>> >> It says: > >>> >>> > >>> >>> Why does this happen? > >>> >>> > >>> >>> For some reason signalling doesn't work as expected between your > >>> >>> Asterisk > >>> >>> server and the other device. There could be many reasons why this > >>> >>> happens. > >>> >>> > >>> >>> A NAT device in the signalling path. A misconfigured NAT device is > in > >>> >>> the > >>> >>> signalling path and stops SIP messages. > >>> >>> A firewall that blocks messages or reroutes them wrongly in an > attempt > >>> >>> to > >>> >>> assist in a too clever way. > >>> >>> A SIP middlebox (SBC) that rewrites contact: headers so that we > can't > >>> >>> reach the other side with our reply or the ACK. > >>> >>> A badly configured SIP proxy that forgets to add record-route > headers > >>> >>> to > >>> >>> make sure that signalling works. > >>> >>> Packet loss. IP and UDP are unreliable transports. If you loose too > >>> >>> many > >>> >>> packets the retransmits doesn't help and communication is > impossible. > >>> >>> If > >>> >>> this happens with signaling, media would be unusable anyway. > >>> >> > >>> >> It could nor be the firewall nor a NAT. > >>> >> > >>> >> My sip.conf: > >>> >>> > >>> >>> [IMSI123456789101112] > >>> >>> callerid=IMSI123456789101112 <IMSI123456789101112> > >>> >>> port = 5060 > >>> >>> srvlookup = yes > >>> >>> type = friend > >>> >>> context = sip-external > >>> >>> disallow = all > >>> >>> allow = gsm > >>> >>> host = 127.0.0.1 > >>> >>> dtmfmode = info > >>> >>> insecure = port,invite > >>> >>> Nat =yes > >>> >>> Qualify=Yes > >>> >>> Canreinvite = yes > >>> >>> > >>> >>> [IMSI262032761936993] > >>> >>> callerid=IMSI262032761936993 <IMSI262032761936993> > >>> >>> port = 5060 > >>> >>> srvlookup = yes > >>> >>> type = friend > >>> >>> context = sip-external > >>> >>> disallow = all > >>> >>> allow = gsm > >>> >>> host = 127.0.0.1 > >>> >>> dtmfmode = info > >>> >>> insecure = port,invite > >>> >>> Nat =yes > >>> >>> Qualify=Yes > >>> >>> Canreinvite = yes > >>> >> > >>> >> > >>> >> extensions.conf: > >>> >>> > >>> >>> [default] > >>> >>> exten => 6101,1,Macro(dialGSM,IMSI262032761936993@127.0.0.1:5062) > >>> >>> exten => 6202,1,Macro(dialGSM,IMSI123456789101112@127.0.0.1:5062) > >>> >>> > >>> >>> [sip-external] > >>> >>> include => default > >>> >>> > >>> >>> [macro-dialGSM] > >>> >>> exten => s,1,Dial(SIP/${ARG1}) > >>> >>> exten => s,2,Goto(s-${DIALSTATUS},1) > >>> >>> exten => s-CANCEL,n,Hangup() > >>> >>> exten => s-NOANSWER,n,Hangup() > >>> >>> exten => s-BUSY,n,Busy(30) > >>> >>> exten => s-CONGESTION,n,Congestion(30) > >>> >>> exten => s-CHANUNAVAIL,n,Playback(ss-noservice) > >>> >>> exten => s-CHANUNAVAIL,n,GoSub(s-${ARG2},1) > >>> >>> exten => s-CHANUNAVAIL,n,Hangup() > >>> >> > >>> >> > >>> >> > >>> >> Thanks for reading and to all who help to answer the questions which > >>> >> are > >>> >> sent to the mailinglist. This is a very great support. > >>> >> > >>> >> Best regards > >>> >> Ellen > >>> > > >>> > > >>> > > >>> > > >>> > > ------------------------------------------------------------------------------ > >>> > Live Security Virtual Conference > >>> > Exclusive live event will cover all the ways today's security and > >>> > threat landscape has changed and how IT managers can respond. > >>> > Discussions > >>> > will include endpoint security, mobile security and the latest in > >>> > malware > >>> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >>> > _______________________________________________ > >>> > Openbts-discuss mailing list > >>> > Ope...@li... > >>> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > >>> > > >> > >> > > |