Re: [Openbts-discuss] OpenBTS + Asterisk = made a call -> crashed -> Segmentation fault(?)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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
> >>> >
> >>
> >>
>
>

Re: [Openbts-discuss] OpenBTS + Asterisk = made a call -> crashed -> Segmentation fault(?)

GSM L1-L3 stack with SIP network interfaces

Re: [Openbts-discuss] OpenBTS + Asterisk = made a call -> crashed -> Segmentation fault(?)