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/991bb422d417d24b25c40dbca5b312c385a5a668

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.