18 Jul
2023
18 Jul
'23
7:43 p.m.
Dear list,
I managed to set up my E1 based Nokia BTS, the complete Osmo-CNI
stack, SIP-connector and Asterisk. MO/MT calls do work as well as
external SIP calls to and from mobile as well. But no matter what I do
only plain FullRate calls are possible.
Under osmo-bsc.conf code support is set like this (the BTS HW do
support all of these codecs):
codec-support fr efr amr
but once I also add "codec-list fr3 fr2 fr1" to the MSC section of the
osmo-bsc.conf, the calls wont establish anymore.
I watched Neel's OsmoDevCall presentation on this topic, but it is not
very clear what codecs are supported when osmo-sip-connector and an
external PBX is used?
Regards,
Csaba
19 Jul
19 Jul
10:05 a.m.
On 18/07/2023 11:43, Sipos Csaba wrote:
Dear list,
Hi.
I watched Neel's OsmoDevCall presentation on this topic, but it is not
very clear what codecs are supported when osmo-sip-connector and an
external PBX is used?
The question is somewhat out of scope for this list. The answer to what
codecs are supported with an external PBX is it totally depends on the
external PBX.
run sngrep on the interface carrying the SIP between your PBX and
osmo-sip-connector and take note of how your PBX is responding to the
INVITE.
If the external PBX is supporting AMR, at least in pass through mode,
that should be all you need for a mobile to mobile call. For "external"
SIP calls, well it totally depends on what your external SIP EP is
supporting and so therefore whether or not your PBX needs to do
transcoding, and if it does, then you need that capability, (obviously),
and I would tend very strongly to assume you don't have that
out-of-the-box with Asterisk.
k/
23 Jul
23 Jul
4:13 a.m.
Hi Csaba,
I managed to set up my E1 based Nokia BTS, the
complete Osmo-CNI
stack, SIP-connector and Asterisk. MO/MT calls do work as well as
external SIP calls to and from mobile as well. But no matter what I do
only plain FullRate calls are possible.
What version of Osmocom CNI software are you using: 2023-02 stable
release or current master? The distinction is a big one: shortly
after the 2023-02 release was cut, the long-standing SDP-fication
patches by Neels were merged. I haven't studied those patches in full
detail yet, but the changes appear to be very massive (paradigmatic)
and when I tried running current master, it was totally broken for me.
I currently run my production network (interconnected to USA PSTN)
with 2023-02 version of Osmocom CNI. More precisely, I run this
stable version plus some small patches - see falconia/production
branch in osmo-hlr and osmo-msc - but these patches don't change
anything significant.
It will be a while before I have the requisite time slice to study the
SDP-fication patches that have been merged into current master and
find a way to repair / mitigate / work around the damage caused by
them. I will also need to set up a separate test environment for
playing with the new code, separate from my production network.
Under osmo-bsc.conf code support is set like this (the
BTS HW do
support all of these codecs):
codec-support fr efr amr
but once I also add "codec-list fr3 fr2 fr1" to the MSC section of the
osmo-bsc.conf, the calls wont establish anymore.
In the 2023-02 version the vty option in OsmoBSC (under msc 0) is
called codec-list, not codec-support, and in this good OsmoCNI version
this OsmoBSC vty setting is the only config setting in the entire
stack that determines not only which codecs will be used, but also the
order of preference for codec selection at the time of channel
assignment. Some practical possibilities:
* The default is "codec-list fr1 [...]". With fr1 listed at the head
of the list, the rest doesn't matter: with FRv1 indicated as the first
choice and with every GSM MS support FRv1, the selection will always
be FRv1.
* If you set "codec-list fr2 fr1 [...]", the network will switch to
preferring EFR. If the MS support EFR, then EFR will be chosen; if
the MS does not support EFR, then the fallback is FRv1. (This is my
production config.)
* If you set "codec-list fr3 fr2 fr1 [...]", you will get the standard
behavior implemented by most commercial GSM networks:
- if the MS supports AMR, then AMR will be used;
- if the MS supports EFR but nor AMR, then EFR will be used;
- if the MS supports neither AMR nor EFR, then FRv1 will be used.
I watched Neel's OsmoDevCall presentation on this
topic, but it is not
very clear what codecs are supported when osmo-sip-connector and an
external PBX is used?
I won't be able to help you with osmo-sip-connector or external PBX -
I don't use either of those - but to test and prove that the lower-level
components of OsmoCNI stack are working, you should try switching to
the internal MNCC in osmo-msc and see if that config works with all
codecs of interest to you.
On my production network I run OsmoMSC with external MNCC, but that
external MNCC is not osmo-sip-connector - it is my own alternative
implementation of the component which ETSI/3GPP specs call GMSC -
gateway MSC, the gateway to the host country's PSTN. For calls from
one local GSM subscriber to another, my external MNCC is an exact copy
of the internal one built into osmo-msc - but for calls to and from
outside PSTN, my GMSC transcodes RTP to G.711 PCMU or PCMA. Because
the local MS-to-MS path in my production network is identical to
OsmoMSC's internal MNCC, I have a high level of confidence in the
latter, which is why I recommend it as a test path.
Keith wrote:
I'm actually not sure about the state of
transcoding in the MGW, maybe
somebody has WIP in a branch.
I am not aware of anyone having implemented transcoding inside osmo-mgw,
but most production networks implement a transcoder in whatever element
connects to the {OsmoMSC+OsmoMGW} entity. As I understand it, in the
case of Rhizomatica this transcoder is an off-the-shelf piece of
software operating somewhere in SIP universe; in the case of Themyscira
Wireless the transcoder is a "soft TRAU" implemented by me, transcoding
between FR/EFR on the GSM side and PCMU/PCMA on the PSTN side, no other
combinations.
M~
24 Jul
24 Jul
10:39 a.m.
On 23.07.23 04:13, Mychaela Falconia wrote:
and when I tried running current master, it was
totally broken for me.
It sounds like you are referring to https://osmocom.org/issues/6074 of
which the root cause was https://osmocom.org/issues/6081 and has been
fixed in https://gerrit.osmocom.org/c/osmo-mgw/+/33534. If you
experience more bugs, please create proper bug reports.
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
8:15 p.m.
Oliver Smith <osmith(a)sysmocom.de> wrote:
It sounds like you are referring to
https://osmocom.org/issues/6074 of
which the root cause was https://osmocom.org/issues/6081 and has been
fixed in https://gerrit.osmocom.org/c/osmo-mgw/+/33534.
Yes, that was the first issue I hit. Whether or not there are others,
I don't know - back on June 25 I quickly reached the limit of how much
downtime I could allow on the production network, and moved to the
stable 2023-02 release.
If you experience more bugs, please create proper bug
reports.
I sure will, once I set up a separate test network (with separate BTS
hw) on which I can tinker without taking down my prod network. But
that setup is likely many months away, and I am sticking with known
good 2023-02 release in the meantime.
Back to this thread's OP, I also recommend sticking with 2023-02
release for the time being - the non-SDP-fied OsmoMSC plus matching
OsmoBSC and OsmoMGW is a much simpler, much more tested and weathered
design, and given that I run this version myself, I can also help
others in getting a working setup with it.
M~
7 Aug
7 Aug
5:16 p.m.
On Mon, Jul 24, 2023 at 10:15:53AM -0800, Mychaela Falconia wrote:
Back to this thread's OP, I also recommend
sticking with 2023-02
release for the time being - the non-SDP-fied OsmoMSC plus matching
You are welcome to use a release marked stable, but...
I find it odd to read here handwavy dismissal with the words "completely
broken" paired with "I have no time" and then basing recommendations to
others
on that.
Current master passes the test suite, and it works very well for others. The
codecs patches in question have run at various CCC events.
The codecs behavior in osmo-msc makes a lot more sense in current master. But
osmo-sip-connector is not yet up to speed. It would help to use
osmo-sip-connector from branch neels/codecs3.
In the older release, things are much worse: it actually may require fixating
the setup on a single codec, and hardcoding that specific codec in
osmo-sip-connector's source with a manual build, to be able to get the codec
that you expect through to SIP. So it may be infinitely more fun to configure a
new setup with current master of osmo-msc, and seeing codec choices from the MS
actually showing up in SIP *at all*.
~N
275
days inactive
295
days old
5 comments
5 participants
participants (5)
-
Keith -
Mychaela Falconia -
Neels Hofmeyr -
Oliver Smith -
Sipos Csaba