from:"Riccardo Vangelisti"

Re: [review] dcbw/huawei-voice

2017-06-13 Thread Riccardo Vangelisti


  
  
Hey,


  On Fri, 2017-05-05 at 18:56 +0200, Riccardo Vangelisti wrote:

  

  On Fri, 2017-05-05 at 16:40 +0200, Riccardo Vangelisti wrote:

  
Hi,


  On Thu, 2017-05-04 at 16:30 +0200, Riccardo Vangelisti wrote:

  
Hi,
sorry for late reply but we took some time to test this
branch
using
these Huawei modems:

+---+-+

--+---
+


  Modem | Firmware| ^CVOICE
Support  |
Voice |



+---+-+

--+---
+


  Huawei ME909s-120 | 11.617.01.00.00 | ^CVOICE: 1, 8000, 16,
20

  


  
  
Yes  |
Huawei MU709s-2   | 11.651.67.00.00 | ^CVOICE: 1, 8000, 16,
20

  


  
  
Yes  |
Huawei E1150  | 11.609.18.00.00 |
^CVOICE:0,8000,16,20 |
Yes  |



+---+-+

--+---
+

First of all, when ^CVOICE command is not supported by the
modem
all
of
voice capabilities are disabled.
For example, ME909s and MU709s modems have voice capabilities
supported
by the firmware but voice is disabled anyway.

  
  
So for these devices, they don't implement CVOICE, but do
support
voice
via non-host-routed mechanisms, is that correct?



Yes, I don't know why manufacturer disable CVOICE command in
these
modems.

  
  
OK.


  

  eg, they have pins for I2C audio or something like that?  How
do we
know that these devices support voice, can we tell from
firmware
commands?



Yes, they have a PCM audio interface (data in, data out, clk and
sync
on
Mini-PCI express) connected to an external audio codec like
TLV320AIC3204.

  
  
Ok.  The problem is that ModemManager should only enable the Voice
API
when it knows the modem has audio hardware or an audio interface,
which
most devices like USB sticks and lots of PCIE modems don't.  So
we'll
probably need to use udev rules too.



Ok.


  

  

  
Our proposal is to use ^CVOICE command only for checking PCM
audio
port
capabilities and not for all voice capabilities.
Can voice capabilities be enabled or not using ATH or AT+CHUP
command
?

  
  
No, because most modems support these commands, but do not
include
voice capabilities because they have no mechanism to get audio
in/out
of the device.  Only modems with specific voice routing (I2C,
USB,
PCM
etc) actually have the voice capabilitiy, and I don't think we
should
enable the interface unless we know.

Ideally we can use some other firmware commands to detect that
voice is
possible on devices that do not support CVOICE.



After a quick search I cannot find a specific command that can be
used
to check if modem+firmware supports voice.
I think that manufacturer deploy a general purpose firmware in
most
of
their modems.
I've attached a text file with some test that show voice related
at
command can't be used to check if voice is supported or not.
In particular Huawei E172 make voice call but voice related AT
commands
return an error.

  
  
I know many modems support the generic voicecall commands, but most
don't have audio hardware at all.  I wasn't aware the E172 had that
voice capabilities in any firmware version, are you sure it has the
USB
PCM audio capability like others?



E172 makes call but don't have an audio jack, maybe with a little
hack 
with opening the case or something else it can be connected an audio
jack.



  

  

  If we cannot, then I think we have to fall back to udev tags or
something.



Right, if CVOICE is not supported we can enable voice capability
from
udev specifying the audio mode, for example external PCM audio or
CVOICE
mode.
Also when CVOICE is supported we could use external PCM audio
using
udev
tags.
Something like ID_MM_HUAWEI_FORCE_EXTAUDIO=1

  
  
Since CVOICE only works on Huawei, and only works on some Huawei
devices, obviously we'd need to find other AT commands for other
manufacturers, and/or use udev tags.

I would suggest ID_MM_VOICE_SUPPORTED=1 or something like that, and
make it available to all devices not just Huawei.



Perfect !


  
The next question is whether these devices should provide anything
in
the "Audio Format" and "Audio Port" properties.  I would say no,
since
it's ve

Re: huawei: duplicated DTMF tone

2017-05-11 Thread Riccardo Vangelisti


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-&g

Re: huawei: duplicated DTMF tone

