Attention is currently required from: fixeria, laforge, pespin.
jolly has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/34492?usp=email )
Change subject: ASCI: Add group receive and transmit mode support to MM layer
......................................................................
Patch Set 12:
(1 comment)
File src/host/layer23/src/mobile/gsm48_mm.c:
https://gerrit.osmocom.org/c/osmocom-bb/+/34492/comment/058305d5_3478639a
PS10, Line 4854: // There are event handlers for group call in this implementation.
> not sure what do you mean with this.
Oops, I missed some words. I rephrased it.
--
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/34492?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: I05957182a57423ad947ab200b52f65fde859e110
Gerrit-Change-Number: 34492
Gerrit-PatchSet: 12
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 28 Sep 2023 11:52:43 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
osmith has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/34559?usp=email )
Change subject: CC: don't start guard timer on mid-call MNCC messages
......................................................................
CC: don't start guard timer on mid-call MNCC messages
The intent of the guard timer is to clear hung or stuck states
during call setup or teardown. However, there are some MNCC
messages that will be exchanged between OsmoMSC (passing CC
messages to and from the MS) and the external MNCC agent during
the active call state, not related to setup or teardown: DTMF
start and stop, plus call hold and retrieve operations for call
waiting. Unpatched OsmoMSC restarts the guard timer on every
received MNCC message, even those that pass through to CC without
affecting any state, and the result is breakage for users.
Consider the case of an IVR where you have to press some DTMF keys
before you can be transferred to a human operator. You press the
needed keys, get the human operator, and start talking. Then
3 minutes into your conversion (default guard timer duration)
your call unceremoniously disconnects without any warning.
Fix: look at the MNCC message type, and skip the call to start
the guard timer for known-benign MNCC messages.
Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa
---
M src/libmsc/gsm_04_08_cc.c
1 file changed, 49 insertions(+), 1 deletion(-)
Approvals:
Jenkins Builder: Verified
diff --git a/src/libmsc/gsm_04_08_cc.c b/src/libmsc/gsm_04_08_cc.c
index 6148bbd..1e2c5af 100644
--- a/src/libmsc/gsm_04_08_cc.c
+++ b/src/libmsc/gsm_04_08_cc.c
@@ -2383,7 +2383,27 @@
log_mncc_rx_tx(trans, "rx", msg);
- gsm48_start_guard_timer(trans);
+ /*
+ * The step of gsm48_start_guard_timer() needs to be done for
+ * major state-impacting MNCC messages, but not for those
+ * that are a mere pass-through to CC messages to MS.
+ */
+ switch (msg->msg_type) {
+ case MNCC_PROGRESS_REQ:
+ case MNCC_NOTIFY_REQ:
+ case MNCC_FACILITY_REQ:
+ case MNCC_START_DTMF_RSP:
+ case MNCC_START_DTMF_REJ:
+ case MNCC_STOP_DTMF_RSP:
+ case MNCC_HOLD_CNF:
+ case MNCC_HOLD_REJ:
+ case MNCC_RETRIEVE_CNF:
+ case MNCC_RETRIEVE_REJ:
+ case MNCC_USERINFO_REQ:
+ break;
+ default:
+ gsm48_start_guard_timer(trans);
+ }
trans->cc.mncc_initiated = true;
if (trans->msc_a)
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34559?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: osmith/1.11.1
Gerrit-Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa
Gerrit-Change-Number: 34559
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: falconia <falcon(a)freecalypso.org>
Gerrit-MessageType: merged
osmith has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/34557?usp=email )
Change subject: fix codecs in internal call bridge
......................................................................
fix codecs in internal call bridge
This is a fixup for the patch
'3G: decapsulate IuUP to AMR at the MGW; allow 3G<-AMR->2G'
I386a6a426c318040b019ab5541689c67e94672a1
After above patch, osmo-msc intelligently decides which codecs to run on
which legs of the RTP streams. In the meantime, it seems the necessary
matching changes to call_leg_local_bridge() had been lost somehow.
Testing 3G to 3G voice now, I noticed that call_leg_local_bridge()
overwrites the intelligent choices made earlier.
The history of an MGW endpoint that should convert from IUFP to plain
AMR, extracted from a pcap, looks like this:
<- CRCX None None
-> CRCX-OK audio 4050 RTP/AVP 112 None
<- MDCX audio 4056 RTP/AVP 112 AMR
-> MDCX-OK audio 4050 RTP/AVP 112 AMR
<- MDCX audio 4056 RTP/AVP 96 VND.3GPP.IUFP
-> MDCX-OK audio 4050 RTP/AVP 96 VND.3GPP.IUFP
So after call_leg_local_bridge(), there is an extra MDCX + MDCX-OK that
switches the codec from 112 AMR back to 96 IUFP.
That is because call_leg_local_bridge() copies the *RAN* side's codec to
both CN sides, which used to be ok when RAN and CN codecs were always
identical.
Instead, adjust only the CN sides of the MGW endpoints, and adjust them
so that both CN sides are identical. osmo-mgw should then be able to
trivially translate the codecs appropriately.
Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d
---
M src/libmsc/call_leg.c
1 file changed, 73 insertions(+), 11 deletions(-)
Approvals:
Jenkins Builder: Verified
diff --git a/src/libmsc/call_leg.c b/src/libmsc/call_leg.c
index d0dc642..b797322 100644
--- a/src/libmsc/call_leg.c
+++ b/src/libmsc/call_leg.c
@@ -352,25 +352,46 @@
int call_leg_local_bridge(struct call_leg *cl1, uint32_t call_id1, struct gsm_trans *trans1,
struct call_leg *cl2, uint32_t call_id2, struct gsm_trans *trans2)
{
- struct sdp_audio_codecs *codecs;
+ struct sdp_audio_codecs *cn_codecs = NULL;
cl1->local_bridge = cl2;
cl2->local_bridge = cl1;
- /* We may just copy the codec info we have for the RAN side of the first leg to the CN side of both legs. This
- * also means that if both legs use different codecs the MGW must perform transcoding on the second leg. */
- if (!cl1->rtp[RTP_TO_RAN] || !cl1->rtp[RTP_TO_RAN]->codecs_known) {
- LOG_CALL_LEG(cl1, LOGL_ERROR, "RAN-side RTP stream codec is not known, not ready for bridging\n");
+ /* Marry the two CN sides of the call legs. Call establishment should have made all efforts for these to be
+ * compatible. However, for local bridging, the codecs and payload type numbers must be exactly identical on
+ * both sides. Both sides may so far have different payload type numbers or slightly differing codecs, but it
+ * will only work when the SDP on the RTP_TO_CN sides of the call legs talk the same payload type numbers.
+ * So, simply take the SDP from one RTP_TO_CN side, and overwrite the other RTP_TO_CN side's SDP with it.
+ * If all goes to plan, the codecs will be identical, or possibly the MGW will do a conversion like AMR-BE to
+ * AMR-OA. In the worst case, the other call leg cannot transcode, and the call fails -- because codec
+ * negotiation did not do a good enough job.
+ *
+ * Copy one call leg's CN config to the other:
+ *
+ * call leg 1 call leg 2
+ * ---MGW-ep------- ---MGW-ep-------
+ * RAN CN CN RAN
+ * AMR:112 AMR:112 AMR:96 AMR:96
+ * |
+ * +-------+
+ * |
+ * V
+ * AMR:112 AMR:112 AMR:112 AMR:96
+ * ^MGW-endpoint converts payload type numbers between 112 and 96.
+ */
+ if (cl1->rtp[RTP_TO_CN] && cl1->rtp[RTP_TO_CN]->codecs_known)
+ cn_codecs = &cl1->rtp[RTP_TO_CN]->codecs;
+ else if (cl2->rtp[RTP_TO_CN] && cl2->rtp[RTP_TO_CN]->codecs_known)
+ cn_codecs = &cl2->rtp[RTP_TO_CN]->codecs;
+ if (!cn_codecs) {
+ LOG_CALL_LEG(cl1, LOGL_ERROR, "RAN-side CN stream codec is not known, not ready for bridging\n");
+ LOG_CALL_LEG(cl2, LOGL_ERROR, "RAN-side CN stream codec is not known, not ready for bridging\n");
return -EINVAL;
}
- codecs = &cl1->rtp[RTP_TO_RAN]->codecs;
-
- if (!cl1->rtp[RTP_TO_CN] || !cl2->rtp[RTP_TO_CN])
- return -ENOTCONN;
call_leg_ensure_ci(cl1, RTP_TO_CN, call_id1, trans1,
- codecs, &cl2->rtp[RTP_TO_CN]->local);
+ cn_codecs, &cl2->rtp[RTP_TO_CN]->local);
call_leg_ensure_ci(cl2, RTP_TO_CN, call_id2, trans2,
- codecs, &cl1->rtp[RTP_TO_CN]->local);
+ cn_codecs, &cl1->rtp[RTP_TO_CN]->local);
return 0;
}
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34557?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: osmith/1.11.1
Gerrit-Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d
Gerrit-Change-Number: 34557
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-MessageType: merged
osmith has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/34561?usp=email )
Change subject: gsup_client_mux: set destination_name in error reply function
......................................................................
gsup_client_mux: set destination_name in error reply function
If the GSUP request message to which we are replying is an MT SMS
delivery from an SMSC relayed via OsmoHLR, we must set destination_name
in our reply - otherwise our reply won't make it back to the SMSC.
Related: OS#6135
Change-Id: I892fe87a733a78ed9d5761a8ce238caa135dea1e
---
M src/libmsc/gsup_client_mux.c
1 file changed, 16 insertions(+), 0 deletions(-)
Approvals:
Jenkins Builder: Verified
diff --git a/src/libmsc/gsup_client_mux.c b/src/libmsc/gsup_client_mux.c
index 1900377..9a0dc16 100644
--- a/src/libmsc/gsup_client_mux.c
+++ b/src/libmsc/gsup_client_mux.c
@@ -150,6 +150,8 @@
.cause = cause,
.message_type = OSMO_GSUP_TO_MSGT_ERROR(gsup_orig->message_type),
.message_class = gsup_orig->message_class,
+ .destination_name = gsup_orig->source_name,
+ .destination_name_len = gsup_orig->source_name_len,
/* RP-Message-Reference is mandatory for SM Service */
.sm_rp_mr = gsup_orig->sm_rp_mr,
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34561?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: osmith/1.11.1
Gerrit-Change-Id: I892fe87a733a78ed9d5761a8ce238caa135dea1e
Gerrit-Change-Number: 34561
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: falconia <falcon(a)freecalypso.org>
Gerrit-MessageType: merged