pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/docker-playground/+/36951?usp=email )
Change subject: asterisk: pjsip.conf: Disable remote bridging between local SIP and IMS
......................................................................
asterisk: pjsip.conf: Disable remote bridging between local SIP and IMS
While implementing a first ttcn3 test validating the MO call scenario
(SIP-UA -> Asterisk -> IMS-CORE) [1] I was running into the scenario where,
after the first SIP INVITE + 200 OK + ACK, Asterisk was sending a RE-INVITE
to both parties to attempt to remotely bridge them (RTP traffic flowing
directly between them without passing through Asterisk).
This happened in part because I'm so far configure A-LAW on both sides so
asterisk figures out it can do so. I still need to change IMS-core to EVS only.
In any case, regardless of the codecs used, my understanding is that asterisk
should never attempt remote bridging when using the "volte_ims" endpoint, since
that network segment is separate from the local network where the local SIP UAs
are located.
The "direct_media=no" option just addresses the issue; Asterisk no longer tries
to re-invite after the call is established
Related: SYS#6782
Change-Id: I4edea96151b31f02bf292b43b757922389375429
---
M ttcn3-asterisk-ims-ue-test/asterisk/pjsip.conf
1 file changed, 28 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/docker-playground refs/changes/51/36951/1
diff --git a/ttcn3-asterisk-ims-ue-test/asterisk/pjsip.conf b/ttcn3-asterisk-ims-ue-test/asterisk/pjsip.conf
index 9400780..9ca85e5 100644
--- a/ttcn3-asterisk-ims-ue-test/asterisk/pjsip.conf
+++ b/ttcn3-asterisk-ims-ue-test/asterisk/pjsip.conf
@@ -106,6 +106,7 @@
rewrite_contact=yes
from_user=238010000090828
from_domain=172.18.11.103
+direct_media=no
[volte_ims]
type=auth
--
To view, visit https://gerrit.osmocom.org/c/docker-playground/+/36951?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: docker-playground
Gerrit-Branch: master
Gerrit-Change-Id: I4edea96151b31f02bf292b43b757922389375429
Gerrit-Change-Number: 36951
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: neels, nt2mku.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36784?usp=email )
Change subject: gsm48_encode_bearer_cap(): omit octet 3a if only GSM-FR/GSM-HR v1 is supported
......................................................................
Patch Set 10:
(1 comment)
Patchset:
PS10:
This patch is now pedantically correct: it does what it says, follows Osmocom coding style, and produces encoded output that follows the 3GPP spec. However, I am still unsure if it should be merged, or if we should pursue a different solution. If we merge this patch as-is, we will lose the ability to send intentionally invalid speech version lists, and thereby lose the ability to make discoveries like the one made by @vyanitskiy@sysmocom.de in Russia last year.
Background: in 2023-09 Vadim discovered (using osmocom-bb as his test instrument) that Russian MNO Tele2 will issue a connection using HRv1 codec (yes, that's right) *only if* the MS transmits a certain carefully crafted spec-invalid speech version list in its bearer cap IE. Per ETSI and 3GPP specs, every MS *must* support FRv1 at the very least, hence a bearer cap IE that says (via any encoding) that "I don't support FRv1" is spec-invalid. When octet 3a is omitted, there is no possible coding that produces this spec-invalid meaning - but if you do include octet 3a, you can produce this oddity by sending a speech version list that omits FRv1 and only includes HRv1, or only HRv1 and AMR-HR as in Vadim's other experiment on that MNO (which resulted in AHS being issued). It is my understanding that Vadim produced those spec-invalid SV lists using osmocom-bb without even realizing at the time that they were spec-invalid.
Also irrespective of whether octets 3a etc are included or omitted, every correct MS (outside of experiments where you send intentionally invalid stuff) must set the RRQ bits correctly based on its speech version support. Contrary to common misunderstanding, those bcap->radio bits are *not* there to say in an abstract, codec-independent manner whether the MS supports TCH/H, or which rate it prefers - instead it is there to tell ancient networks (those that predate the addition of octet 3a) whether the MS supports HRv1 or if it is FRv1-only, and if HRv1 is supported, which is preferred. Referring to the same spec PDF version which Vadim cited earlier, please look at logical page 558 (PDF physical page 559), and scrutinize the table at the very bottom of the page (the case with octets 3a etc included) and the table just above it (the case with octet 3a omitted). These two tables make it clear that the two RRQ bits need to be set based *solely* on whether or not the MS supports HRv1, and where HRv1 stands *relative to FRv1* in the order of preference, without any regard for TCH/F or TCH/H support or preference with newer codecs! This logic does not currently exist in gsm48_encode_bearer_cap(), and this functions does not look like the right place for it.
My proposal: we leave gsm48_encode_bearer_cap() as it is (don't merge the present patch), but create a wrapper (or preprocessor) function to be called (optionally) just before this encoding function, and have this preener function do the following:
* Enforce that FRv1 appears in the provided speech version list, returning an error otherwise;
* Compute spec-compliant RRQ bits from the provided speech version list;
* Replace the SV list with an empty one (-1 in speech_ver[0]) if only FRv1/HRv1 are supported, and this support has now been encoded in the RRQ bits.
I can produce a patch implementing this preener function *if* others agree with the general principle outlined above.
P.S. I apologize for not making this thought-out proposal earlier - but my volunteer time isn't infinite, and my previous replies here were somewhat rushed.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36784?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Ia09abb32a8458384151a6ae28744835ea440fc5b
Gerrit-Change-Number: 36784
Gerrit-PatchSet: 10
Gerrit-Owner: nt2mku <degrunert.web(a)googlemail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-CC: falconia <falcon(a)freecalypso.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: nt2mku <degrunert.web(a)googlemail.com>
Gerrit-Comment-Date: Wed, 29 May 2024 18:46:05 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: laforge.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36949?usp=email )
Change subject: asterisk: Allow passing full templates to {tr,ts}_SIP_msgh_std
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
I validated that both Asterisk_tests and SIP_Tests still pass with this one applied.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36949?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I3a85701822d7b76ec078b1a7c615e5ef50f36902
Gerrit-Change-Number: 36949
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 29 May 2024 17:34:21 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36948?usp=email )
Change subject: asterisk: AMI_Functions: Fix decoding of empty AccountID field
......................................................................
asterisk: AMI_Functions: Fix decoding of empty AccountID field
While at it, convert the code to a loop since we start to have a bunch
of fields to check.
Change-Id: Ifc0e84a81b24d8ce8194b769a8ff9a0d4f3e85ff
---
M asterisk/AMI_Functions.ttcn
1 file changed, 17 insertions(+), 7 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/48/36948/1
diff --git a/asterisk/AMI_Functions.ttcn b/asterisk/AMI_Functions.ttcn
index a82af97..9c84d00 100644
--- a/asterisk/AMI_Functions.ttcn
+++ b/asterisk/AMI_Functions.ttcn
@@ -419,13 +419,11 @@
private function dec_AMI_Msg_ext(charstring txt) return AMI_Msg {
log("AMI dec: '", txt, "'");
/* TEXT Enc/dec is not happy with empty values, workaround it: */
- var charstring patched_txt := f_str_replace(txt, "Challenge: \r\n", "");
- patched_txt := f_str_replace(patched_txt, "AccountCode: \r\n", "");
- patched_txt := f_str_replace(patched_txt, "Value: \r\n", "");
- patched_txt := f_str_replace(patched_txt, "DestExten: \r\n", "");
- patched_txt := f_str_replace(patched_txt, "Exten: \r\n", "");
- patched_txt := f_str_replace(patched_txt, "Extension: \r\n", "");
- patched_txt := f_str_replace(patched_txt, "Hint: \r\n", "");
+ var Misc_Helpers.ro_charstring fields := { "AccountCode", "AccountID", "Challenge", "DestExten", "Exten", "Extension", "Hint", "Value" };
+ var charstring patched_txt := txt;
+ for (var integer i := 0; i < lengthof(fields); i := i +1) {
+ patched_txt := f_str_replace(patched_txt, fields[i] & ": \r\n", "");
+ }
/* "AppData" field sometimes has a value containing separator ": ", which makes
* TEXT dec not happy. Workaround it for now by removing the whole field line:
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36948?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Ifc0e84a81b24d8ce8194b769a8ff9a0d4f3e85ff
Gerrit-Change-Number: 36948
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: fixeria, laforge, neels.
osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36772?usp=email )
Change subject: msc: add TC_gsup_mt_sms_lu_delay for X36 (LU delay) timer
......................................................................
Patch Set 4:
(1 comment)
File msc/MSC_Tests.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36772/comment/63d03748_36ea…
PS4, Line 3325: mtc.stop;
Why mtc.stop here? I'm not 100% sure, but as I understand this means the commands to reset VTY configuration in TC_gsup_mt_sms_lu_delay() will then not get executed in this code path.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36772?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I74fa174ea649adb2112c8e471c0e339a2197a08d
Gerrit-Change-Number: 36772
Gerrit-PatchSet: 4
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 29 May 2024 13:53:36 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment