Vadim Yanitskiy vyanitskiy@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~