aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPau Espin Pedrol <pespin@sysmocom.de>2021-07-08 12:54:06 +0200
committerpespin <pespin@sysmocom.de>2021-07-09 11:32:40 +0000
commit25ea643e19c2d95bec07e3ac783c2864afbf350c (patch)
tree4d7cdc0970e2668fc09f373741199f2d40705f62
parentfd3204e0de381b5c8aa9cc25942961d6b4313dd4 (diff)
lchan_fsm: Improve timeout logging line in state WAIT_RLL_RTP_ESTABLISH
This allows quickly finding out whether the timeout is happening due to RLL not established or whether RTP is not ready. In essence, it indicates whether issue may be coming from MGW or from MS/BTS side. If coming from MGW, the timer T3101 is in general not a problem and the issue should be related to some misbehaving. If coming from MS/BTS, T3101 may require tunning (it could be a misbehaving of the MS/BTS too, or simply bad signal). Related: SYS#5526 Change-Id: Ib655f71aec584962c70d84a4405d996505dff53c
-rw-r--r--src/osmo-bsc/lchan_fsm.c9
1 files changed, 8 insertions, 1 deletions
diff --git a/src/osmo-bsc/lchan_fsm.c b/src/osmo-bsc/lchan_fsm.c
index e3b6c837c..841415fdd 100644
--- a/src/osmo-bsc/lchan_fsm.c
+++ b/src/osmo-bsc/lchan_fsm.c
@@ -1712,7 +1712,14 @@ static int lchan_fsm_timer_cb(struct osmo_fsm_inst *fi)
lchan->release.in_error = true;
lchan->release.rsl_error_cause = RSL_ERR_INTERWORKING;
lchan->release.rr_cause = bsc_gsm48_rr_cause_from_rsl_cause(lchan->release.rsl_error_cause);
- lchan_fail("Timeout");
+ if (fi->state == LCHAN_ST_WAIT_RLL_RTP_ESTABLISH) {
+ lchan_fail("Timeout (rll_ready=%s,voice_require=%s,voice_ready=%s)",
+ (lchan->sapis[0] != LCHAN_SAPI_UNUSED) ? "yes" : "no",
+ lchan->activate.info.requires_voice_stream ? "yes" : "no",
+ lchan_rtp_established(lchan) ? "yes" : "no");
+ } else {
+ lchan_fail("Timeout");
+ }
return 0;
}
}