7 Dec
2022
7 Dec
'22
6:37 a.m.
Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> wrote:
If anyone likes this approach, I could implement a
'test-call' command
which would be like a silent call, but sending an MT SETUP message with
a random calling MSISDN. This way it would work for real phones too.
Thinking about it more, I like your proposal, except for the random
calling MSISDN part - like I said in my previous reply, the "calling
number" IE in the MT SETUP message should be either filled with a
vty-provided number or omitted altogether. Aside from this nitpick, a
test-call command built into OsmoMSC can (if implemented properly)
offer one obvious advantage over an external MNCC-based implementation
of the same functionality (such as my current themwi-test-mtc): the
ability to select the codec explicitly.
But let's think about it some more - how is the codec selected currently
for MT voice calls coming from MNCC? Irrespective of whether or not
the MT SETUP message includes a bearer capabilities IE (one will be
present with internal MNCC, coming from MO call leg, but typically not
present with externally originated MNCC calls), the MS will respond
with CALL CONFIRM, that CC message will always include a bearer
capabilities IE, and these latter bearer caps (sent by MS in response
to the MT SETUP, *not* from the MT SETUP msg itself!) will be the ones
controlling the channel type IE in the assignment command toward RAN.
The codec-list setting in OsmoBSC then sets the network-enforced order
of preference against which the bearer-caps-based codec request is
matched.
In operational networks, it is perfectly fine to let the combination
of MS capabilities and network-policy order of preference decide which
codec will be used - but for test calls, it would certainly be nice to
be able to manually select a specific codec for that specific call. I
can think of two ways:
1) Add a flag to MNCC, to be set together with MNCC_F_BEARER_CAP,
telling OsmoMSC to use the bearer caps from MNCC_SETUP_REQ instead
of those from MS CALL CONFIRM response, and/or
2) Implement some other mechanism within OsmoMSC, such as your proposed
test-call command, that bypasses the regular MNCC interface and
internally does an equivalent of option 1 above - sets some internal
flag telling the code to ignore bearer caps from MS CALL CONFIRM
response and to use the vty-specified codec instead.
That's all I have for now...
M~