8 Oct
2022
8 Oct
'22
1:42 a.m.
Hello Osmocom CNI community,
I am writing my own software that talks MNCC to OsmoMSC instead of
using osmo-sip-connector, and I am seeing perplexing behaviour with
call waiting. Normally when I send an MT call toward GSM with
MNCC_SETUP_REQ, the response from OsmoMSC consists of
MNCC_CALL_CONF_IND (when the called phone confirms the call),
followed by MNCC_RTP_CREATE (when OsmoMSC assigns the call), and
finally followed by MNCC_ALERT_IND when the called phone starts
alerting. Likewise on MO calls I get an MNCC_RTP_CREATE message on
the MNCC interface when the call is assigned, typically in response to
MNCC_CALL_PROC_REQ.
But now consider a call waiting scenario: call 1 is already in progress
(fully connected, parties talking), and there is a second incoming
call. I send a new MNCC_SETUP_REQ to OpenMSC for call 2, with a new
callref, the phone receives it and starts making call-waiting beeps.
The response on the MNCC socket for call 2 is that I get
MNCC_CALL_CONF_IND followed by MNCC_ALERT_IND (and then MNCC_SETUP_CNF
if the target phone puts call 1 on hold and answers call 2) - but there
is no MNCC_RTP_CREATE!
I can see how MNCC_RTP_CREATE is sent by OsmoMSC when the call has been
assigned and there is a TCH cross-connected through OsmoMGW, and I can
see how the call assignment step will naturally be omitted in the call
waiting scenario when TCH is already there for call 1. But the call
gateway (be it osmo-sip-connector or an independent reimplementation)
feeding MT call 2 to MNCC has to have some way of obtaining RTP
connection information for this call without having to know how to
associate it with another previous call, and if it doesn't get
MNCC_RTP_CREATE, how would it get this vital info?
This is one of those "how does it work for everyone else?" moments -
while I am certainly unique in writing my own MNCC software instead of
running osmo-sip-connector, surely o-s-c also needs to receive
MNCC_RTP_CREATE with RTP info from OsmoMSC in order to successfully
connect call 2... And given that someone implemented call hold and
retrieve operations in o-s-c, I reason that someone must be using the
call waiting feature and it must be working for them - but how?
One thing which o-s-c does differently from my sw is that o-s-c sends
an empty MNCC_RTP_CREATE (the "command" version of this packet) to
OsmoMSC in response to MNCC_CALL_CONF_IND, which my sw doesn't do at
the moment. But I looked in the OsmoMSC code, and I don't see any
difference: the function that handles MNCC_RTP_CREATE command
(tch_rtp_create()) simply calls msc_a_try_call_assignment(trans), and
the exact same call is made in the gsm48_cc_rx_call_conf() function
that sends MNCC_CALL_CONF_IND. So I don't see any code path that can
result in call 2 receiving MNCC_RTP_CREATE from OsmoMSC in the call
waiting scenario when TCH is already there from call 1.
So, how does the call waiting feature work for others in the community,
and what am I missing? I am running the tagged release from 2021-11.
M~
8 Oct
8 Oct
2:09 a.m.
On 07/10/2022 18:42, Mychaela Falconia wrote:
Hello Osmocom CNI community,
I am writing my own software that talks MNCC to OsmoMSC instead of
using osmo-sip-connector,
I can't but wonder why, given that you've outlined quite some things
here that need attention in osmo-sip-connector and maybe the MNCC/CC
parts of osmo-msc.
And given that someone implemented call hold and
retrieve operations in o-s-c, I reason that someone must be using the
call waiting feature and it must be working for them - but how?
Why must it?
IIRC I had call hold working with osmo-nitb some years ago and added
some re-INVITE processing to osmo-sip-connector for that reason. Call
waiting I'm not sure. I think that's the reason for this:
https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/commit/991bb422d…
k/
5:28 a.m.
Hi Keith,
I am interfacing my little one-cell GSM network to USA PSTN, using a
PSTN-via-SIP connectivity provider, currently playing with BulkVS.
o-s-c is not designed to connect directly to a PSTN-via-SIP trunk
provider, it is designed to connect to a local instance of Asterisk or
FreeSWITCH or some other sw of that sort - and I am avoiding that
massive complexity.
I began with not being able to decide between Asterisk and FreeSWITCH:
just "trying out" either of them would require a very significant
learning curve investment for me, plus massive pain of getting it
compiled and running under Slackware. I was terrified of the idea of
investing all that effort only to discover down the road that I picked
the wrong one, and in any case, the probability of either o-s-c plus
Asterisk or o-s-c plus FreeSWITCH doing *exactly* what I desire,
without me needing to delve into it and make my own improvements, is
rather slim. Therefore, I decided to cut the massive complexity and
uncertainty of Asterisk-or-FreeSWITCH out of the equation, and write
my own replacement for o-s-c that interfaces directly to PSTN-via-SIP
connectivity providers, and further specific to the peculiarities of
USA PSTN, as opposed to whatever may exist in other countries with
which I have no experience.
All source is published here:
https://www.freecalypso.org/hg/themwi-system-sw/
One major diff between o-s-c and my solution is that my solution
includes a transcoding RTP MGW that talks GSM codecs on the inside and
G.711 on the outside - absolutely required function, as at least in
USA no PSTN-via-SIP connectivity provider supports GSM codecs. With
the "official" solution of o-s-c plus Asterisk or o-s-c plus FreeSWITCH,
do Asterisk and FreeSWITCH provide the needed RTP transcoding between
GSM codecs (*all* of them) and G.711 for PSTN?
On the reasoning that call hold feature has zero usefulness outside of
call waiting (at least the phones I work with, they send GSM48_MT_CC_HOLD
and GSM48_MT_CC_RETR *only* in the context of call waiting handling),
I naively assumed that someone working on call hold functionality means
that they must have working call waiting.
I am writing
my own software that talks MNCC to OsmoMSC instead of
using osmo-sip-connector,
I can't but wonder why, And given that
someone implemented call hold and
retrieve operations in o-s-c, I reason that someone must be using the
call waiting feature and it must be working for them - but how?
Why must it? Call waiting I'm not sure. I think that's the
reason for this:
https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/commit/991bb422d…
OK, so there is a config setting to enable or disable call waiting -
perfectly reasonable. It also happens to be enabled by default,
further leading new entrants into the scene to make the reasonable
assumption that call waiting works, or ought to work. Are you telling
me that call waiting DOES NOT work and has never worked in Osmocom,
for everyone and not just me?
If indeed call waiting has never worked successfully for anyone in
Osmocom, and I am going to be the first gal to make it work - oh well,
challenge accepted! For the first stumbling block I ran into, the
absence of MNCC_RTP_CREATE on call 2, I am going to try inserting a
call to gsm48_tch_rtp_create() into the 'if' block in
msc_a_try_call_assignment() where it currently prints the log message
"Another call is already ongoing, not assigning yet\n". I'll try it
later tonight, when I get back home where my BTS and test phones
reside - I'm out at a meetup right now.
M~
9 Oct
9 Oct
1:06 a.m.
Hello again everyone,
I am pleased to report that I have call waiting feature working just
fine on my network, consisting of OsmoMSC (plus OsmoBSC and sysmoBTS)
for the GSM part plus my own themwi-system-sw for the gateway to USA
PSTN. The only change I had to make to OsmoMSC (see attached trivial
patch) is just one line of code, calling gsm48_tch_rtp_create() in the
"another call already present" code path in msc_a_try_call_assignment().
Now I'm sure there are probably all kinds of corner cases this trivial
patch doesn't cover, but with this patch added call waiting works fine
in simple testing at the end user level, whereas without this patch it
has exactly zero chance of working: if there is no MNCC_RTP_CREATE
message sent by OsmoMSC for call 2, then whatever software is handling
that call 2, be it osmo-sip-connector or an independent reimplementation,
will have no ability to cross-connect the traffic plane for that call.
This discovery leads me to an unsetting observation about the state of
this community: given that current mainline unpatched OsmoMSC allows
no possibility of working call waiting feature, and it's been this way
for years, am I really the first person in the entire community to try
using call waiting, see it not working, spend less than a day digging
through code to see why, and make at least a rough experimental patch
to make it work? Really the first? Really? Wow...
In any case, it works now, with inbound calls coming from PSTN via my
themwi-sip-in call gateway that routes them to my themwi-mncc switch
and ultimately to OsmoMSC. For anyone who would like to see a real
gateway between an Osmocom-based GSM network and PSTN, the source is
here:
https://www.freecalypso.org/hg/themwi-system-sw/
I haven't started on the outbound call gateway yet, but the inbound
gateway feels quite solid now, including the necessary transcoding of
RTP and even generation of in-band DTMF tones toward PSTN.
M~
6:27 a.m.
Hi Keith,
I have to say, I'm impressed, (I think?) that
writing a new program from
scratch that involves protocol translation and RTP transcoding is easier
for you that configuring existing programs that do said thing.
I have two additional issues I didn't already mention:
1) I hate SIP with a passion, and I am using it out of poverty, rather
than out of genuine desire. If I were filthy rich, I would have
nothing to do with SIP, I would have got a TDM trunk instead for my
PSTN interface, with SS7 signaling. But I am not filthy rich, and a
SIP-based connection to PSTN is the only kind that's available for
dirt cheap, via providers like bulkvs.com - hence that's what I am
working with. But as an expression of protest and disapproval, I
don't want to embed SIP into the core of my network, instead I want to
keep it at the periphery. The approach espoused by osmo-sip-connector
where a purely local call from one locally attached GSM phone to
another is converted to SIP, then hairpinned back to o-s-c at the SIP
level by the PBX, is anathema to me. In my themwi-system-sw the
internal switch (themwi-mncc) is pure MNCC without any SIP (would be
easy to convert to Q.931 given a traditional PSTN trunk), and there
are two separate gateway processes for themwi-sip-in and themwi-sip-out.
2) There is no pre-existing sw (that I know of) that very specifically
does the job of interconnecting a GSM network to PSTN via SIP, nothing
more and nothing less. Neither Asterisk nor FreeSWITCH (and I haven't
even heard of the others you mentioned) is designed specifically for
this job, instead they are designed to do "everything and anything"
that revolves around SIP, and assume an operator/admin who loooves SIP
- not a "bellhead" like me! ("Bellhead" is an American term for
someone who thinks and views the world the way traditional Bell System
telco people did.)
But I feel that this discussion is approaching the situation from the
wrong angle - at the end of the day it doesn't matter whether any given
network operator/implementor chose to write her own sw or use mostly
pre-existing sw - it's an internal implementation detail - instead what
matters more (to me at least) is whether or not anyone else is building
similar functionality at all, irrespective of how they choose to
implement it.
Let me repeat the fundamental question: is there *anyone* in this
community besides me who operates an Osmocom GSM network with
interconnection to USA PSTN, with every GSM subscriber getting a real
10-digit NANP phone number, with ability to receive PSTN calls from
anywhere in the world and with ability to dial calls to anywhere in
the world, or at least to anywhere in USA? If someone has done what I
just described, I would *love* to hear from you, including as much
detail about your choice of software and technical setup as you would
be willing to share. And if no one has done this before me, if I get
to be the trailblazer here, going where no woman has gone before, then
on exactly what basis are you telling me that I am doing it wrong?
I asked a similar question here several months ago, before I embarked
"full steam ahead" on my themwi-system-sw. If someone had responded
along the lines of "yes, here we are, running an Osmocom network
interconnected to USA PSTN via such and such PSTN-via-SIP provider,
and this is the software stack use", then I would have looked into
that existing implementation before deciding to reinvent the wheel.
But no one responded positively, the silence I heard gave me the
impression that no one else is operating an Osmocom network in
furtherance of a similar telos, and so I had to strike out on my own.
But hey, I freely share all of the code I have written in furtherance
of my goal, and it interoperates with Osmocom CNI - so if what I am
doing is not community contribution, then what is?
[my quick-n-dirty patch to OsmoMSC to make call waiting work]
I'd be happy to test it, but unfortunately, I
don't see it in Code Review
I sent it as an email attachment; here it is again, inline this time:
--- msc_a.c.orig 2021-11-16 08:44:54.000000000 -0800
+++ msc_a.c 2022-10-07 19:47:29.459549124 -0800
@@ -1768,6 +1768,8 @@
if (msc_a->cc.active_trans) {
LOG_MSC_A(msc_a, LOGL_INFO, "Another call is already ongoing, not
assigning yet\n");
+ /* ThemWi addition for call waiting */
+ gsm48_tch_rtp_create(cc_trans);
return 0;
}
As you can see, it is literally a one line change, if you don't count
the comment. I don't have spare cycles at the moment to get into the
world of Gerrit, but if no one beats me to it, I'll submit it some
time later.
M~
4:17 p.m.
On 09/10/2022 23:27, Mychaela Falconia wrote:
In my themwi-system-sw the
internal switch (themwi-mncc) is pure MNCC
That's cool I guess if you don't care about call registration or billing
or such.
I don't have spare cycles at the moment to get
into the
world of Gerrit,
If you did submit to gerrit, you'll possibly get feedback on your
particular issue with MNCCC in osmo-msc from a wider osmocom community,
which I'd have thought might be a more productive use of your cycles
than long emails.
1:11 a.m.
On 07/10/2022 22:28, Mychaela Falconia wrote:
Hi Keith,
Hello again.
I began with not being able to decide between Asterisk
and FreeSWITCH:
I would have gone with kamailio/rtpengine
just "trying out" either of them would
require a very significant
learning curve investment for me, plus massive pain of getting it
compiled and running under Slackware.
I have to say, I'm impressed, (I think?) that writing a new program from
scratch that involves protocol translation and RTP transcoding is easier
for you that configuring existing programs that do said thing.
All source is published here:
https://www.freecalypso.org/hg/themwi-system-sw/
That's quite some lines of
code!
13 Oct
13 Oct
11:12 p.m.
Sorry for a real stupid question,but could this call waiting code somehow establist a
third connection to an ongoing gsm voice traffic channel ?/erich
På lørdag 8. oktober 2022 kl. 05:28:20 CEST skrev Mychaela Falconia
<mychaela.falconia(a)gmail.com> følgende:
Hi Keith,
I am interfacing my little one-cell GSM network to USA PSTN, using a
PSTN-via-SIP connectivity provider, currently playing with BulkVS.
o-s-c is not designed to connect directly to a PSTN-via-SIP trunk
provider, it is designed to connect to a local instance of Asterisk or
FreeSWITCH or some other sw of that sort - and I am avoiding that
massive complexity.
I began with not being able to decide between Asterisk and FreeSWITCH:
just "trying out" either of them would require a very significant
learning curve investment for me, plus massive pain of getting it
compiled and running under Slackware. I was terrified of the idea of
investing all that effort only to discover down the road that I picked
the wrong one, and in any case, the probability of either o-s-c plus
Asterisk or o-s-c plus FreeSWITCH doing *exactly* what I desire,
without me needing to delve into it and make my own improvements, is
rather slim. Therefore, I decided to cut the massive complexity and
uncertainty of Asterisk-or-FreeSWITCH out of the equation, and write
my own replacement for o-s-c that interfaces directly to PSTN-via-SIP
connectivity providers, and further specific to the peculiarities of
USA PSTN, as opposed to whatever may exist in other countries with
which I have no experience.
All source is published here:
https://www.freecalypso.org/hg/themwi-system-sw/
One major diff between o-s-c and my solution is that my solution
includes a transcoding RTP MGW that talks GSM codecs on the inside and
G.711 on the outside - absolutely required function, as at least in
USA no PSTN-via-SIP connectivity provider supports GSM codecs. With
the "official" solution of o-s-c plus Asterisk or o-s-c plus FreeSWITCH,
do Asterisk and FreeSWITCH provide the needed RTP transcoding between
GSM codecs (*all* of them) and G.711 for PSTN?
On the reasoning that call hold feature has zero usefulness outside of
call waiting (at least the phones I work with, they send GSM48_MT_CC_HOLD
and GSM48_MT_CC_RETR *only* in the context of call waiting handling),
I naively assumed that someone working on call hold functionality means
that they must have working call waiting.
I am writing
my own software that talks MNCC to OsmoMSC instead of
using osmo-sip-connector,
I can't but wonder why, And given that
someone implemented call hold and
retrieve operations in o-s-c, I reason that someone must be using the
call waiting feature and it must be working for them - but how?
Why must it? Call waiting I'm not sure. I think that's the
reason for this:
https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/commit/991bb422d…
OK, so there is a config setting to enable or disable call waiting -
perfectly reasonable. It also happens to be enabled by default,
further leading new entrants into the scene to make the reasonable
assumption that call waiting works, or ought to work. Are you telling
me that call waiting DOES NOT work and has never worked in Osmocom,
for everyone and not just me?
If indeed call waiting has never worked successfully for anyone in
Osmocom, and I am going to be the first gal to make it work - oh well,
challenge accepted! For the first stumbling block I ran into, the
absence of MNCC_RTP_CREATE on call 2, I am going to try inserting a
call to gsm48_tch_rtp_create() into the 'if' block in
msc_a_try_call_assignment() where it currently prints the log message
"Another call is already ongoing, not assigning yet\n". I'll try it
later tonight, when I get back home where my BTS and test phones
reside - I'm out at a meetup right now.
M~
11:47 p.m.
Erich Dachleger <edachleger(a)yahoo.com> wrote:
Sorry for a real stupid question,
but could this call waiting code somehow establist a third connection
to an ongoing gsm voice traffic channel ?
The software that talks MNCC to OsmoMSC needs to be written properly
in this regard: specifically, in the case of MT calls delivered to
OsmoMSC, the MNCC agent must not send MNCC_RTP_CONNECT until and
unless it receives MNCC_SETUP_CNF. If the MNCC agent were to send
MNCC_RTP_CONNECT right away, then indeed it would disrupt (intrude
upon) the existing voice TCH - however, if the MS sends a CC CONNECT
message which OsmoMSC turns into MNCC_SETUP_CNF, then the MS indicates
that the user would like to accept the new call, in which case
switching the existing TCH to the new call (which is what
MNCC_RTP_CONNECT will do) is appropriate. OTOH, if the user rejects
the new call, then there will never be an MNCC_SETUP_CNF for that
rejected call, and the MNCC agent must never send MNCC_RTP_CONNECT.
osmo-sip-connector appears to behave correctly in this regard, based
on my reading of the code, and of course my own themwi-system-sw is
correct too.
M~
14 Oct
14 Oct
10:13 p.m.
On 13/10/2022 16:12, Erich Dachleger wrote:
Sorry for a real stupid question,
The only really stupid question is the one for
which an answer was never
sought.
but could this call waiting code somehow establist a
third connection
to an ongoing gsm voice traffic channel ?
If you are thinking of something like three-way group calling, where you
have an existing call between two parties and then a 3rd caller can join
in, I don't think there is any provision in GSM for such, but you can
mux calls without so much trouble with a PBX like Freeswitch or a number
of FOSS tools.
k/
567
days inactive
574
days old
10 comments
3 participants
participants (3)
-
Erich Dachleger -
Keith -
Mychaela Falconia