Re: [Openbts-discuss] OpenBTS 4.0 not responding to Asterisk hangup()

[Ralph A. S. d. <ra...@sc...>]

Not exactly to the topic, but openregistration still has the issue of the irritating “404” sms when applying for a new phone number by sms to 101. 

 

Ralph.

 

 

From: Ervin Teng [mailto:erv...@sv...] 
Sent: Wednesday, 27 August, 2014 19:46
To: Michael Iedema
Cc: ope...@li...
Subject: Re: [Openbts-discuss] OpenBTS 4.0 not responding to Asterisk hangup()

 

Hi Michael,

 

I have an update to this issue, and it's quite interesting! 

 

We returned from JIFX, where we brought two radio heads, one USRP-based and another a Range Networks 5150. 

 

Running the same OpenBTS build (one compiled with --with-uhd and one without) based on 4.0, with the same configuration (except for power, C0) and the same Asterisk/sipauthserve/smqueue server separate from OpenBTS, the USRP-based system continued to exhibit the hangup problem. But the 5150 did not! 

 

This makes me wonder if it is indeed a tranciever issue...

 

Thanks,

Ervin

On Thursday, June 19, 2014, Michael Iedema <mic...@ra...> wrote:

Hi Ervin,

The thing that sparks my interest is that these were provisioned through OpenRegistration. That could definitely be the problem. We honestly need more testing of that feature because there is definitely a focus on private networks and pre-defined databases. The OpenReg sequence for getting information into the subscriber's database may differ from other paths.

The radio and transceiver shouldn't be in play here, correct. This seems to be basic signaling and state differences.

-Michael


On Jun 19, 2014, at 8:21 PM, Ervin Teng <erv...@sv... <javascript:;> >
 wrote:

> Hi Michael,
>
> I've tried this with two setups, with the same results. One of them was straight-up everything installed from the Range Github, including the Asterisk, settings, etc., on one machine.
>
> This particular setup has Asterisk 12, some modifications to the Asterisk configs, but I didn't change the flows and event sequences at all. The Asterisk, smqueue, and sipauthserve are on a separate server than the OpenBTS. The subscribers are in the sqlite3 database, provisioned through OpenRegistration.
>
> Both setups are also running Transciever52M with a USRP210, but I'd imagine that's much lower level than what's here. I'll keep debugging this, and maybe get some more logs.
>
> Thanks!
> Ervin
>
>
> On Thu, Jun 19, 2014 at 9:14 AM, Michael Iedema <mic...@ra... <javascript:;> > wrote:
> Hi Ervin,
>
> The new range configs do have that additional security parameter for each BTS (just IP authentication against Asterisk) but if you can make calls, it's already sorted out.
>
> How is the Asterisk server setup otherwise? I see it's version 12 instead of 11. Is it using different configs than the ones that ship with 4.0? Are your subscribers in the standard database or are they manually defined in the flat files sip.conf and extensions.conf.
>
> I haven't seen a replicable problem with hangups() using Asterisk and 4.0. An additional clarification from my earlier statement is that with the new switch, we're seeing this issue only appear if someone hangs up during ringing. When that occurs, the B-party isn't torn down.
>
> I will forward your traces (thanks for those!!) on and see if anything jumps out. If you get a chance to make a new trace, please include the Asterisk verbose output as well (usually from /var/log/syslog directly).
>
> Regards,
> -Michael
>
> On Jun 13, 2014, at 7:20 PM, Ervin Teng <erv...@sv... <javascript:;> > wrote:
>
> > Hi Michael,
> >
> > It's incredibly easy to replicate; it happens every time, including calls from the PSTN (hanging up on the OpenBTS phone will hang up on the public phone, but vice versa does not work). Here's the dumps I collected:
> >
> > Could it be linked to the fact that we don't have each base station as a user in the Asterisk sip.conf? I noticed the new range configs do this... but it wasn't necessary in the previous versions.
> >
> > Thanks,
> > Ervin
> >
> >
> > On Fri, Jun 13, 2014 at 8:32 AM, Michael Iedema <mic...@ra... <javascript:;> > wrote:
> > Hi Ervin,
> >
> > We ran into this today using a different switch than Asterisk. It looks like an OpenBTS bug where it cannot find the call to cancel when receiving a SIP CANCEL. Since it cannot match up the legs to kill the call, it does not tear down.
> >
> > If you can reliably reproduce this, could you provide a snip from the OpenBTS.log and a tcpdump of SIP+RTP if possible?
> >
> > Thanks for the report,
> > -Michael
> >
> > On Jun 7, 2014, at 1:34 AM, Ervin Teng <erv...@sv... <javascript:;> > wrote:
> >
> > > Ever since I upgraded to OpenBTS 4.0, I noticed phones don't hang up by themselves if the other side hangs up. Has anyone else noticed this?
> > >
> > > Following the Asterisk logs, Asterisk does indeed issue a hangup request to the appropriate phone:
> > >
> > > Hangup("SIP/IMSI001010000000006-00000064", "")
> > >
> > > With that IMSI being the phone that was hung up on.
> > >
> > > Previous versions of OpenBTS did indeed hangup the call when this command in the dial plan was executed.
> > > ------------------------------------------------------------------------------
> > > Learn Graph Databases - Download FREE O'Reilly Book
> > > "Graph Databases" is the definitive new guide to graph databases and their
> > > applications. Written by three acclaimed leaders in the field,
> > > this first edition is now available. Download your free book today!
> > > http://p.sf.net/sfu/NeoTech_______________________________________________
> > > Openbts-discuss mailing list
> > > Ope...@li... <javascript:;> 
> > > https://lists.sourceforge.net/lists/listinfo/openbts-discuss
> >
> >
> > <siprtpdump.cap><OpenBTSlog.dump>
>
>