Those patches integrates the future org.bluez.Telephony interface into
oFono for HFP HF and HFP AG plugins.
For HFP AG plugin, the bluetooth rfcomm server is replaced by a
Telephony Agent registered to org.bluez.Telephony.
For HFP HF plugin, RegisterAgent call of org.bluez.HandsfreeGateway is
replaced by the one of org.bluez.Telephony
Since latest RFC :
- add support of org.bluez.MediaTransport interface in emulator.
This allows support of audio related functions with the new
- add support for AT+NREC command
- add support of In-band ring tone (+BSIR event)
- add support of volume management (AT+VGS and AT+VGM commands,
+VGS and +VGM events)
Any comments appreciated.
Frédéric Danis (12):
bluetooth: Add org.bluez.Telephony helpers
hfp_hf: Update to org.bluez.Telephony interface
hfp_ag: Update to org.bluez.Telephony interface
bluetooth: Add org.bluez.MediaTransport interface
include: Add audio transport set API
emulator: Add audio transport set
hfp_ag: Add media transport support
emulator: Add AT+NREC support
emulator: Add +BSIR support
emulator: Add AT+VGM support
emulator: Add AT+VGS support
hfp_ag: Update supported features
include/emulator.h | 3 +
plugins/bluetooth.c | 199 +++++++++++++++++++++++++++++
plugins/bluetooth.h | 15 +++
plugins/hfp_ag.c | 129 +++++++++----------
plugins/hfp_hf.c | 165 +++++++++---------------
src/emulator.c | 348 +++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 686 insertions(+), 173 deletions(-)
From: Jarkko Lehtoranta <devel(a)jlranta.com>
Voice output serial port is enabled on some Huawei models (e.g. E169) without
problems, but for example on E173u-2 it is never enabled during an incoming
call. There might also be other Huawei models having the same issue.
I traced the issue down to "^DDSETEX" AT command, which is used to notify
the device to start streaming audio. It seems that Ofono sends this
command too early on incoming calls. The command should always be sent
*after* the dial "D" or answer "A" command. The patch fixes this behavior
and afterwards voice will also work on E173u-2.
Jarkko Lehtoranta (1):
huawei: fix AT^DDSETEX=2 timing
drivers/huaweimodem/voicecall.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
I'm working on handling errors while receiving an MMS (listed in TODO as
: "Error cases should handled and reported to the application layer." in
MMS Reception section).
What kind of error do you want to report to the application : generic
MMS reception error such as "Unable to decode message", "Unable to
download message" ... or more accurate error (error code, "HTTP error
XXX", "Communication error while downloading message"... ) ?
Since the reception is automatically performed, there is no D-Bus reply
msg to use to send error back to the application !
I cannot always handle the error in 'Message' interface since the D-Bus
object (associated to the message) does not exist before having
downloaded the entire message. More generally, how to handle errors that
occurs before the message D-Bus object has been published ?
Should I define a new signal ("MessageError") in 'Service' interface to
report errors ?
What kind of information the reported error should contain ? the sender
(if the notification has been decoded), the meta file path (if
available) ... ?
Thanks in advance,
This series concerns mmsd for ofono mailing list.
Patch 1 to 3 fix some leaks when a problem arises when a send request is
Patch 4 to 6 fix some mistakes in send message recovery.
Sébastien Bianti (6):
service: remove dead file
service: fixed possible meta with NULL uuid
service: remove pdu without meta
service: request_post_file opens the pdu itself
service: fix some leaks
service: request needs to keep msg
src/service.c | 29 +++++++++++++++++++++++------
1 files changed, 23 insertions(+), 6 deletions(-)
Please find changes in mmsd in order to fix problems that occurred when
1) the messages table contains mms_message object and not uuid, now
every message is unregister with its correct path when the messages
table is destroyed. Furthermore, don't need to remove the message from
the table using g_hash_table_foreach_remove() since
mms_message_unregister() already removed it from the table.
2) use the msg_path (within the debug statement) before removing the
message from the table which free it
Ronald Tessier (2):
service: fix object path when unregistering msg
service: free the msg after tracing its path
src/service.c | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
Please find the changes in order to correct call forwarding states.
Changes from v2:
- Re-run conditional queries on cfu removal and mark cached.
- Handle the caching properly on supplementary services path
unconditional/all/all conditional cfs modifications.
Oleg Zhurakivskyy (12):
call-forwarding: Remove cf_list_clear()
call-forwarding: Inline get_query_next_cf_cond()
call-forwarding: Refactor cf_condition_find_with_cls() slightly
call-forwarding: Refactor cf_find_unconditional()
call-forwarding: Minor cleanup of set_query_cf_callback
call-forwarding: Don't run conditional queries if cfu is active
call-forwarding: Re-run conditional queries on cfu removal
call-forwarding: Toggle the cached flag on CFU changes
call-forwarding: Cache cfs on CFU removal
call-forwarding: Re-run ss path cfs queries on cfu changes
call-forwarding: Cache cfs on all/all conditional removal
TODO: Remove completed call forwarding state task
TODO | 17 ----
src/call-forwarding.c | 237 +++++++++++++++++++++----------------------------
2 files changed, 100 insertions(+), 154 deletions(-)