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 the > property and force user to read the call object properties. > Yes, the signal should only expose the path of the new call object being exposed in DBus. Clients should load the properties they are interested in, and that would include the direction. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
