Yep, we do want to handle this in MM.  What kind of datacard do you have which has this voicecall support?  I do have a Huawei device that supports voicecalls as you describe, though it's about the only datacard that I've found that does, and I had a very hard time finding it on eBay.  The voicecall stuff is also very vendor-specific, so I'm not sure if there are commands to control gain or not.  What we probably want to do is to create a gstreamer plugin that can handle the modem's audio format which the actual voicecall handling program (ekiga, telepathy, whatever) would use for audio in/out.  ModemManager would then expose a D-Bus property for "audio device file" (in this case /dev/ttyUSB2) that the gstreamer plugin could get.  MM would also expose some call management interfaces on D-Bus.

So far starters, we need to put together a call management D-Bus interface for ModemManager and then implement that for the modem plugin that controls your device.  Then we work on a gstreamer plugin.

I did talk to upstream PulseAudio devs about this stuff specifically and their recommendation was *not* to expose the modem as a PA audio device, but to go the gstreamer route, since the audio device is only available when there's an actual call happening, and only MM knows about that and can control it.

If you'd like to work on this, great!  I can definitely provide some pointers if you need more info.

i have zte mf112. not shure, that gstreamer plugin needed in MM.
on windows in harware manager threre is serial port called "%vendorname% audio device", i had not seen another variant. first my idea was to use telepathy, but it complex for me.

first of all i need RING signal from MM. it is not verndor specific and used in first versions of AT commands standart. it must be handled in generic plugin.

i writed draft of gnome-shell plugin. outgoing calls works, but i cant handle incoming calls.

ps. threre is asterisk(voip server) plugin to use datacard. http://code.google.com/p/asterisk-chan-dongle/

Yeah, I've seen that asterisk plugin, and that's what I was using as a reference for my Huawei card that supports voicecall.  WRT the gstreamer plugin, *something* needs to handle the audio interface, and that's not MM because MM isn't a voicechat or conferencing thing.  So obviously the thing that actually reads/writes the audio samples from the device is what needs to know how to talk that protocol.

And you're right, we don't technically need a gstreamer plugin.  But since each modem is different, MM at least needs to export the audio format and audio device via the D-Bus interface in a standardized manner so that the client apps that do handle the actual audio know what to do.  Having an MM-supplied gstreamer plugin that would talk to MM and just present a nice generic gstreamer audio source and sink would be great, but it would use the same D-Bus interface that any other client would use.

But also, since each modem is different, we're not guaranteed that access to the audio device happens in the same manner.  Some modems might use different framing, or some modems might use entirely different protocols (ie, encapsulated audio via a USB control channel instead of exposing an audio device via a serial TTY).  *That's* a nice reason to have a gstreamer plugin, though again that plugin would use the same D-Bus interface as any other client of MM.  It would just be easier to do one gstreamer plugin for all clients than to have each client re-implement the audio processing for X number of modems.

If audio frames are actually routed along the same control channels that MM is already using to talk to the device, then obviously we cannot have some other program also use those channels, and we'd need to have MM proxy the audio frames via D-Bus, or create a fake audio device node, or whatever.  Again, I say this just to point out that just because the ZTE MF112 uses a pretty basic audio interface, that doesn't mean all modems will, and we need to make the MM interface flexible enough for most of them.

But anyway, what needs to happen first is to define the D-Bus API for the voicecall interface, and properties on that interface would include the following:

Audio format: khz, 8-bit/16-bit/24-bit etc, encoding (PCM, raw, etc)
Audio device: Linux device file, if any, otherwise maybe MM has to create a device node and proxy the traffic, in which case the device node would be here
Call start time in seconds since the epoch
Called number

And obviously we need signals like "incoming call" and provisions for caller ID and such as well.  After we get the basics, we need to handle call waiting too.  Some investigation into the API that the Android telephony stack, Ofono, and maybe the Windows Phone stack use would be worthwhile here.

audio routine is not MM business, i think voice conects must to be handled by other manager (Phone Manager). like NM spawns ppp after CONNECT. does MM proxing data then?

lets try to make standard-way, generic, simple?
another realisation may be added in future by if ... else ... patches or plugins, that will replace methods for another modems

dbus api:

method Answer -- sends ATA
signal Ring -- emits then modem prints RING

signal StopRing -- then "STOP RING"
property CallerID  -- indication, followed by RING
property AudioDevice -- returns /dev/ttyUSB2, needs to be implemented in vendor specific plugin
(maybe property AudioMethod -- in plugin)

to property State add "VOICE CONNECT" state

MM should send-recieve AT commands only and i dont want to go into Turing_tarpit

where i can read about architecture of MM? i downloaded sources, but cant find there , for example, ATD is send to modem... dbus layer looks simple, modem interface looks simpler, but layers between confused me. 

ps. sory for my week english...

> 
> where i can read about architecture of MM? i downloaded sources, but cant find
> there , for example, ATD is send to modem... dbus layer looks simple, modem
> interface looks simpler, but layers between confused me. 
> 

There is some online documentation about the ModemManager 1.x architecture in the following link (also in the sources if gtk-doc enabled):
http://www.freedesktop.org/software/ModemManager/api/latest/ref-overview.html

Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue
there as well. Please subscribe to the new bugreport to get new updates.

https://bugs.freedesktop.org/show_bug.cgi?id=84981

Closing this report as NOTGNOME.