huawei: duplicated DTMF tone

Riccardo Vangelisti riccardo.vangelisti at sadel.it
Thu Jun 29 14:35:18 UTC 2017


Hi Dan,
have you any feedback about this patch ?
I've made a lot of test and seems to fix CPU leak and duplicated DTMF.

Thanks,
Riccardo

> Hi Dan,
> I take a look to the code and I came up to this patch.
> It saves the device name at the voice call connection start (^CONN) 
> and use it for DTMF until call ends (^CEND).
> I tested on Huawei modems I own and it works perfectly. Theoretically, 
> it should work also in case of PPP connection.
>
> What do you think ?
>
> diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
> b/plugins/huawei/mm-broadband-modem-huawei.c
> index cf22b0d5..38f815d8 100644
> --- a/plugins/huawei/mm-broadband-modem-huawei.c
> +++ b/plugins/huawei/mm-broadband-modem-huawei.c
> @@ -147,6 +147,8 @@ struct _MMBroadbandModemHuaweiPrivate {
>      GArray *prefmode_supported_modes;
>
>      DetailedSignal detailed_signal;
> +
> +    gchar *dtmf_device_name;
>  };
>
>  /*****************************************************************************/ 
>
> @@ -3008,6 +3010,11 @@ huawei_voice_call_connection (MMPortSerialAt 
> *port,
>
>      mm_dbg ("[^CONN] Call id '%u' of type '%u' connected", call_x, 
> call_type);
>
> +    if (self->priv->dtmf_device_name) {
> +        g_free(self->priv->dtmf_device_name);
> +        self->priv->dtmf_device_name = NULL;
> +    }
> +
>      mm_iface_modem_voice_call_ringing_to_active (MM_IFACE_MODEM_VOICE 
> (self));
>  }
>
> @@ -3035,6 +3042,11 @@ huawei_voice_call_end (MMPortSerialAt *port,
>
>      mm_dbg ("[^CEND] Call '%u' terminated with status '%u' and cause 
> '%u'. Duration of call '%d'", call_x, end_status, cc_cause, duration);
>
> +    if (self->priv->dtmf_device_name) {
> +        g_free(self->priv->dtmf_device_name);
> +        self->priv->dtmf_device_name = NULL;
> +    }
> +
>      mm_iface_modem_voice_network_hangup (MM_IFACE_MODEM_VOICE (self));
>  }
>
> @@ -3048,8 +3060,16 @@ huawei_voice_received_dtmf (MMPortSerialAt *port,
>      key = g_match_info_fetch (match_info, 1);
>
>      if (key) {
> -        mm_dbg ("[^DDTMF] Received DTMF '%s'", key);
> -        mm_iface_modem_voice_received_dtmf (MM_IFACE_MODEM_VOICE 
> (self), key);
> +        if (!self->priv->dtmf_device_name) {
> +            self->priv->dtmf_device_name = g_strdup 
> (mm_port_get_device (MM_PORT(port)));
> +        }
> +
> +        if (g_strcmp0(self->priv->dtmf_device_name, 
> mm_port_get_device (MM_PORT(port))) == 0) {
> +            mm_dbg ("[^DDTMF] Received DTMF '%s' on port '%s'", key, 
> self->priv->dtmf_device_name);
> +            mm_iface_modem_voice_received_dtmf (MM_IFACE_MODEM_VOICE 
> (self), key);
> +        } else {
> +            mm_dbg ("[^DDTMF] Ignoring DTMF '%s' on port '%s'", key, 
> mm_port_get_device (MM_PORT(port)));
> +        }
>      }
>  }
>
> @@ -4446,6 +4466,8 @@ mm_broadband_modem_huawei_init 
> (MMBroadbandModemHuawei *self)
>      self->priv->prefmode_support = FEATURE_SUPPORT_UNKNOWN;
>      self->priv->nwtime_support = FEATURE_SUPPORT_UNKNOWN;
>      self->priv->time_support = FEATURE_SUPPORT_UNKNOWN;
> +
> +    self->priv->dtmf_device_name = NULL;
>  }
>
>  static void
>
>
> Riccardo
>
>
>> Hi Dan,
>> your patch doesn't compile because "if (port)" needs curly braces 
>> after that.
>> Apart of that your patch it works but in case of PPP connection DTMF 
>> are not handled anyway and CPU loading issue is present (in a very 
>> remote case if I receive a lot of DTMF messages).
>>
>> Could we mark the port on which voice call has been received and, 
>> during the call, use only that for DTMF ?
>>
>> Riccardo
>>
>>> On Mon, 2017-05-08 at 15:24 +0200, Riccardo Vangelisti wrote:
>>>> Hi all,
>>>> I've found a strange behavior when I receive DTMF during voice call.
>>>> It seems that DTMF code are received and signaled twice,
>>>> specifically
>>>> one time for each active AT port.
>>> So in this case, it should probably just be enabled for the primary
>>> port.  Though I'm a bit wary of only doing it for the primary port,
>>> since it's theoretically possible to have the primary port taken by PPP
>>> and do simultaneous voicecall with notifications on the secondary port,
>>> but I think that's less-than-likely.
>>>
>>> Does something like this work?
>>>
>>> diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
>>> b/plugins/huawei/mm-broadband-modem-huawei.c
>>> index cf22b0d..ee01d9c 100644
>>> --- a/plugins/huawei/mm-broadband-modem-huawei.c
>>> +++ b/plugins/huawei/mm-broadband-modem-huawei.c
>>> @@ -3058,12 +3058,23 @@ set_voice_unsolicited_events_handlers 
>>> (MMBroadbandModemHuawei *self,
>>>                                          gboolean enable)
>>>   {
>>>       GList *ports, *l;
>>> +    MMPortSerialAt *port;
>>> +
>>> +    port = mm_base_modem_get_port_primary (MM_BASE_MODEM (self));
>>> +    if (port)
>>> +        mm_port_serial_at_add_unsolicited_msg_handler (
>>> +            port,
>>> +            self->priv->ddtmf_regex,
>>> +            enable ? 
>>> (MMPortSerialAtUnsolicitedMsgFn)huawei_voice_received_dtmf: NULL,
>>> +            enable ? self : NULL,
>>> +            NULL);
>>> +    }
>>>         ports = get_at_port_list (self);
>>>         /* Enable/disable unsolicited events in given port */
>>>       for (l = ports; l; l = g_list_next (l)) {
>>> -        MMPortSerialAt *port = MM_PORT_SERIAL_AT (l->data);
>>> +        port = MM_PORT_SERIAL_AT (l->data);
>>>             mm_port_serial_at_add_unsolicited_msg_handler (
>>>               port,
>>> @@ -3089,12 +3100,6 @@ set_voice_unsolicited_events_handlers 
>>> (MMBroadbandModemHuawei *self,
>>>               enable ? 
>>> (MMPortSerialAtUnsolicitedMsgFn)huawei_voice_call_end : NULL,
>>>               enable ? self : NULL,
>>>               NULL);
>>> -        mm_port_serial_at_add_unsolicited_msg_handler (
>>> -            port,
>>> -            self->priv->ddtmf_regex,
>>> -            enable ? 
>>> (MMPortSerialAtUnsolicitedMsgFn)huawei_voice_received_dtmf: NULL,
>>> -            enable ? self : NULL,
>>> -            NULL);
>>>             /* Ignore this message (Huawei ME909s-120 firmware. 
>>> 23.613.61.00.00) */
>>>           mm_port_serial_at_add_unsolicited_msg_handler (
>>>
>>>
>>>> Jan  1 00:02:22 localhost ModemManager[1940]: <debug>
>>>> [1325376142.982264] [mm-port-serial-at.c:459] debug_log():
>>>> (ttyUSB0):
>>>> <-- '<CR><LF>^DDTMF: 9<CR><LF>'
>>>> Jan  1 00:02:22 localhost ModemManager[1940]: <debug>
>>>> [1325376142.982562] [huawei/mm-broadband-modem-huawei.c:3051]
>>>> huawei_voice_received_dtmf(): [^DDTMF] Received DTMF '9'
>>>> Jan  1 00:02:22 localhost ModemManager[1940]: <debug>
>>>> [1325376142.983283] [mm-port-serial-at.c:459] debug_log():
>>>> (ttyUSB2):
>>>> <-- '<CR><LF>^DDTMF: 9<CR><LF>'
>>>> Jan  1 00:02:22 localhost ModemManager[1940]: <debug>
>>>> [1325376142.983596] [huawei/mm-broadband-modem-huawei.c:3051]
>>>> huawei_voice_received_dtmf(): [^DDTMF] Received DTMF '9'
>>>>
>>>>
>>>> # dbus-monitor --system
>>>>
>>>> signal sender=:1.0 -> dest=(null destination) serial=1362
>>>> path=/org/freedesktop/ModemManager1/Call/1;
>>>> interface=org.freedesktop.ModemManager1.Call; member=DtmfReceived
>>>>      string "9"
>>>> signal sender=:1.0 -> dest=(null destination) serial=1363
>>>> path=/org/freedesktop/ModemManager1/Call/1;
>>>> interface=org.freedesktop.ModemManager1.Call; member=DtmfReceived
>>>>      string "9"
>>>>
>>>>
>>>> Looking in commit log, I've found that problem is present since this
>>>> commit: "huawei: update to correct secondary port request and regex
>>>> masking for ^POSITION" (1f270c09d03b6c2c4c57fb9b8ca539243035992b)
>>>> This commit enable all unsolicited message (DTMF included) also on
>>>> secondary AT port.
>>>>
>>>> In most cases unsolicited message can be handled twice or many times
>>>> without any side effect, but in the case of voice command (DTMF,
>>>> call,
>>>> ecc...) this is a problem.
>>>>
>>>> Reverting to the previous behavior (unsolicited message handled only
>>>> on
>>>> primary AT port) DTMF are received correctly but there is a CPU
>>>> loading
>>>> issue as reported by Marc Murphy (and verified by me).
>>>>
>>>> Is this right ? Any ideas ?
>>>>
>>>> Thanks,
>>>> Riccardo
>>>> _______________________________________________
>>>> ModemManager-devel mailing list
>>>> ModemManager-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>>
>



More information about the ModemManager-devel mailing list