2017-05-09 Thread Riccardo Vangelisti


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]: 
[1325376142.982264] [mm-port-serial-at.c:459] debug_log():
(ttyUSB0):
<-- '^DDTMF: 9'
Jan  1 00:02:22 localhost ModemManager[1940]: 
[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]: 
[1325376142.983283] [mm-port-serial-at.c:459] debug_log():
(ttyUSB2):
<-- '^DDTMF: 9'
Jan  1 00:02:22 localhost ModemManager[1940]: 
[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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

huawei: duplicated DTMF tone

2017-05-08 Thread Riccardo Vangelisti


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.


Jan  1 00:02:22 localhost ModemManager[1940]:  
[1325376142.982264] [mm-port-serial-at.c:459] debug_log(): (ttyUSB0): 
<-- '^DDTMF: 9'
Jan  1 00:02:22 localhost ModemManager[1940]:  
[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]:  
[1325376142.983283] [mm-port-serial-at.c:459] debug_log(): (ttyUSB2): 
<-- '^DDTMF: 9'
Jan  1 00:02:22 localhost ModemManager[1940]:  
[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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [review] dcbw/huawei-voice

2017-05-05 Thread Riccardo Vangelisti




On Fri, 2017-05-05 at 16:40 +0200, Riccardo Vangelisti wrote:

Hi,

On Thu, 2017-05-04 at 16:30 +0200, Riccardo Vangelisti wrote:

Hi,
sorry for late reply but we took some time to test this branch
using
these Huawei modems:

+---+-+
--+---
+

Modem | Firmware| ^CVOICE
Support  |
Voice |

+---+-+
--+---
+

Huawei ME909s-120 | 11.617.01.00.00 | ^CVOICE: 1, 8000, 16, 20
|
Yes  |
Huawei MU709s-2   | 11.651.67.00.00 | ^CVOICE: 1, 8000, 16, 20
|
Yes  |
Huawei E1150  | 11.609.18.00.00 |
^CVOICE:0,8000,16,20 |
Yes  |

+---+-+
--+---
+

First of all, when ^CVOICE command is not supported by the modem
all
of
voice capabilities are disabled.
For example, ME909s and MU709s modems have voice capabilities
supported
by the firmware but voice is disabled anyway.

So for these devices, they don't implement CVOICE, but do support
voice
via non-host-routed mechanisms, is that correct?

Yes, I don't know why manufacturer disable CVOICE command in these
modems.

OK.


eg, they have pins for I2C audio or something like that?  How do we
know that these devices support voice, can we tell from firmware
commands?

Yes, they have a PCM audio interface (data in, data out, clk and sync
on
Mini-PCI express) connected to an external audio codec like
TLV320AIC3204.

Ok.  The problem is that ModemManager should only enable the Voice API
when it knows the modem has audio hardware or an audio interface, which
most devices like USB sticks and lots of PCIE modems don't.  So we'll
probably need to use udev rules too.

Ok.



Our proposal is to use ^CVOICE command only for checking PCM
audio
port
capabilities and not for all voice capabilities.
Can voice capabilities be enabled or not using ATH or AT+CHUP
command
?

No, because most modems support these commands, but do not include
voice capabilities because they have no mechanism to get audio
in/out
of the device.  Only modems with specific voice routing (I2C, USB,
PCM
etc) actually have the voice capabilitiy, and I don't think we
should
enable the interface unless we know.

Ideally we can use some other firmware commands to detect that
voice is
possible on devices that do not support CVOICE.

After a quick search I cannot find a specific command that can be
used
to check if modem+firmware supports voice.
I think that manufacturer deploy a general purpose firmware in most
of
their modems.
I've attached a text file with some test that show voice related at
command can't be used to check if voice is supported or not.
In particular Huawei E172 make voice call but voice related AT
commands
return an error.

I know many modems support the generic voicecall commands, but most
don't have audio hardware at all.  I wasn't aware the E172 had that
voice capabilities in any firmware version, are you sure it has the USB
PCM audio capability like others?
E172 makes call but don't have an audio jack, maybe with a little hack 
with opening the case or something else it can be connected an audio jack.





If we cannot, then I think we have to fall back to udev tags or
something.

Right, if CVOICE is not supported we can enable voice capability
from
udev specifying the audio mode, for example external PCM audio or
CVOICE
mode.
Also when CVOICE is supported we could use external PCM audio using
udev
tags.
Something like ID_MM_HUAWEI_FORCE_EXTAUDIO=1

Since CVOICE only works on Huawei, and only works on some Huawei
devices, obviously we'd need to find other AT commands for other
manufacturers, and/or use udev tags.

I would suggest ID_MM_VOICE_SUPPORTED=1 or something like that, and
make it available to all devices not just Huawei.

Perfect !


The next question is whether these devices should provide anything in
the "Audio Format" and "Audio Port" properties.  I would say no, since
it's very hardware specific and not generally applicable.
Ok, I would suggest "Audio Port" something like "forced" or "User 
request" if voice was enabled by udev tags and all "Audio Format" fields 
set to unknown.


So I will modify the branch to add the ID_MM_VOICE_SUPPORTED tag, and
have that override the CVOICE check in the Huawei plugin.  I just don't
want MM to say "this modem supports voice!" for a device that clearly
has no way to get voice out (like many USB sticks).  I think the
combination of udev tags and plugin-specific probing would make us all
happy.

What do you think?

Ok, it's correct.

Thank you,
Riccardo


dan



Actually master don't check if modem has voice capabilities but
simply
returns an error when you try to make a call.

Right, I changed the check on master to make the CVOICE call for
Huawei
to ensure the modem had voice capability.  Since I only know the
voice
checks for Huawei, that's the only plugin that (in the br

Re: [review] dcbw/huawei-voice

2017-05-04 Thread Riccardo Vangelisti


Hi,
sorry for late reply but we took some time to test this branch using 
these Huawei modems:


+---+-+--+---+
| Modem | Firmware| ^CVOICE Support  | Voice |
+---+-+--+---+
| Huawei ME909s-120 | 11.617.01.00.00 | ^CVOICE: 1, 8000, 16, 20 | Yes  |
| Huawei MU709s-2   | 11.651.67.00.00 | ^CVOICE: 1, 8000, 16, 20 | Yes  |
| Huawei E1150  | 11.609.18.00.00 | ^CVOICE:0,8000,16,20 | Yes  |
+---+-+--+---+

First of all, when ^CVOICE command is not supported by the modem all of 
voice capabilities are disabled.
For example, ME909s and MU709s modems have voice capabilities supported 
by the firmware but voice is disabled anyway.


Our proposal is to use ^CVOICE command only for checking PCM audio port 
capabilities and not for all voice capabilities.
Can voice capabilities be enabled or not using ATH or AT+CHUP command ? 
Actually master don't check if modem has voice capabilities but simply 
returns an error when you try to make a call.


Aleksander, did you check if this branch works on your MU709 dev board ?

Second, we tried to start and receive voice's calls using E1150 (CVOICE 
supported) but no audio coming from /dev/ttyUSB1 (qcdm).

# mmcli -m 0 -o 0

|encoding: 'unknown'
|  resolution: 'unknown'
|rate: 'unknown'

If we make calls using mmcli --command in debug mode and enabling CVOICE 
support (AT^CVOICE=0) and the audio port (AT^DDSETEX=2) all works 
correctly and audio coming from /dev/ttyUSB1.

Example: # cat /dev/ttyUSB1 | aplay -f S16_BE

Dan, could you indicate the correct sequence to make a call when CVOICE 
is supported ? How ModemManager tells me what is the correct device used 
by audio stream ?


Thanks,
Riccardo


Il 18/04/2017 12:29, Aleksander Morgado ha scritto:

On Mon, Apr 17, 2017 at 7:08 PM, Dan Williams  wrote:

Reworked the audio format stuff and added mmcli support.

Removed the 'blocked' stuff and started using 'connected' instead.

Now the larger change: call state handling in mm-base-call.c.  I
removed most of the base class call state setting for the MO (mobile-
originated, eg outgoing) call stuff.  I think the call state handling
there was wrong; only the subclasses know when the call is ringing and
has been picked up (answered) on the remote end through unsolicited
notifications.  So the subclasses must be the ones to update the call
state when they get these notifications, not the base call class.
Huawei calls will now go through UNKNOWN -> DIALING -> RINGING_OUT ->
ACCEPTED, where previously they went UNKNOWN -> RINGING_OUT -> ACTIVE
and at the wrong times.

Eventually we should implement +CLCC (list current calls) polling in
the base class and then we can get this information generically for
subclasses that don't implement unsolicited notifications.  Newer
devices may have support for +CMCCS/+CMCCSI unsolicited notifications
which could also be used in a generic implementation.

Riccardo, Marco, could you guys also review Dan's branch?



___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] Huawei: Ignore unsolicited message ^EONS

