Project

General

Profile

Actions

Bug #5699

open

MNCC_RTP_CREATE is not sent in a call waiting scenario

Added by falconia over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
10/10/2022
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

Whenever an external call control agent (be it osmo-sip-connector or externally developed MNCC software) delivers an MT call to OsmoMSC, it needs to receive an MNCC_RTP_CREATE message back from OsmoMSC with RTP stream information, in order for the call in question to have any chance of working with passing voice traffic. This mechanism currently works just fine in the "first call" scenario, i.e., in the ordinary circumstance where an MT call is delivered to a previously idle MS. However, in a call waiting scenario, where a new MT call comes in when the target MS is already in a call, all signaling plane functions currently work just fine, but the external MNCC agent sending Call 2 to OsmoMSC never receives an MNCC_RTP_CREATE message for it, resulting in no possibility of passing voice traffic.

Looking in the code, I see that the sending of MNCC_RTP_CREATE to external MNCC is triggered by the event of channel assignment succeeding - makes sense - and it is thus apparent why no MNCC_RTP_CREATE is sent for Call 2: TCH is already there, hence there is no new assignment to be made, and the existing TCH will be repurposed for Call 2 if the MS accepts it. This part is clear; what is less obvious is how to fix it, i.e., how to communicate the necessary RTP stream info (for the repurposed TCH in this case) to the external MNCC agent, ideally without forcing external MNCC agents to treat call-waiting scenarios any different from regular "first" calls.

The trivial one-line patch attached to this ticket (to be applied to osmo-msc/src/libmsc/msc_a.c) is a quick hack that makes call waiting work in my deployment (I run my own external MNCC software, but I don't see how it would be any different with osmo-sip-connector), but I reason that a truly correct solution, covering all necessary corner cases, will probably need to be more complex.


Files

msc_a.c.patch msc_a.c.patch 341 Bytes falconia, 10/10/2022 06:30 PM

No data to display

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)