Messages

1

YateBTS / Re: SIP Routing Issue: Hangup reason='Proxy Authentication Required'

« on: August 22, 2018, 11:40:19 AM »

One-way audio indicates usually a firewall or NAT problem.
To further diagnose look at the BYE message and its 200 OK response. Yate puts a P-RTP-Stat header indicating how many RTP (voice) packets it sent and received.

The received= tag in Via line of the answer to REGISTER is suspicious. I would expect a public IP address - the one on the outside of NAT - whose detection would allow Yate to build a proper SDP offer.
What kind of router you use for Internet access? Check if it has a SIP ALG (Application Layer Gateway) and try to turn it off.
If disabling ALG is impossible Zadarma may help if they support Symetric RTP.

Calls received over the registered account can be routed to one of the connected phones.
Add to regexroute.conf:

[contexts]
${called}^238867$=;called=MSISDN

Replace MSISDN with the number allocated to the phone you want to ring. I assumed the inbound call will be for 238867 which appears to be your account with Zadarma.

2

YateBTS / Re: Can't detect my GSM network with newest phones.

« on: December 07, 2017, 12:19:21 PM »

It is important to know the following:
- Is the bladeRF frequency (auto)calibrated?
- Are you using the 850MHz band?
- What is the PLMN (MCC+MNC) of the IMSI
- What is the PLMN broadcasted by the BTS
- Where you are located geographically

At the whim of US operators Apple (and others) have introduced restrictions about which bands are available to which networks. In some conditions the phones may not list some or all cells in a band. This depend on the hardware version, iOs version, SIM and network identity. I am not sure but it's possible that geolocation may be taken into account as well.

The GSM850 / LTE band 5 is one of the bands affected since it's supposed to be used only in North America, South Korea, China and Australia. If you're located somewhere else or not having a matching IMSI the phone may not list cells or may behave erratically.

Try using one of the worldwide GSM bands - 900 or 1800. These are unlikely to be restricted.

3

YateBTS / Re: Why Shortname of network didn't appear in network search?

« on: August 07, 2016, 11:29:01 AM »

Network name and time is not broadcasted so a new network will only appear as MCC MNC.
The network name is optionally indicated in a MMInformation at the end of a successful Location Update procedure. The phone may save it internally for later searches.

4

YateBTS / Re: bladeRF rssi issues

« on: January 13, 2015, 01:02:25 PM »

1. network not always appear in list on phone
2. even if its appear registration can take few minutes (tested on different models)

This suggests the frequency is not calibrated. Mobile networks are very sensitive to frequency, especially when signals from several base stations can be received.
https://github.com/Nuand/kalibrate-bladeRF
http://wiki.yatebts.com/index.php/Configuration_Commands#freqcorr
http://wiki.yatebts.com/index.php/Ybts.conf#.5Btransceiver.5D_Controls_how_to_start_and_operate_the_radio_transceiver

3. why RSSI level on phone never change, it always shows same value after it registered, lets say -48 db even when i'm 30 meters away

Where and when do you see this RSSI level? Does the phone you use have some field test mode?

5

YateBTS / Re: YateBTS with bladeRF x40 : no visible network

« on: December 14, 2014, 08:55:04 AM »

This looks like a YateBTS / libbladeRF / firmware / FPGA incompatibility.

The bladeRF API is unstable and has changed several times. The structure of the data buffers (controlled by FPGA) and of the control code (Cypress firmware) has also changed.

Please use libbladeRF from http://repo.yatebts.com/devel/bladeRF.tar.gz and flash the board with the firmware.img from our SVN directory mbts/TransceiverRAD1. You will need to rebuild YateBTS after installing libbladeRF so it picks the corect API.

6

Yate users hangout place / Re: CDR finalize without combiner for 'id'

« on: December 14, 2014, 07:05:51 AM »

"CDR finalize without combiner" indicates that the cdrcombine module found an outbound call for which it could not identify the corresponding inbound call.

To properly match call legs you should copy the "billid" parameter from the inbound to the outbound call leg(s).

Alternatively, if you don't care about a combined CDR you may disable the module entirely.

7

Other Yate server issues / Re: How to change SIP header fields in Yate

« on: December 01, 2014, 01:03:58 PM »

