Project

General

Profile

Bug #2777

Document that DTMF signalling does not work (with internal MNCC)

Added by dexter 12 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/21/2017
Due date:
% Done:

100%

Resolution:

Description

The correct transmission of DTMF tones is currently not working. I have done a series of tests, here are the results:

  • unsuccessful_ms_to_ms_dtmf_tone_(NG40).pcapng: Mobile to mobile DTMF tone signalling Start and stop of the DTMF tone is acknowledged. This looks good to my perspective, probably the DTMF forwarding is not properly configured inside the NG40 tester, otherwise I would expect to see the MSC at least trying to deliver the DTMF tones to the other mobile.
  • unsuccessful_ms_to_ms_dtmf_tone_with_external_mncc.pcapng: Here I can see the start command, which gets translated into a SIP message on the osmo-sip-connector. The tone also gets acknowledged and is stopped again. But again we see no response to the other MS whatsoever. This could also still be a problem with my PBX setup, since we would expect to see another SIP-Message that triggers the DTMF tone for the other MS.
  • unsuccessful_ms_to_ms_dtmf_tone_with_internal_mncc.pcapng: This trace was recorded with the internal MNCC active and really looks not ok. The DTMF tone gets actively rejected.
  • successful_ms_to_sip_dtmf_tone.pcapng: Here I see almost the same as in unsuccessful_ms_to_ms_dtmf_tone_with_external_mncc.pcapng, but the tone gets actually played on the other side. So I think sending DTMF tones should be fine, but receiving definetly has a problem.
  • When I press buttons on the sip phone actually nothing, not even a sip-message is transmitted. That also confirms that there may be problems with the PBX.

However. I still wonder why the DTMF tones get rejected when osmo-msc is running on its internal MNCC. Something is definetly problematic there. The DTMF tone should travel back to the other end and not get rejected. I also attached the configuration files of osmo-bsc and osmo-msc. Maybe I am just lacking the right configuration options.


Related issues

Related to osmo-sip-connector - Bug #1684: osmo-sip-connector: Create manual for the osmo-sip-connectorResolved2016-03-312018-07-06

History

#1 Updated by laforge 12 months ago

please split this into separate bugs, from what I can tell some of the bugs relate
to OsmoBSC and some to OsmoMSC?

#2 Updated by laforge 11 months ago

  • Checklist item document no DTMF withi nternal mncc in OsmoMSC manual added
  • Checklist item document challenges of getting MT-DTMF to work with SIP in osmo-sip-connector manual added
  • Checklist item document we need DTMF inside the media (not signalling) for MT-DTMF from SIP added
  • Checklist item document we provide MO-DTMF as signalling on SIP added
  • Checklist item investigate if this could be done in the MGW (are there MGCP message for tone playback?) added
  • Priority changed from Normal to Low

AFAIK the DTMF related signalling in GSM L3 Call Control only caters for mobile originated DTMF.

This means that the MSC/MGW or some other entity higher up in the network would have to convert those DTMF signals into actual tones, and substitute some audio samples with those tones before sending it back.

I guess the rationale is that one wants users to be able to use DTMF (e.g. for voice mailbox systems, call center applications, etc.) but as such applications are all connected to the wired telephony network, it's not needed to signal DTMF to a GSM subscriber.

So all in all, it's probably ok for the internal MNCC to reject the DTMF playing, as it doesn't have the media playback ability. In some distant future we should be able to add this to OsmoMGW, but not now.

As for the interworking with external SIP: as long as we properly report the DTMF tones on the SIP trunk, everything else is up to the SIP switch and its media handling. We should document in the osmo-sip-connector manual that this is apparently not working from statch.

#3 Updated by laforge 6 months ago

  • Subject changed from DTMF signalling does not work (with internal MNCC) to Document that DTMF signalling does not work (with internal MNCC)
  • Priority changed from Low to Normal

pleaes document the shortcomings in the related manuals as indicated above. Coordinate with daniel regarding the osmo-sip-connector manual. Maybe it makes sense for you (Philipp) to also write that?

#4 Updated by laforge 6 months ago

  • Related to Bug #1684: osmo-sip-connector: Create manual for the osmo-sip-connector added

#5 Updated by dexter 5 months ago

Note: I have re-tested it with recent versions. The only constellation that works is MO to landline (SIP).

#6 Updated by laforge 3 months ago

  • Project changed from OsmoBSC to OsmoMSC
  • Category deleted (A interface)

this is a rather small task, just adding a few lines of documentation to various documents. It woudl be great if those small tickets could be resolved quickly without being open for multiple months.

#7 Updated by dexter 2 months ago

  • Checklist item document no DTMF withi nternal mncc in OsmoMSC manual set to Done
  • Checklist item document challenges of getting MT-DTMF to work with SIP in osmo-sip-connector manual set to Done
  • Checklist item document we need DTMF inside the media (not signalling) for MT-DTMF from SIP set to Done
  • Checklist item document we provide MO-DTMF as signalling on SIP set to Done
  • Checklist item investigate if this could be done in the MGW (are there MGCP message for tone playback?) set to Done

#8 Updated by dexter 2 months ago

  • % Done changed from 0 to 90

I have now gone through the specs and did a few experiments. The signaling of DTMF tones is indeed implemented in two different ways. I think for MO DTMF we are doing everything right. The START/STOP DTMF messages travel upwards the core network and finally arrive as sip-info messages at the PBX. For the other way around I think at least what osmo-msc is concerned everything is correct as well. When someone tries to signal DTMF tones at the MNCC interface those attempts should be rejected since the MT DTMF is done as inband signaling.

I checked the MT DTMF signaling using a Tems Phone on a public network. There are indeed no DTMF START/STOP messages when a MT DTMF Tone arrives, so it must be inband. For MO DTMF I can see the START/STOP DTMF messages.

I have now documented the DTMF limitations in the manual of osmo-msc and osmo-sip-connector, see also:
remote: https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/11169 running: Add note about DTMF support
remote: https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/11170 mncc: add missing DTMF message types.
remote: https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/11171 mncc: add note about DTMF considerations

I also checked the MGCP specs (RFC3435). There are RQNT commands that provide a SignalRequest field (S), this field can describe various events. From what I can see it can also be used to describe a DTMF tone. We could instruct the MGW to playback random DTMF tones using this functionality, see also: RFC3435, 3.2.2.21 and 3.2.2.4. Injecting DTMF tones into the voice stram is probably not that easy since we would have to generate the tones using the right codec. For the MSC side that would mean we need to fix the codec negotiation on the MNCC interface first.

Once we are able to inject tones using the MGW we could allow DTMF START/STOP messages on the MNCC interface also in MT direction. First we would have to extend osmo-sip-connector to also accept DTMF sip-info messages. Currently osmo-sip-connector seems to reject those messages early. However, once we can signal DTMF messages through the MNCC towards the MSC, the MSC could send the RQNT to the MGW in order to playback the DTMF tone.

#9 Updated by dexter 2 months ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)