2017-03-24 Thread Riccardo Vangelisti


Ops, sorry :)


Il 24/03/2017 15:28, Aleksander Morgado ha scritto:

Hey Riccardo,

On Fri, Mar 24, 2017 at 3:03 PM, Riccardo Vangelisti
<riccardo.vangeli...@sadel.it> wrote:

Hi, I've found an unsolicited message (^EONS) that broke the incoming voice
call in Huawei ME909s-120 modules.
This patch can fix it (simply ignore it).


Could you make sure the patch applies in top of git master and re-send
it in a way I can easily import it? (e.g. git send-email or git
format-patch)

it's currently giving me an error when applying:

$ git am /home/aleksander/\[PATCH\]\ Huawei\:\ Ignore\ unsolicited\
message\ \^EONS.eml
Applying: Huawei: Ignore unsolicited message ^EONS
error: corrupt patch at line 16
Patch failed at 0001 Huawei: Ignore unsolicited message ^EONS
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


From 97891e3eea4d5c25d1e185193e24b5387892673d Mon Sep 17 00:00:00 2001
From: Riccardo Vangelisti <riccardo.vangeli...@sadel.it>
Date: Fri, 24 Mar 2017 15:35:25 +0100
Subject: [PATCH] Huawei: Ignore unsolicited message ^EONS