Those fields are currently hardcoded since no program it using them.

8

YateBTS / Re: YateBTS initial setup with bladeRF x115

« on: December 01, 2014, 01:01:54 PM »

...

Code: [Select]

2014-11-27_15:44:57.097372 <mbts:NOTE> OpenBTS.cpp:144:startTransceiver: starting transceiver ./transceiver-bladerf w/ 1 ARFCNs and Args:
EMERG 140160281310976 15:44:57.0 OpenBTS.cpp:150:startTransceiver: cannot find ./transceiver-bladerf
2014-11-27_15:44:57.097487 <mbts:GOON> OpenBTS.cpp:150:startTransceiver: cannot find ./transceiver-bladerf
...

Apparently the bladeRF specific transceiver was not installed or built (check existence of TransceiverRAD1/transceiver-bladerf). Perhaps the bladeRF library wasn't properly installed or wasn't detected?

Please check the config.log produced by YateBTS's ./configure to see what happened. Do you see something like the following?

Code: [Select]

configure:5518: checking for bladeRF support using pkg-config
configure:5533: result: no
configure:5551: checking libbladeRF.h usability
configure:5568: gcc -c  -O2 -DLITTLE_ENDIAN  conftest.c >&5
conftest.c:60:24: error: libbladeRF.h: No such file or directory
If so please make sure libbladeRF was properly built and its development files were installed in the proper location. Also make sure you have pkg-config installed.

9

YateBTS / Re: YateBTS and 3G dongle

« on: December 01, 2014, 12:51:58 PM »

You can use pretty much any form of IP connectivity to reach out as long as it provides reasonable quality and latency and VoIP is not blocked. If the mobile provider you get 3G from blocks VoIP you need to use some form of VPN to hide the traffic. As a minimum you may use TLS as SIP transport and hope the RTP doesn't get blocked.

For the 3G dongle to work properly you need to install it in a fixed position that gets a good signal. Depending on coverage you may need a dongle with an external antenna. take a look at our commercial SatSite product http://www.yatebts.com/sat_site.php which can also do calls over 3G (but unlike the NIB it registers subscribers in their home network HLR).

Since Yate (of which YateBTS is a module) is a complete softswitch you can just connect it to a VoIP provider for calls. You can set up routing rules for outbound and inbound traffic. See the http://wiki.yatebts.com/index.php/Network_in_a_Box and http://docs.yate.ro/wiki/Main_Page documentation.

YateBTS can be compiled on pretty much any Linux distro, the main requirement being support for building and / or installing the bladeRF library.

10

YateBTS / Re: Problem changing frequency

« on: October 23, 2014, 09:20:20 PM »

Hi!

What exact error you receive and where? Is it in the Web configuration interface?

Are you sure the error is related to the band change you make? Maybe you made a manual change in the config file which gets rejected by the validator.

I would expect changing Radio.Band to only require a matching Radio.C0 (since ARFCN coding is band specific).

Also note that you need to remove the Rx filter (we provide 850 and 900 MHz band ones) and install a 1900 band one else you'll get poor performance.

11

YateBTS / Re: GPRS Networking Basics GGSN

« on: September 06, 2014, 06:44:52 AM »

The easiest way is to change the MS.IP.Base to a different subnet than your LAN and set up a NAT for the mobile phones to access the Internet.

For DNS check if your /etc/resolv.conf is populated correctly.

12

Yate users hangout place / Re: YateBTS: How voice is send when two GSM phones are talking

« on: September 04, 2014, 06:38:29 AM »

Media streams are exchanged internally between mbts and the ybts module over an unnamed UNIX socket pair.

Even if the call is between two phones the media goes mbts -> ybts -> mbts as only the ybts module knows about routes and calls.

The NIB script does local routing for calls and connect together two ybts channels if the call is MO to MT. If the call needs to go out of the bts then it is sent out over a VoIP protocol (usually SIP). In this case the media can be intercepted as RTP.

13

YateBTS / Re: GSM scanning ?

« on: September 03, 2014, 11:44:05 PM »

Hi!

There is currently no way to perform a spectrum audit with YateBTS.

