API Call proposal

Dan Williams dcbw at redhat.com
Mon Apr 20 10:59:53 PDT 2015


On Mon, 2015-04-20 at 19:03 +0200, Aleksander Morgado wrote:
> On Mon, Apr 20, 2015 at 6:47 PM, Riccardo Vangelisti <
> riccardo.vangelisti at 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.​

Agreed.  We probably want to support circuit-switched data calls
eventually, but lets get the voice stuff in first.  I thought perhaps we
could put the CSD stuff into the Bearer/CreateBearer() API, but thinking
about it again the result is not necessarily an IP-level connection but
a raw channel that you could start any kind of protocol over (ZMODEM,
PPP, SLIP, etc).  It's conceptually a data bearer though, but a less
defined one than what we currently consider a bearer.

Dan



More information about the ModemManager-devel mailing list