---
 plugins/huawei/mm-broadband-modem-huawei.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
b/plugins/huawei/mm-broadband-modem-huawei.c
index 0e375e1..4b6ba90 100644
--- a/plugins/huawei/mm-broadband-modem-huawei.c
+++ b/plugins/huawei/mm-broadband-modem-huawei.c
@@ -110,6 +110,7 @@ struct _MMBroadbandModemHuaweiPrivate {
 GRegex *cend_regex;
 GRegex *ddtmf_regex;
 GRegex *cschannelinfo_regex;
+GRegex *eons_regex;
 
 /* Regex to ignore */
 GRegex *boot_regex;
@@ -3149,6 +3150,12 @@ set_voice_unsolicited_events_handlers 
(MMBroadbandModemHuawei *self,
 port,
 self->priv->cschannelinfo_regex,
 NULL, NULL, NULL);
+
+/* Ignore this message (Huawei ME909s-120 firmware. 23.613.61.00.00) */
+mm_port_serial_at_add_unsolicited_msg_handler (
+port,
+self->priv->eons_regex,
+NULL, NULL, NULL);
 }
 
 g_list_free_full (ports, (GDestroyNotify)g_object_unref);
@@ -4474,6 +4481,13 @@ mm_broadband_modem_huawei_init (MMBroadbandModemHuawei 
*self)
 self->priv->cschannelinfo_regex = g_regex_new 
("\\r\\n\\^CSCHANNELINFO:\\s*(\\d+),(\\d+)\\r\\n",
 G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);
 
+/* Voice: Unknown message that's broke ATA command
+ * ^EONS:
+ */
+self->priv->eons_regex = g_regex_new ("\\r\\n\\^EONS:\\s*(\\d+)\\r\\n",
+G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);
+
+
 
 self->priv->ndisdup_support = FEATURE_SUPPORT_UNKNOWN;
 self->priv->rfswitch_support = FEATURE_SUPPORT_UNKNOWN;
@@ -4529,6 +4543,7 @@ finalize (GObject *object)
 g_regex_unref (self->priv->cend_regex);
 g_regex_unref (self->priv->ddtmf_regex);
 g_regex_unref (self->priv->cschannelinfo_regex);
+g_regex_unref (self->priv->eons_regex);
 
 if (self->priv->syscfg_supported_modes)
 g_array_unref (self->priv->syscfg_supported_modes);
-- 
2.11.0

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH] Huawei: Ignore unsolicited message ^EONS

2017-03-24 Thread Riccardo Vangelisti

Hi, I've found an unsolicited message (^EONS) that broke the incoming 
voice call in Huawei ME909s-120 modules.

This patch can fix it (simply ignore it).

diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
b/plugins/huawei/mm-broadband-modem-huawei.c

