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~
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/991bb422d4...
k/
Hi Keith,
I am writing my own software that talks MNCC to OsmoMSC instead of using osmo-sip-connector,
I can't but wonder why,
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?
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?
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.
Call waiting I'm not sure. I think that's the reason for this: https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/commit/991bb422d4...
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~
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~
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~
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.
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:
That's quite some lines of code!
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@gmail.com følgende:
Hi Keith,
I am writing my own software that talks MNCC to OsmoMSC instead of using osmo-sip-connector,
I can't but wonder why,
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?
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?
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.
Call waiting I'm not sure. I think that's the reason for this: https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/commit/991bb422d4...
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~
Erich Dachleger edachleger@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~
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/
-
Erich Dachleger -
Keith -
Mychaela Falconia