Re: Call waiting and MNCC_RTP_CREATE

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. 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~