index 0e375e1..4b6ba90 100644
--- a/plugins/huawei/mm-broadband-modem-huawei.c
+++ b/plugins/huawei/mm-broadband-modem-huawei.c
@@ -110,6 +110,7 @@ struct _MMBroadbandModemHuaweiPrivate {
 GRegex *cend_regex;
 GRegex *ddtmf_regex;
 GRegex *cschannelinfo_regex;
+GRegex *eons_regex;

 /* Regex to ignore */
 GRegex *boot_regex;
@@ -3149,6 +3150,12 @@ set_voice_unsolicited_events_handlers 
(MMBroadbandModemHuawei *self,

 port,
 self->priv->cschannelinfo_regex,
 NULL, NULL, NULL);
+
+/* Ignore this message (Huawei ME909s-120 firmware. 
23.613.61.00.00) */

+mm_port_serial_at_add_unsolicited_msg_handler (
+port,
+self->priv->eons_regex,
+NULL, NULL, NULL);
 }

 g_list_free_full (ports, (GDestroyNotify)g_object_unref);
@@ -4474,6 +4481,13 @@ mm_broadband_modem_huawei_init 
(MMBroadbandModemHuawei *self)
 self->priv->cschannelinfo_regex = g_regex_new 
("\\r\\n\\^CSCHANNELINFO:\\s*(\\d+),(\\d+)\\r\\n",
 G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);


+/* Voice: Unknown message that's broke ATA command
+ * ^EONS:
+ */
+self->priv->eons_regex = g_regex_new ("\\r\\n\\^EONS:\\s*(\\d+)\\r\\n",
+G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);

+
+

 self->priv->ndisdup_support = FEATURE_SUPPORT_UNKNOWN;
 self->priv->rfswitch_support = FEATURE_SUPPORT_UNKNOWN;
@@ -4529,6 +4543,7 @@ finalize (GObject *object)
 g_regex_unref (self->priv->cend_regex);
 g_regex_unref (self->priv->ddtmf_regex);
 g_regex_unref (self->priv->cschannelinfo_regex);
+g_regex_unref (self->priv->eons_regex);

 if (self->priv->syscfg_supported_modes)
 g_array_unref (self->priv->syscfg_supported_modes);


--

*Riccardo Vangelisti*

Software Design Engineering Dept.

*SADEL S.p.A*

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Branch for review: 'riccardo/voice'

2015-06-03 Thread Riccardo Vangelisti


Il 03/06/2015 16:43, Aleksander Morgado ha scritto:

On Wed, Jun 3, 2015 at 4:04 PM, Riccardo Vangelisti
riccardo.vangeli...@sadel.it wrote:

broadband-modem: added voice call support

I'm not sure just checking for ATH is a great indicator of voice
support; most devices I know of will support ATH, but almost none
actually support voice.  Possibly we need plugin-specific checks
instead?  For example I don't think most of the Huawei devices support
voice unless they return ^CVOICE: 1, but they will return OK from ATH.

Ok nice question, we have discussed a bit me and Marco but there isn't an AT
command that confirm the voice call support.
Also there isn't a proprietary Huawei ones.
Actually, if someone use a voice call method will receive an error on
unsupported modules (for example on start method).

Any ideas ?


Yeah, ATH is definitely not a good indicator. I'm not sure what to do
here if we cannot get a good generic AT-based way to detect this
support. Maybe we should just assume it does work and just fail if the
ATD call fails...

For Huawei, didn't the ^CVOICE: 1 check that Dan suggested work?

This command is not mentioned in the AT command user guide (ME709).
However it doesn't work because it returns always ^CVOICE: (0) both on 
ME709 (voice supported) and E3276 (voice non supported), and if you try 
to set it always returns OK.
For example ofono doesn't check if voice is supported or not, it sends a 
lot of AT's command and ignore replies.



api,voice: added DTMF interface specification

How about SendDtmf and DtmfReceived instead?  Seems clearer to me.

Aleksander what do you think ? If you agree, I will change it.

Yes, that is a good change.

Ok we will change it tomorrow



Dan


All changes are pushed on bitbucket.

Didn't check, but did you push your new commits on a new branch based
on the one I created in the MM git repo? Or did the new ones go on top
of the original branch? (I would prefer the former)

Currently we use a new branch voicecall based on riccardo/voice




___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: API Call proposal

2015-05-11 Thread Riccardo Vangelisti


Il 11/05/2015 17:19, Aleksander Morgado ha scritto:

We have tested new mm with these modems:
  * Simcom SIM7250E
  * Telit GT863-PY
  * Falcom Twist
  * Huawei MU709S-2

all modems works ! :)


