[RFC] HFP support into oFono and BlueZ
by Gustavo F. Padovan
Hi,
These patches implement the new API for the Audio Gateway in BlueZ. It
follows the last version of the HandsfreeGateway and HandsfreeAgent
Intefaces API.
The first two patches is for BlueZ and the other for oFono. You can
test it with using enable-modem and test-voicecall scripts into the
test dir of oFono.
Feel free to test it and send me your comments. We have some bugs yet.
The audio part is not working yet. We are going to work on pulseaudio
this week to get this done soon.
Regards,
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
7 years, 11 months
CDMA SMS Handling
by Rajesh.Nagaiah＠elektrobit.com
Hi,
There was a discussion about the CDMA SMS handling and CDMA PDUs in the
IRC channel couple of days before. I would like to highlight the
differences between CDMA and GSM PDU and how we should proceed with this
from my understanding. Let me know your opinion.
Even though oFono supports +CMT and +CMTI, if we feed the incoming CDMA
PDUs to the SMS core it wont get decoded correctly, as there is
substantial differences between the GSM and CDMA SMS PDUs as described
in 3GPP2 specification C.S0015-B Short Message Service (SMS) for
Wideband Spread Spectrum Systems
For eg, the incoming PDU example that was mentioned in the IRC
discussion
+CMT: , 40,
00000210020207028CE95DCC65800601FC08150003168D30010610241830608003061010
04044847
40 - Length of the PDU in bytes
00 - Message Type ( 00 - SMS Point-to-Point)
00 - TeleService Identifier Tag (SMS Parameter Indentifier)
02 - TeleService Identifier Length (SMS Parameter Length)
10 - TeleService Identifier Value - First 8 bits
02 - TeleService Identifier Value - Second 8 bits
TeleService Identifier - 0x1002 - CDMA Messaging Teleservice
(CMT-95)
02 - Originating Address Tag
07 - Originating Address Length
02 - Originating Address 1st 8 Bits
8C - Originating Address 2nd 8 Bits
E9 - Originating Address 3rd 8 Bits
5D - Originating Address 4th 8 Bits
CC - Originating Address 5th 8 Bits
65 - Originating Address 6th 8 Bits
80 - Originating Address 7th 8 Bits
Digit Mode - 1 Bit
Number Mode - 1 Bit
Number Type - 0 or 3 bits
Number Plan - 0 or 4 bits
Number Fields - 8 Bits
Number Field occurrence of CHARi
CHARi - 4 or 8 bits ( 4 - in case of DTMF encoding, 8 - incase
of ASCII encoding)
Reserved - 0-7 bits
Lets take the 1st and 2nd 8 bits
02 - 0000 0010 ( Digit Mode bit - 0, Number Mode bit - 0)
8C - 1000 1100
As Digit mode bit is set to 0, Number Plan and Number Type is void
(0 bits) in this case.
So the remaining 6 bits of 1st 8bits and the first 2 bits of 2nd
8bit is Number fields
Number fields - 00 0010 10 - 0000 1010 - 0x0A (10 digits)
As Digit mode bit is set to 0, each address digit here is
represented as 4bit DTMF digit
0x8C 0xE9 0x5D 0xCC 0x65 0X80
1000 1100 1110 1001 0101 1101 1100 1100 0110 0101 1000 0000
10 0011 0011 1010 0101 0111 0111 0011 0001 1001 0110 0000 00
3 3 0 5 7 7 3 1 9 6 Last 6 bits
are reserved bits
Originating Address - 3305773196
06 - Bearer Reply Option Tag
01 - Bearer Reply Option Length
FC - First 6 bits Reply Sequence number and last 2 bits reserved set to
0
1111 1100 - 111111 REPLY_SEQ
00 Reserved
08 - Bearer Data Tag
15 - Bearer Data Length
00 - Message Indentifier Tag ( Bearer Data Sub parameter )
03 - Message Indentifier Length
16 - Message Type 4 bits Message Id 4 Bits
8D - Message Id 8 Bits
30 - Message Id 4 Bits, UDH Header indicator 1 Bit, Reserved 3 Bits
How Message Identifier value 16 8D 30 was formed ?
Message type ( 4 bits ) - 1( 0001 - Deliver)
Message Identifier ( 16 bits ) - 26835( 0x68D3)
Header Indicator (1 bit) - 0 (UDH not present in User Data
Subparameter)
Reserved ( 3bits) - 0 (000)
01 - User Data Tag ( Bearer Data Sub parameter )
06 - User Data Length
10 - Message Encoding 5 bits ( 0001 0000 ( 00010 = 2 -> 7-bit ASCII )) &
Number Fields 3 bits ( 000)
24 - Number Fields 5 Bits + User char field 1's 3 bits ( 0010 0100 )
18 - User char field 1's remaining 5 bits + User char field 2's 3 bits
(0001 1000)
30 - User char field 2's remaining 5 bits + User char field 3's 3 bits
(0011 0000)
60 - User char field 3's remaining 5 bits + User char field 4's 3 bits
(0110 0000)
80 - User char field 4's remaining 5 bits + Reserved 3 Bits (1000 0000)
Number Fields: 000 00100 - 04 (4 Character fields)
User Char [1] - 100 00011 - 0x83
User Char [2] - 000 00110 - 0x06
User Char [3] - 000 01100 - 0x0C
User Char [4] - 000 10000 - 0x10
Hex 0x83 0x06 0x0C 0x10
Octets 1000 0011 0000 0110 0000 1100 0001 0000
Septets 1000 001 10000 01 100000 1 1000001
Character A(0x41) A(0x41) A(0x41) A(0x41)
Message content: AAAA
Message Encoding - 2 (00010 - 5 bits)
Number Fields - 4 (0000 0100 - 8 bits)
User characters - 0x83 0x06 0x0C 0x10 ( 8 bits each)
00010 0000 0100 1000 0011 0000 0110 0000 1100 0001 0000
0001 0000 - 0x10
0010 0100 - 0x24
0001 1000 - 0x18
0011 0000 - 0x30
0110 0000 - 0x60
1000 0000 - 0x80 (Last 3 bits set to 0's(reserved bit) to complete
the octets)
03 - Message Center Time Stamp Tag ( Bearer Data Sub parameter )
06 - Message Center Time Stamp Length
all date and time fields contain two 4-bit BCD numbers giving the
decimal value of the field.
10 - Year (2010)
10 - Month (10 - October)
04 - Day
04 - Hour
48 - Minutes
47 - Seconds
Time Stamp 04:48:47 04/10/2010
Decoded Information:
Message Type: Deliver (Incoming Message)
Teleservice: CMT-95
Message Identifier: 26835
Originating Address: 3305773196
Message content: AAAA
Message Center Time Stamp: 04:48:47 04/10/2010
As from the above decoding example we can see there is substantial
differences between the GSM and CDMA SMS specifications and so the SMS
atom needs many additions and needs to be heavily modified to support
also CDMA SMS handling. Currently the oFono sms file unit handles the
common and the GSM technology aspects of the SMS stack along with the
smsutils. The SMS atom has the GSM specific members, segmentation and
queuing logic. The smsutils mainly takes care of encoding/decoding of
the PDUs, which is GSM specific. As the segmentation and queuing logic
and the interface is common for both GSM and CDMA, we could reuse this
common code and add the CDMA handling into it and create a new
cdmasmsutils unit to support the CDMA SMS specifics, much like the
smsutils does already for GSM.
BR,
Rajesh
8 years, 1 month
[PATCH_v2] atmodem: Fix crash on context activation.
by Guillaume Zajac
Shutdown PPP session if modem did not do it.
---
drivers/atmodem/gprs-context.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/atmodem/gprs-context.c b/drivers/atmodem/gprs-context.c
index 16893ce..100c80b 100644
--- a/drivers/atmodem/gprs-context.c
+++ b/drivers/atmodem/gprs-context.c
@@ -239,6 +239,17 @@ static void at_gprs_activate_primary(struct ofono_gprs_context *gc,
memcpy(gcd->username, ctx->username, sizeof(ctx->username));
memcpy(gcd->password, ctx->password, sizeof(ctx->password));
+ /*
+ * For some modem, mainly Huawei branded, when GPRS is no more attached
+ * to the network, oFono core will reset context although the modem
+ * has not ended ppp sesssion at driver level.
+ * In this case trigger a disconnection manually and send an error.
+ */
+ if (gcd->ppp != NULL && gcd->state == STATE_ACTIVE) {
+ g_at_ppp_shutdown(gcd->ppp);
+ goto error;
+ }
+
gcd->state = STATE_ENABLING;
if (gcd->vendor == OFONO_VENDOR_ZTE) {
--
1.7.4.1
8 years, 3 months
[PATCH] Wavecom Q2403/Q2686 support
by pablo＠gnumonks.org
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
Hi!
The following patch adds support for Wavecom Q2403 and Q2686.
We (the Osmocom team) are using these modems with ofono in our
testbed setup.
Any chance this can be applied to mainstream?
Thank you!
Pablo Neira Ayuso (1):
wavecom: add support for Wavecom Q2403/Q2686 modems
Makefile.am | 3 +
drivers/atmodem/sim.c | 8 ++
drivers/atmodem/sms.c | 31 ++++++--
drivers/atmodem/vendor.h | 1 +
gatchat/gatchat.c | 3 +-
plugins/udev.c | 2 +
plugins/wavecom_q.c | 192 ++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 234 insertions(+), 6 deletions(-)
create mode 100644 plugins/wavecom_q.c
--
1.7.9.5
8 years, 3 months
[PATCH 0/2] mmsd: error management
by Sébastien Bianti
Hi,
The first patch removes the MMS reception part from TODO file which
has been done some times ago.
This model of error management applies also for MMS emission, except that
it shouldn't be silent because initiated by the user.
Sébastien Bianti (2):
TODO: MMS reception error management done
service: emit signal when send has failed
TODO | 13 -------------
src/service.c | 32 ++++++++++++++++++++------------
2 files changed, 20 insertions(+), 25 deletions(-)
--
1.7.4.4
8 years, 3 months
[PATCHv1 0/5] mmsd: GetConversation support
by Ronald Tessier
These patches concern mmsd and implement "GetConversation" D-Bus API.
Ronald Tessier (5):
service: Add GetConversation method
service: Retrieve get_conversation() args
service: Fill conversation list with messages
service: Sort conversation list by message date
doc: Update service-api.txt
doc/service-api.txt | 9 +++-
src/service.c | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 179 insertions(+), 1 deletions(-)
--
1.7.4.1
8 years, 3 months
[RFC v5 00/12] org.bluez.Telephony interface integration
by Frédéric Danis
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 :
- Patch 4
forward declare the structute used in bluetooth plug-in by
bluetooth_set_audio_management() and bluetooth_free_audio_management()
- Patch 5
Fix DBus pending call management in case of HFP emulator unregistration
Remove ofono_emulator_remove_handler() calls
- Patches 9 and 10
Add APIs to set/get data for emulator atom
- Patch 11 (previously 9)
Remove IO watch as data destroyer associated to emulator will be called
on atom removal
RFC v4:
- Patche 1
move agent registration from adapter_added() to adapter_properties_cb()
- Patches 4 to 10:
Rewrote support of AT+NREC, AT+VGM, +VGM, AT+VGS, +VGS and +BSIR into
bluetooth plugin
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 audio APIs for HFP AG
bluetooth: Add AT+NREC support
bluetooth: Add +BSIR support
bluetooth: Add AT+VGM support
bluetooth: Add AT+VGS support
include: add set/get data APIs to emulator
emulator: add set/get data APIs
hfp_ag: Add media transport support
emulator: Update supported features
include/emulator.h | 5 +
plugins/bluetooth.c | 546 +++++++++++++++++++++++++++++++++++++++++++++++++++
plugins/bluetooth.h | 19 ++
plugins/hfp_ag.c | 132 ++++++-------
plugins/hfp_hf.c | 166 ++++++----------
src/emulator.c | 19 ++
6 files changed, 714 insertions(+), 173 deletions(-)
8 years, 3 months
[PATCHv4 00/13] Call forwarding state handling change
by Oleg Zhurakivskyy
Hello,
Please find the changes in order to correct call forwarding states.
Changes from v3:
- Re-run conditional queries on cfu removal and mark cached.
- End querying once cfu is active.
- Handle the caching on supplementary services path
cfs modifications.
Regards,
Oleg
Oleg Zhurakivskyy (13):
call-forwarding: Refactor cf_condition_compare()
call-forwarding: Refactor cf_condition_find_with_cls()
call-forwarding: Get rid of extra variable
call-forwarding: Streamline number assignment
call-forwarding: Streamline cf_find_timeout() logic
call-forwarding: Refactor cf_find_unconditional()
call-forwarding: Streamline set_query_cf_callback()
call-forwarding: Remove unneeded variable
call-forwarding: End querying once cfu is active
call-forwarding: CFU unset, update conditionals
call-forwarding: Re-run ss path queries on CFU unset
call-forwarding: Cache ss TYPE_ALL modifications
TODO: Remove completed call forwarding state task
TODO | 17 -----
src/call-forwarding.c | 168 ++++++++++++++++++++-----------------------------
2 files changed, 68 insertions(+), 117 deletions(-)
--
1.7.5.4
8 years, 3 months
[PATCH v6 00/16] Add DUN support
by Daniel Wagner
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
Hi,
for what it is worth, here is an rebased version. I haven't changed
anything in the code. Some packaging updates such as including the header
file into the distro etc. Also fixed the systemd service file installation.
Changes v6:
- Distro building fixes
- Use dundee instead elect in disconnect-dundee
cheers,
daniel
Daniel Wagner (16):
bluetooth: Add Serial interface definition
dundee: Add documentation
dundee: Add test scripts
dundee: Add skeleton implementation
dundee: Add D-Bus error messages
dundee: Add D-Bus configuration file
dundee: Add systemd configuration file
dundee: Add Manager interface
dundee: Add skeleton implementation for device
dundee: Manager append devices
dundee: Add callback helpers
dundee: Add device un/register
dundee: Add driver helper functions
dundee: Add device D-Bus interface
dundee: Add PPP handling code to device
dundee: Add Bluetooth DUN driver
Makefile.am | 25 ++
bootstrap-configure | 1 +
configure.ac | 7 +-
doc/dundee-api.txt | 76 ++++++
dundee/bluetooth.c | 290 +++++++++++++++++++++
dundee/dbus.c | 45 ++++
dundee/device.c | 646 ++++++++++++++++++++++++++++++++++++++++++++++
dundee/dundee.conf | 23 ++
dundee/dundee.h | 145 +++++++++++
dundee/dundee.service.in | 11 +
dundee/main.c | 256 ++++++++++++++++++
dundee/manager.c | 119 +++++++++
plugins/bluetooth.h | 1 +
test/dundee-connect | 20 ++
test/dundee-disconnect | 20 ++
test/monitor-dundee | 109 ++++++++
16 files changed, 1793 insertions(+), 1 deletion(-)
create mode 100644 doc/dundee-api.txt
create mode 100644 dundee/bluetooth.c
create mode 100644 dundee/dbus.c
create mode 100644 dundee/device.c
create mode 100644 dundee/dundee.conf
create mode 100644 dundee/dundee.h
create mode 100644 dundee/dundee.service.in
create mode 100644 dundee/main.c
create mode 100644 dundee/manager.c
create mode 100755 test/dundee-connect
create mode 100755 test/dundee-disconnect
create mode 100755 test/monitor-dundee
--
1.7.10.rc3.1.gb3065
8 years, 3 months
[PATCH] controlbase: Remove html property from teSMSText
by Oleg Zhurakivskyy
The content of this property adds a few extra newlines
into QTextEdit, which is probably not the intention.
---
src/controlbase.ui | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/src/controlbase.ui b/src/controlbase.ui
index 50315db..ce675d2 100644
--- a/src/controlbase.ui
+++ b/src/controlbase.ui
@@ -746,19 +746,6 @@
<property name="tabChangesFocus">
<bool>true</bool>
</property>
- <property name="html">
- <string><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
-<html><head><meta name="qrichtext" content="1" /><style type="text/css">
-p, li { white-space: pre-wrap; }
-</style></head><body style=" font-family:'Sans Serif'; font-size:9pt; font-weight:400; font-style:normal;">
-<table border="0" style="-qt-table-type: root; margin-top:4px; margin-bottom:4px; margin-left:4px; margin-right:4px;">
-<tr>
-<td style="border: none;">
-<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"></p>
-<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"></p>
-<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"></p>
-<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"></p></td></tr></table></body></html></string>
- </property>
</widget>
</item>
</layout>
--
1.7.5.4
8 years, 3 months
