Hi,
I am setting up openbsc with LCR and Asterisk to provide external
connectivity for the GSM clients, and I encountered and interesting
problem.
If the GSM phone initiates a voice call towards a SIP phone it works
perfectly, the voice goes both ways, the quality is OK, everything is
fine.
But when the SIP phones initiates a voice call towards the GSM phone,
only the SIP phone can hear the voice of the GSM phone, and not the
other way around (half sided call). The connection setup works both
ways just fine.
The GSM and the SIP phone can also call the asterisk test numbers, and even can do
echo test just fine. The two GSM phones can call each other too
without any problem.
Does somebody has any idea what could go wrong?
Config:
E1 based Nokia BTS with DAHDI card and TCH/F FR codec.
The SIP phone uses Alaw, LCR also set to use Alaw.
The LCR is bridged to Asterisk, interface.conf:
[GSM]
gsm-bs
tones yes
earlyb no
bridge ast
[ast]
remote asterisk
context from-lcr
earlyb no
tones yes
bridge GSM
routing.conf is completely empty.
Astrisk SIP.conf:
[general]
context=incoming
disallow=all
allow=alaw
allow=ulaw
allow=gsm
transport=udp
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
tlsenable=no
tlsbindaddr=0.0.0.0
[5010]
type=friend
username=5010
secret=123456
dtmfmode=rfc2833
callerid="5010" <5010>
host=dynamic
canreinvite=no
context=myphones
Asterisk extensions.conf
[general]
static=yes
writeprotect=no
clearglobalvars=no
[globals]
; Global variables goes here
[incoming]
; Nothing should land here yet, but every context should end in
; a Hangup(), so we do that.
exten => s,1,Hangup()
[myphones]
; When we dial something from the phones we just added in
; sip.conf, Asterisk will look for a matching extension here,
; in this context.
; SIP phone
exten => 5010,1,Dial(SIP/5010)
exten => 5010,n,Hangup()
; Another SIp phone
;exten => 1001,1,Dial(SIP/1001)
;exten => 1001,n,Hangup()
; GSM phone 1
exten => 12346,1,Dial(LCR/ast/${EXTEN:0},60)
exten => 12346,n,Hangup()
; GSM phone 2
exten => 12345,1,Dial(LCR/ast/${EXTEN:0},60)
exten => 12345,n,Hangup()
; Testing extension
exten => 201,1,Answer()
exten => 201,n,Playback(levan_polka.mp3)
exten => 201,n,Hangup()
; Echo-test, it is good to test if we have sound in both directions.
; The call is answered
exten => 202,1,Answer()
; Welcome message is played
exten => 202,n,Playback(dir-welcome)
; Play information about the echo test
exten => 202,n,Playback(demo-echotest)
; Do the echo test, end with the # key
exten => 202,n,Echo()
; Plays information that the echo test is done
exten => 202,n,Playback(demo-echodone)
; Goodbye message is played
exten => 202,n,Playback(vm-goodbye)
; Hangup() ends the call, hangs up the line
exten => 202,n,Hangup()
[from-lcr]
include => myphones
exten => _X.,1,Dial(LCR/ast/${EXTEN:0},60)
exten => 5010,1,Dial(SIP/5010)
exten => 5010,n,Hangup()
BR,
Csaba
here a small patch for a bug which prevent phones to register.
more info is available in the patch
note: the same mistake may exist at other places. I only looked at how the users are read
kevin
Currently uninitialized elements of the femtobts_sysprim_type array
are mistaken as L1P_T_REQ (which is accidently the first element and
thus 0).
This patch adds a new element to the enum that has the value 0 to
detect uninitialized elements of the femtobts_sysprim_type array.
Those will then show up in the log as 'SYS Prim XXX is not a
Request!'.
This patch also adds missing definitions of the CalibTbl messages
in the femtobts_sysprim_type mapping so that the requests can still
be identified as such.
Sponsored-by: On-Waves ehf
---
src/osmo-bts-sysmo/femtobts.c | 10 ++++++++++
src/osmo-bts-sysmo/femtobts.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/src/osmo-bts-sysmo/femtobts.c b/src/osmo-bts-sysmo/femtobts.c
index 6bd9ce4..1e513bf 100644
--- a/src/osmo-bts-sysmo/femtobts.c
+++ b/src/osmo-bts-sysmo/femtobts.c
@@ -106,6 +106,16 @@ const enum l1prim_type femtobts_sysprim_type[SuperFemto_PrimId_NUM] = {
[SuperFemto_PrimId_RfClockSetupCnf] = L1P_T_CONF,
[SuperFemto_PrimId_Layer1ResetReq] = L1P_T_REQ,
[SuperFemto_PrimId_Layer1ResetCnf] = L1P_T_CONF,
+#if SUPERFEMTO_API_VERSION >= SUPERFEMTO_API(2,1,0)
+ [SuperFemto_PrimId_GetTxCalibTblReq] = L1P_T_REQ,
+ [SuperFemto_PrimId_GetTxCalibTblCnf] = L1P_T_CONF,
+ [SuperFemto_PrimId_SetTxCalibTblReq] = L1P_T_REQ,
+ [SuperFemto_PrimId_SetTxCalibTblCnf] = L1P_T_CONF,
+ [SuperFemto_PrimId_GetRxCalibTblReq] = L1P_T_REQ,
+ [SuperFemto_PrimId_GetRxCalibTblCnf] = L1P_T_CONF,
+ [SuperFemto_PrimId_SetRxCalibTblReq] = L1P_T_REQ,
+ [SuperFemto_PrimId_SetRxCalibTblCnf] = L1P_T_CONF,
+#endif
};
const struct value_string femtobts_sysprim_names[SuperFemto_PrimId_NUM+1] = {
diff --git a/src/osmo-bts-sysmo/femtobts.h b/src/osmo-bts-sysmo/femtobts.h
index 7239757..a2b8dea 100644
--- a/src/osmo-bts-sysmo/femtobts.h
+++ b/src/osmo-bts-sysmo/femtobts.h
@@ -44,6 +44,7 @@
(OSMO_MAX(sizeof(SuperFemto_Prim_t), sizeof(GsmL1_Prim_t)) + 128)
enum l1prim_type {
+ L1P_T_INVALID, /* this must be 0 to detect uninitialized elements */
L1P_T_REQ,
L1P_T_CONF,
L1P_T_IND,
--
1.7.9.5
I am more and more sure that the my failing handover situation has a
deeper root cause and it is not actually the handover which is
failing, but there should be a channel allocation problem. And there
it is.
The following log is made during the send of an SMS to the mobile from
the BSC CLI:
Tue Oct 29 15:06:15 2013 <001e> sms_queue.c:220 Attempting to send 20 SMS
Tue Oct 29 15:06:15 2013 <0000> chan_alloc.c:457 (bts=0,trx=0,ts=0,ss=1) starting release sequence
Tue Oct 29 15:06:15 2013 <0000> abis_rsl.c:892 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1)
Tue Oct 29 15:06:15 2013 <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 1 Type: 1
Tue Oct 29 15:06:15 2013 <0004> abis_rsl.c:634 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
Tue Oct 29 15:06:15 2013 <0004> abis_rsl.c:1070 (bts=0,trx=0,ts=0,ss=1): MEAS RES for inactive channel
Tue Oct 29 15:06:15 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:06:15 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:06:15 2013 <0000> abis_rsl.c:1657 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION
Tue Oct 29 15:06:15 2013 <0004> abis_rsl.c:1628 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=3 to be released.
Tue Oct 29 15:06:21 2013 <0000> abis_rsl.c:1657 (bts=0,trx=0,ts=0,ss=1) SAPI=3 Tue Oct 29 15:06:21 2013 <0000> abis_rsl.c:1599 (bts=0,trx=0,ts=0,ss=1) ERROR INDICATION cause=Timer T200 expired (N200+1) times
Tue Oct 29 15:06:21 2013 <0004> abis_rsl.c:680 (bts=0,trx=0,ts=0,ss=1) RF Channel Release CMD due error 1
Tue Oct 29 15:06:21 2013 <0004> abis_rsl.c:634 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
Tue Oct 29 15:06:21 2013 <0000> abis_rsl.c:892 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1)
Tue Oct 29 15:06:21 2013 <0004> abis_rsl.c:732 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK
Tue Oct 29 15:06:23 2013 <0004> abis_rsl.c:649 (bts=0,trx=0,ts=0,ss=1) is back in operation.
As you can see, although SAPI=3 was requested to be release, we never
got any RELEASE INDICATION for that. And after some time, the radio
link will be disconnected with T200 timeout.
I tried to send another SMS the same way like above, and get a more
interesting log:
Tue Oct 29 15:54:45 2013 <001e> sms_queue.c:220 Attempting to send 20 SMS
Tue Oct 29 15:54:46 2013 <0000> chan_alloc.c:457 (bts=0,trx=0,ts=0,ss=1) starting release sequence
Tue Oct 29 15:54:46 2013 <0000> abis_rsl.c:892 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1)
Tue Oct 29 15:54:46 2013 <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 1 Type: 1
Tue Oct 29 15:54:46 2013 <0004> abis_rsl.c:634 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
Tue Oct 29 15:54:46 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:54:46 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:54:46 2013 <0004> abis_rsl.c:1070 (bts=0,trx=0,ts=0,ss=1): MEAS RES for inactive channel
Tue Oct 29 15:54:46 2013 <0000> abis_rsl.c:1657 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION
Tue Oct 29 15:54:46 2013 <0004> abis_rsl.c:1628 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=3 to be released.
...
Tue Oct 29 16:00:46 2013 <0004> abis_rsl.c:1467 (bts=0,trx=0,ts=0,ss=2) Activating ARFCN(885) SS(2) lctype SDCCH r=LOCATION_UPDATE ra=0x08 ta=0
Tue Oct 29 16:00:46 2013 <0004> abis_rsl.c:1169 (bts=0,trx=0,ts=0,ss=2) CHANNEL ACTIVATE ACK
As you can see, SAPI=3 again not getting released properly, but this
time there is not even a T200 timeout and the SACCH channel got stuck,
never released. The last two line is the periodic LA update, and you can see
that it uses ss=2, because the BSC thinks that ss=1 is still in use.
This is the very same issue I noticed with the handover:
[0;mFri Jul 26 12:45:29 2013 <000c> handover_decision.c:203 (bts=0,trx=0,ts=2): Cell on ARFCN 123 is better: [0;mFri Jul 26 12:45:29 2013 <000c> handover_logic.c:96 (old_lchan on BTS 0, new BTS 1)
[0;mStarting handover
[0;m[1;35mFri Jul 26 12:45:29 2013 <0004> abis_rsl.c:1165 (bts=1,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
[0;mFri Jul 26 12:45:29 2013 <000c> handover_logic.c:204 handover activate ack, send HO Command
[0;m[1;35mFri Jul 26 12:45:29 2013 <0004> abis_rsl.c:1138 (bts=1,trx=0,ts=2,ss=0) HANDOVER DETECT [0;m[1;35maccess delay = 0
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 [0;m[1;31mESTABLISH INDICATION
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 [0;m[1;31mDATA INDICATION
[0;m[1;34mFri Jul 26 12:45:29 2013 <0003> bsc_api.c:515 HANDOVER COMPLETE cause = Normal event
[0;mFri Jul 26 12:45:29 2013 <000c> handover_logic.c:261 Subscriber 244153333330126 HO from BTS 0->1 on ARFCN 885->123
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> chan_alloc.c:405 (bts=0,trx=0,ts=2,ss=0) starting release sequence
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x00, reason=1)
[0;m[1;35mFri Jul 26 12:45:29 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:30 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:30 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
......
[0;m[1;35mFri Jul 26 12:45:40 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:42 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:43 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:988 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING [0;m[1;35mCAUSE=0x01(Radio Link Failure) [0;m[1;35m
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:679 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:633 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
[0;m[1;31mFri Jul 26 12:45:44 2013 <0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x40, reason=1)
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:731 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
[0;m[1;35mFri Jul 26 12:45:46 2013 <0004> abis_rsl.c:648 (bts=0,trx=0,ts=2,ss=0) is back in operation.
As you can see, from the BSC point of view the handover was
successful, but it was not able to release the old channel, we never
got any RELEASE INDICATION. This is why we get the Radio Link Failure
eventually, because the phone is not there anymore, but the channel
yet not closed. Because the release of the old channel is not
successful, OpenBSC never tries to remap the TRAU to the new channel,
therefore both phones got disconnected (properly).
This is as far as I can get with this problem. Maybe now that I
narrowed down the root cause, someone can help me with it.
I still think this problem is not Nokia specific, maybe other BTSes
are affected (BS11 or other E1 based units).
Csaba
Hi Caleb,
The segfault is introduced with this patch:
http://cgit.osmocom.org/libosmocore/commit/?id=f5a079f739c57d8be7c59149fd45…
Is is not really a bugfix, but if you just comment out the following
part from lapd_core.c added by the above patch and recompile openbsc, it will help:
dl->tx_hist = NULL;
The problem is probably related to the RESET function, because Nokia
units are being reset during the initialization phase, and
bootstrapped after that. The reason for this is if this reset is not
concluded, then the BTS will not apply certain configuration parameters
(e.g. change in ARFCN, transmit power, timeslot configuration).
I strongly suggest you anyway, to start with TCF/F FR configuration,
and if you see major alarm "BCF operation degraded: difference between
PCM and BTS clock", it means that your E1 card is not able to provide
accurate enough timing for the BTS. According to Nokia, you need +-5Hz
accuracy on the E1 to meet the timing requirements, but even then at
least 20-25 minutes of operation is needed for the BTS clock to be
synced and the alarm goes away. Usually DAHDI or other E1 cards clock
are not precise enough but don't worry: even with the alarm you can
make pretty good quality phone calls, but remember: if you experience
severe call quality degradation, or the phones cannot camp, or they
loosing the network all the time, it is going to be a timing related
problem. Anyway, do you have the Nokia InSite manager software? If not
just write me a mail and I can help with that. You definitely going to
need that and an LMP cable to do the initial setup, before you can get
started with OpenBSC.
BR,
Csaba