Quick question; how do all these modems implement the actual voice
channel? Is it a physical audio channel? Is it an audio channel going
through a tty? Or...?
All of these modems have an analog voice channel through a PCM hardware 
codec.




___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: API Call proposal

2015-04-22 Thread Riccardo Vangelisti


Hi all,

I attach'd a new patch and schema with your latest suggestions.

Note that Voice.StateChanged signal has reason argument but, by the 
way, I had to create the MMCallStateChangedReason property in order to 
permits user to retrieve that information also from the call object.
This property is the same that indicates why and how a call terminates. 
So, I've created an enum for each state trasition.


Also, I've removed Audio property as Aleksander suggested.

If you doesn't have any other suggestions, my colleague and I start to 
develop in our branch: 
https://bitbucket.org/riccardovangelisti/modemmanager/branch/voicecall



Riccardo Vangelisti - Sadel SpA
Software Development
Via Serenari 1, Castel Maggiore (BO)

Il 22/04/2015 11:23, Aleksander Morgado ha scritto:

Hey Dan  Riccardo,

Some comments from my side.


For states:

+ * MM_CALL_STATE_UNKNOWN: default state for a new outgoing call

Should we have a MM_CALL_STATE_DIALING in between here for outgoing
calls?  The call isn't really RINGING until the dialing request is
complete, and that can sometimes take 10 seconds or more while network
capacity is being allocated and the circuit set up, especially in busy
cells.


Is this worth? I think it could be cleaner to have DIALING state
applicable only to ongoing calls (i.e. you ATD... and you wait for the
OK/NOCARRIER/BUSY/NODIALTONE response), and then RINGING only for
incoming calls (i.e. you're receiving a new call and the device should
ring).


I think we also need STATE_HELD to indicate when the call is on hold
(see +CHLD docs), and STATE_WAITING (+CCWA).

Ok, I ignored these command! I'll add these states in the next patch.


I actually would only add these whenever we support holding/waiting the call...


The Call.Audio property concerns me a bit, I don't think it provides
enough detail.  What is /dev/ttyUSB3 supposed to be as the Audio
value?  I know on the one Huawei that I have that supports voice, the
serial device just spits out and accepts 16-bit PCM frames, but how
would that be indicated here?  I don't think apps should require a
parallel database of modem voice details.  Also, what does analog
actually mean?  Where does the audio come from or go to?  I think this
part needs more specification and possibly more detail in the API.

I will reply to this as soon as possible. In the meanwhile, what are your
suggestions?
Note that in my case the modem provides an analog output that must not be
handled by software.


I would try to avoid guessing; and therefore I would just target for
now the specific device that is going to be supported first. If this
device for now doesn't need anything software-wise (i.e. the audio
circuit is totally independent), then either we add a property showing
a value which says external or the like, or even, we completely
ignore this and we don't even add a property. Whenever new
implementations that require other info are implemented, then we can
add new properties. What do you guys think? I'm just trying to keep it
simple.


On to Voice...

There are also some meta operations that can be done, like call
transfer, join, multiparty, etc.  Ofono created a VoiceCallManager API
for that purpose, which might be useful to review for .Voice API
additions.

It's true, but maybe these methods could be added later.
My goal is to start a call as soon as possible...


I also agree with this. We should write a minimal API for now, not
targeting transfer/join/multiparty...

But looking at Ofono's API is also something that would be valuable.
Riccardo, could you take a look at this API and compare it with the
proposal we're discussing to see if there are inconsistencies?
Android's API would also be interesting to check.


DeleteCall needs more explanation; obviously it will terminate (hang up,
disconnect) the call and release any resources.  Basically it's just
like Hangup() right?

I thought to use DeleteCall in order to remove a terminated call from the
Voice list property.
Obviously if the call is active, this method should also terminate the call.


Yeah, so the thing here is that we'd be leaving in the list of calls
managed by the Voice API all the call objects that have been generated
in this session, and this includes calls that have been terminated
with a HangUp. So, to let the users of the API clear the list or
specific objects from DBus, the DeleteCall() method would be available
(same as we do e.g. in Messaging API with non-stored sent SMS
messages).


For CallAdded, instead of a boolean, how about just re-using
MM_CALL_DIRECTION?  Also, is the direction argument that interesting
here?  eg, what would a client do when it receives the CallAdded signal
+ direction, if it *doesn't* retrieve the call object properties?
Possibly the argument could be removed if we expect clients to get all
the properties, since eventually we'll have CLIP, phone number,
multiparty, emergency indicator, etc.

