These patches implement the new API for the Audio Gateway in BlueZ. It
follows the last version of the HandsfreeGateway and HandsfreeAgent
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.
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
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
+CMT: , 40,
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
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
1111 1100 - 111111 REPLY_SEQ
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
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
30 - User char field 2's remaining 5 bits + User char field 3's 3 bits
60 - User char field 3's remaining 5 bits + User char field 4's 3 bits
80 - User char field 4's remaining 5 bits + Reserved 3 Bits (1000 0000)
Number Fields: 000 00100 - 04 (4 Character fields)
User Char  - 100 00011 - 0x83
User Char  - 000 00110 - 0x06
User Char  - 000 01100 - 0x0C
User Char  - 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
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
Message Type: Deliver (Incoming Message)
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.
These patches implement IPv6 Control Protocol support for gatchat. The implementation is based and following gatchat's IPCP approach.
I tested with gsmdial and test-server, basic cases already work. In case anyone wants to initiate IPv6 CP address negotiation, patches to gsmdial and test-server are included.
These patches aren't complete, things yet to be done:
- Error case (Configure-Reject)
- Connect callback actions
- Proper integration with IPCP
I would appreciate your feedback.
Oleg Zhurakivskyy (1):
gatchat: Add IPv6 CP support
Makefile.am | 2 +-
gatchat/gatppp.c | 58 +++++++++-
gatchat/gatppp.h | 2 +
gatchat/gsmdial.c | 6 +
gatchat/ppp.h | 23 ++++
gatchat/ppp_ipv6cp.c | 306 +++++++++++++++++++++++++++++++++++++++++++++++++
gatchat/test-server.c | 17 +++-
7 files changed, 410 insertions(+), 4 deletions(-)
create mode 100644 gatchat/ppp_ipv6cp.c
First patch is adding cdma-netreg atom watch and status watch.
Second one is using them to check if CDMA modem is registered to the network to activate datacall.
TODO: Manage romaing case whenever it is allowed.
Guillaume Zajac (2):
cdma-netreg: Add various cdma-netreg watches
cdma-connman: Add cdma-netreg status watch to activate data call
include/cdma-netreg.h | 1 +
src/cdma-connman.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++-
src/cdma-netreg.c | 58 ++++++++++++++++++++++++++++++++++++++
src/ofono.h | 13 ++++++++
4 files changed, 144 insertions(+), 2 deletions(-)
2011/2/1 Essi Vehmersalo <essi.vehmersalo at nokia.com>:
> -automatically includes this option.
> +automatically includes this option. See phonesim.conf sample configuration
> +under ofono/plugins on how to configure oFono to use phonesim.
> Run phonesim in foreground using the following options
> # ./src/phonesim -p 12345 -gui src/default.xml
> -Check your modem.conf file and enable the phonesim configuration before
> -executing the above command. Argument -p should be followed by the proper
> -port number, in case you have changed the default "12345". Argument -gui
> -will launch the gui once the modem is enabled.
> +Argument -p should be followed by the proper port number, in case you have
> +changed the default "12345". Argument -gui will launch the gui once the
> +modem is enabled.
A couple of nits: there are some extra whitespace at the end of the
lines, and also, the commit message header should be below 50
Telefon: +49 (33)
- Billige Flüge vergleichen
Trying to get ofono HFP to work on my Ubuntu 11.04 box. I can
connect to the bluetooth device and initiate a voice call, but I can't
hear any audio coming from the speakers.
Went through the
instructions here: http://ofono.org/wiki/hands-free-profile . Saw
something related to configuring pulse audio, but no pointers as to how
to do that-- I do have the pulse audio package installed.
Any help is much appreciated... Let me know if specific logs would help track the issue down.
The modification I did in udevng.c to prevent overiding of the OFONO_LABEL based assignment, could break the default assignment.
I fixed this with this new patch.
Philippe Nunes (5):
udev: Add rules to support ZTE MF668 dongle
udev: Add rules to support ZTE MF190 dongle
udevng.c: tty assignment according OFONO_LABEL should take precedence
udev: Add rules to support Speedup 7300 dongle
udev: Add rules to support SpeedUp 9800 dongle
plugins/ofono.rules | 20 ++++++++++++++++
plugins/udevng.c | 61 +++++++++++++++++++++++++++++++-------------------
2 files changed, 58 insertions(+), 23 deletions(-)
I am currently trying to use ofono and I can not get how to register the
modem in a reliable way.
When I detect a modem, I set org.ofono.Modem.Powered to True.
When SimManager interface is ready, I enter the pin.
Then, I set the modem org.ofono.Modem.Online to True.
By the way, I wait for NetworkRegistration interface to be available.
When it is available, I wait for NetworkRegistration.Name to be non
empty to call NetworkRegistration.Register.
The point is setting Online property usually end with a timeout. It is
the right workflow ? Must I look for other property ?
In a few words, what is the right workflow to get a UMTS modem
registered to its default network from the moment you plug it in ?
Any piece of a clue will be appreciated :)