Even if such will be eventually implemented (depends on hardware capabilities) it needs to be a separate executable that will not run at the same time as the base station as it needs to perform special tuning of the radio.

14

Yate users hangout place / Re: no db query after the expires

« on: August 20, 2014, 06:55:04 AM »

Hi!

The register module expects that the UPDATE affects some rows in the database. For MySQL an identical update returns zero affected rows.

Your user.register query seems incorrect, the `expires` column in the database should hold the absolute expire time not the expire interval:

  UPDATE sip_users SET fullcontact='sip/sip:100@xx.xx.xx.xx:9388',expires='60' WHERE username='100'

For MySQL your queries should probably look like:

  [user.register]
  query=UPDATE users SET fullcontact='${data}',expires=DATE_ADD(NOW(), INTERVAL ${expires} SECOND) WHERE username='${username}'
  
  [engine.timer]
  query=UPDATE users SET fullcontact=NULL,expires=NULL WHERE expires IS NOT NULL AND expires<=NOW()

15

YateBTS / Re: Is it possible to add "cell reselection offset (CRO)" to YateBTS?

« on: August 15, 2014, 10:39:05 AM »

Starting with YateBTS Rev. 374 it is possible to work around the genuine SI13 decoding bug in Wireshark by setting in ybts.conf in:

[gprs_advanced]
Release=6

Now tshark decodes:
    Message Type: System Information Type 13
    SI 13 Rest Octets
        H... ....: SI13 contents: Present
        .011 .... = BCCH Change Mark: 3
        .... 0000 = SI Change Field: Update of unspecified SI message or SI messages (0)
        0... ....: SI13 Change Mark: Not Present
        .0.. ....: PBCCH: Not Present In Cell
        ..00 0000  11.. .... = RAC: 3
        ..0. .... = SPGC CCCH Sup: SPLIT_PG_CYCLE is not supported on CCCH in this cell
        ...1 10.. = Priority Access Thr: Packet access is allowed for priority level 1 to 4 (6)
        .... ..10 = Network Control Order: NC2 (2)
        GPRS Cell Options
            01.. .... = NMO: Network Mode of Operation II (1)
            ..10 1... = T3168: 3000 ms (5)
            .... .000 = T3192: 500 ms (0)
            111. .... = DRX Timer Max: 64 s (7)
            ...0 .... = Access Burst Type: 8-bit format shall be used
            .... 1... = Control Ack Type: Default format is RLC/MAC control block
            .... .000  1... .... = BS CV Max: 1
            .0.. ....: PAN bits: Not Present
            ..1. ....: Optional Extensions: Present
            GPRS Cell Options Extension Information
                Extension Length: 10
                ..0. .... = PFC Feature Mode: The network does not support packet flow context procedures
                ...0 .... = DTM Support: The cell does not support DTM procedures
                .... 0... = BSS Paging Coordination: The cell does not support Circuit-Switched paging coordination
                .... .0.. = CCN Active: CCN is disabled in the cell
                .... ..1. = NW Ext UTBF: The extended uplink TBF mode is supported by the network
                .... ...0 = Multiple TBF Capability: The cell does not support multiple TBF procedures
                0... .... = Ext UTBF No Data: The mobile station shall send a PACKET UPLINK DUMMY CONTROL BLOCK message when there is no other RLC/MAC block ready to send in an uplink radio block allocated by the network
                .0.. .... = DTM Enhancements Capability: The cell does not support enhanced DTM CS establishment and enhanced DTM CS release procedures
                ..0. ....: MBMS procedures: Not supported by cell
                ...0 .... = Reduced Latency Access: The cell does not support "One Phase Access Request by Reduced Latency MS"
            .0.. ....: EGPRS: Not supported by cell
        GPRS Power Control Parameters
            .... 0101 = Alpha: 0.5 (5)
            0111 1... = T Avg W: 2^(15/2) / 6 multiframes (15)
            .... .011  11.. .... = T Avg T: 2^(15/2) / 6 multiframes (15)
            ..0. .... = PC Meas Chan: Downlink measurements for power control shall be made on BCCH
            ...1 111. = N Avg I: 2^(15/2) (15)
        .... ...L: Additions in R99: Not present
        Padding Bits: Unknown extension detected or malformed PDU (Not decoded)