Direction is more correct than the bool value, but I prefer to remove

Re: API Call proposal

2015-04-21 Thread Riccardo Vangelisti


  
  
In spite of the last proposal was very similar, for my opinion, to
Messaging/SMS style, I've attach'd
a new patch with your last suggestions. If you think I don't
understand what you said yet, send me your 
modified patch.

Thanks,

Riccardo Vangelisti - Sadel SpA
Software Development
Via Serenari 1, Castel Maggiore (BO)

Il 20/04/2015 19:03, Aleksander Morgado
  ha scritto:


  

  On Mon, Apr 20, 2015 at 6:47 PM,
Riccardo Vangelisti riccardo.vangeli...@sadel.it
wrote:

  Thanks
for you support.

I agree with your opinion and I changed my proposal with
your advices.
I follow the SMS and Messaging implementation and I
create two new interfaces named CallLog and Call.
CallLog contains all Call objects created.

  




  Ouch, no no, this proposal is even
nastier :) I think you didn't understand me.
  
  
  I was suggesting 2 interfaces:
    * "Voice" interface applicable to the
"Modem" object. This one would have the Start(),
Hangup(), Accept()... methods. Also a List() method to
list which are the available call objects. And also the
"Audio" property as well.
    * "Call" interface applicable to a new
"Call" object. This one would have e.g. the Direction
property, the Number property... i.e. all the stuff
applicable to one single call.
  
  
  This would be equivalent to the
Messaging+SMS interfaces (Messaging~Voice, SMS~Call).

 

  
All Call state are described in a schema that I've
attached.

  




  Ah, nice one.
  

 

  
About call type specification, in GSM service there are
two types of call: Voice Call and Data Call.
In AT Standard the ATD command is described as follow:

"ATD[digits][I/i][;]

[...]

When ';' is contained in this command, a voice call is
initiated.
When ';' is not contained in this command, a data
service call is initiated."

Data call is used for example with ZMODEM in order to
trasfer files between two endpoint.

  




  I would completely ignore this and only
support voice calls for now. We should try to write a
minimal API, we can extend it afterwards if the need
ever arises.

  
  
  
  
  -- 
  Aleksander
https://aleksander.es

  


  

From 6842a64860b9e3f52afa1d7d72bd86e489209b95 Mon Sep 17 00:00:00 2001
From: Riccardo Vangelisti riccardo.vangeli...@sadel.it
Date: Tue, 21 Apr 2015 10:04:48 +0200
Subject: [PATCH] Added Modem.Voice and Call interfaces for voice call handling

---
 include/ModemManager-enums.h   |  30 ++
 introspection/all.xml  |   2 +
 .../org.freedesktop.ModemManager1.Call.xml |  49 ++
 .../org.freedesktop.ModemManager1.Modem.Voice.xml  | 105 +
 4 files changed, 186 insertions(+)
 create mode 100644 introspection/org.freedesktop.ModemManager1.Call.xml
 create mode 100644 introspection/org.freedesktop.ModemManager1.Modem.Voice.xml

diff --git a/include/ModemManager-enums.h b/include/ModemManager-enums.h
index 57a2b27..aa61325 100644
--- a/include/ModemManager-enums.h
+++ b/include/ModemManager-enums.h
@@ -1168,4 +1168,34 @@ typedef enum { /* underscore_name=mm_oma_session_state_failed_reason */
 MM_OMA_SESSION_STATE_FAILED_REASON_SESSION_CANCELLED = 5
 } MMOmaSessionStateFailedReason;
 
