Attention is currently required from: neels.

falconia has posted comments on this change. ( 
https://gerrit.osmocom.org/c/osmo-msc/+/29973 )

Change subject: msc_a: send MNCC_RTP_CONNECT in call waiting scenarios
......................................................................


Patch Set 1:

(1 comment)

Patchset:

PS1:
> i mean "a call waiting scenario" seems to say it all, but when i think about 
> it i'm not so sure afte […]
Alice and Bob are in a call, and then Charlie dials Alice's number. The network 
delivers a new MT call SETUP message for call 2 to Alice's MS, and her phone 
does what all standard phones do: it starts playing an in-band call waiting 
tone (GSM 02.40 Table 1 Tone 7) into her ear, and shows Charlie's calling 
number (from the new SETUP message) on the display. But while this call 2 is 
pending and the CW tone is playing, the call between Alice and Bob is still 
active, and they can keep talking! While this CW in-band audio notification is 
ongoing, to the network it's the same as if Call 2 was ringing normally, and 
the MS replies with ALERTING CC message on this call 2.

If Alice presses the "Accept" button in her phone's call waiting UI (meaning 
"accept new call"), her MS implementation will execute a Hold operation on call 
1 - Bob will NOT be disconnected, but the call will go silent for him as the 
voice traffic from Alice cuts off. Then Alice's MS replies to the network with 
a CONNECT on call 2, and expects the network to switch call 2 audio to the 
existing voice TCH.

For as long as Bob stays on his phone, patiently waiting for Alice to come 
back, she can press a "switch calls" button in her phone UI - and every time 
she does so, the mobile-side protocol stack in her MS will execute a Hold 
operation on the currently active call, and then a Retrieve operation on the 
previously held one.

Now enter Osmocom. For a self-contained Osmocom network with internal MNCC, my 
little patch does not help: with or without this patch, call waiting has no 
chance of working as there is no support for more basic call hold and retrieve 
operations. But enter external MNCC, either themwi-system-sw (what I actually 
run) or osmo-sip-connector (should work the same in this regard, but untested) 
- that's when my patch makes CW work at least in basic testing, without 
considering any corner cases.

For the purpose of analyzing CW with external MNCC and my patch, assume that 
Alice is a local GSM user, while Bob and Charlie are parties in the outside 
world. When Alice and Bob establish their initial call, in either MO (Alice 
calls Bob) or MT (Bob calls Alice) direction, the external MNCC software will 
handle that call under a certain callref on the MNCC socket. The audio 
connection is established by OsmoMSC giving its RTP info to the external MNCC 
via MNCC_RTP_CREATE and the external MNCC giving its RTP info to OsmoMSC via 
MNCC_RTP_CONNECT.

When Charlie dials Alice's number from the outside world, the PSTN-to-Osmocom 
gateway will handle this MT call as a separate logical entity having no 
relation to call 1: it will assign a new MT callref for call 2 and send 
MNCC_SETUP_REQ to OsmoMSC. From that point onward, everything works correctly 
except one detail: in the new MNCC message exchange for callref 2, no 
MNCC_RTP_CREATE is ever sent from OsmoMSC to the external MNCC. And with RTP 
info missing, call 2 audio can never be connected. My patch is a band-aid that 
makes this flow work successfully in the simplest scenario, ignoring all sorts 
of corner cases such as what happens if call 2 comes in while TCH assignment 
for call 1 hasn't been completed yet, Bearer cap and codec issues and probably 
myriad others.

My next OsmoDevCall presentation (tentatively scheduled for August, though I 
won't mind waiting till September if someone else wishes to present in Aug) 
will be on the subject of external MNCC and Osmocom to PSTN interfacing, and I 
will be discussing the present issue then.



--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/29973
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ibb62cb3c154b99769b2dfe708f73c20e8b632f5d
Gerrit-Change-Number: 29973
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <fal...@freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanits...@sysmocom.de>
Gerrit-Reviewer: neels <nhofm...@sysmocom.de>
Gerrit-CC: laforge <lafo...@osmocom.org>
Gerrit-Attention: neels <nhofm...@sysmocom.de>
Gerrit-Comment-Date: Fri, 23 Jun 2023 17:21:08 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofm...@sysmocom.de>
Gerrit-MessageType: comment

Reply via email to