+/**
+ * MMCallState:
+ * MM_CALL_STATE_UNKNOWN: default state for a new outgoing call
+ * MM_CALL_STATE_RINGING: call is waiting for an answer 
+ * @MM_CALL_STATE_ACCEPTED: call is active between two peers
+ * @MM_CALL_STATE_TERMINATED: call is terminated
+ * @MM_CALL_STATE_REFUSED: call is refused or busy
+ * @MM_CALL_STATE_ERROR: call in error (wrong number, network unavailable, etc..)
+ * 
+ * State of Call
+ */
+typedef enum { /* underscore_name=mm_call_state */
+

API Call proposal

2015-04-20 Thread Riccardo Vangelisti


Hi,
in refer to opened bug https://bugs.freedesktop.org/show_bug.cgi?id=84981
I propose the attached patch, to implement voice or data call in MM core.

Please let me know what you think.

Regards,

--

Riccardo Vangelisti - Sadel SpA
Software Development
Via Serenari 1, Castel Maggiore (BO)

From 6cb13d8396c4e6fa3e6fc8d1e10c73664f3bfd12 Mon Sep 17 00:00:00 2001
From: Riccardo Vangelisti riccardo.vangeli...@sadel.it
Date: Mon, 20 Apr 2015 12:58:16 +0200
Subject: [PATCH] Added API proposal of voice/data call handling

---
 .../org.freedesktop.ModemManager1.Modem.Call.xml   | 118 +
 1 file changed, 118 insertions(+)
 create mode 100644 introspection/org.freedesktop.ModemManager1.Modem.Call.xml

diff --git a/introspection/org.freedesktop.ModemManager1.Modem.Call.xml b/introspection/org.freedesktop.ModemManager1.Modem.Call.xml
new file mode 100644
index 000..3d8e08b
--- /dev/null
+++ b/introspection/org.freedesktop.ModemManager1.Modem.Call.xml
@@ -0,0 +1,118 @@
+?xml version=1.0 encoding=UTF-8 ?
+
+node name=/ xmlns:doc=http://www.freedesktop.org/dbus/1.0/doc.dtd;
+
+  !--
+  org.freedesktop.ModemManager1.Modem.Call:
+  @short_description: The ModemManager Call interface.
+
+  The Call interface handles sending calls and notification of new
+  incoming calls.
+  --
+  interface name=org.freedesktop.ModemManager1.Modem.Call
+
+!--
+Start:
+@number: phone number
+@type: The type of call, same as Type property
+@result: The call object path.
+
+Start a new call to specified number
+--
+method name=Start
+  arg name=number type=s direction=in /
+  arg name=type type=i direction=in /
+  arg name=result type=o direction=out /
+/method
+
+!--
+Answer:
+@call: call object path
+
+Answer to specified call
+--
+method name=Answer
+  arg name=call type=o direction=in /
+/method
+
+!--
+HangUp:
+@call: call object path
+
+Hangup specified call
+--
+method name=HangUp
+  arg name=call type=o direction=in /
+/method
+
+!--
+Incoming:
+@path: Object path of the new Call.
+
+Emitted when a new Call has been received.
+
+Check the Type property to determine if the call is data or voice type.
+--
+signal name=Incoming
+  arg name=path type=o /
+/signal
+
+!--
+StateChanged:
+@old: Old object State
+@new: New object State
+
+Emitted when a message has been deleted.
+--
+signal name=StateChanged
+  arg name=old type=i /
+  arg name=new type=i /
+/signal
+
+!--
+State:
+
+The state of Call object paths.
+
+MMCallState:
+  - MM_MODEM_CALL_STATE_INCOMING Incoming
+  - MM_MODEM_CALL_STATE_ACCEPTED Accepted
+  - MM_MODEM_CALL_STATE_TERMINATED Terminated
+  - MM_MODEM_CALL_STATE_REFUSED Refused
+  - MM_MODEM_CALL_STATE_ERROR Error
+  - MM_MODEM_CALL_STATE_INACTIVE Inactive
+--
+property name=State type=i access=read /
+
+!--
+Type:
+
+The call type.
+
+MMCallType:
+  - MM_MODEM_CALL_TYPE_DATA Data call
+  - MM_MODEM_CALL_TYPE_VOICE Voice call
+--
+property name=Type type=i access=read /
+
+!--
+Number:
+
+The remote phone number.
+--
+property name=Number type=s access=read /
+
+!--
+Audio:
+
+The audio device.
+
+Example list:
+  - analog (PCM analog)
+  - /dev/ttyUSB2 (sound device)
+  - others?
+--
+property name=Audio type=s access=read /
+
+  /interface
+/node
-- 
2.1.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [review] dcbw/huawei-voice

Re: huawei: duplicated DTMF tone

Re: huawei: duplicated DTMF tone

huawei: duplicated DTMF tone

Re: [review] dcbw/huawei-voice

Re: [review] dcbw/huawei-voice

Re: [PATCH] Huawei: Ignore unsolicited message ^EONS

[PATCH] Huawei: Ignore unsolicited message ^EONS

Re: Branch for review: 'riccardo/voice'

Re: API Call proposal

Re: API Call proposal

Re: API Call proposal

API Call proposal

13 matches

Site Navigation

Mail list logo

Footer information