Re: [RFC] Add agent API to message atom
Hi,
2010/8/31 Marcel Holtmann mar...@holtmann.org:
+ void RegisterApplicationAgent(object path, uint dest, uint src)
+
+ Registers an agent to receive application messages.
+
+ The object path defines the path of the agent that
+ will be called when an application message is ready
+ to be dispatched.
+
+ The dest parameter is the destination application
+ port number, and the src parameter is the optional
+ source application port number.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.InUse
+
+ void UnregisterAgent(object path)
+
+ Unregisters an agent. If no agent is registered
+ that matches the type of an arriving message, it is
+ silently dropped.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.NotFound
+ [service].Error.NotAuthorized
+
I prefer if we can do a RegisterAgent and UnregisterAgent like we have
in the STK interface. This makes it a lot more consistent throughout the
whole oFono APIs.
Ok.
This of course means that we need a bit more intelligent matching of the
handled types. In general I am against the overhead of regex for this. I
prefer glob style matching with just * and ?. That should be good
enough. If you really need regex pattern matching then then I think a
specialized oFono plugin with its own APIs is the way to go.
This was basically what I was thinking, too, with the addition of ^
and $ for matching at the end or beginning of a message.
+Methods void ImmediateMessage(string message, dict info)
+
+ New immediate (class 0) SMS received. Info has Sender,
+ LocalSentTime, and SentTime information. Sender
+ address is given in string format. LocalSentTime and
+ SentTime are given in string form using ISO8601 format.
Should these really be delivered via an agent?
Why not?
+ void IncomingMessage(string message, dict info)
+
+ New incoming text SMS received. Info has Sender,
+ LocalSentTime, and SentTime information.
+
+ void IncomingPush(array{byte} message, dict info)
+
+ New incoming push message received. Info has Sender,
+ LocalSentTime, SentTime, and ApplicationId information.
+
+ void IncomingApplication(array{byte} message, dict info)
+
+ New incoming application message received. Info has
+ Sender, LocalSentTime, SentTime, DestinationPort, and
+ SourcePort information.
Why the difference between Push and Application. The dict could be
easily used here to differentiate.
True. And in fact we discussed this in IRC with Denis a bit and
decided that separating WAP push makes little sense overall. If the
agent needs to decode the WSP anyway, we're not providing much value
add in oFono just decoding the X-Wap-Application-Id header field. So
the agent might as well just use the application ports to register.
Cheers,
Aki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] Add agent API to message atom
Hi,
2010/8/31 Zhang, Caiwen caiwen.zh...@windriver.com:
+ void RegisterApplicationAgent(object path, uint dest, uint
src)
+
+ Registers an agent to receive application messages.
+
+ The object path defines the path of the agent that
+ will be called when an application message is ready
+ to be dispatched.
+
+ The dest parameter is the destination application
+ port number, and the src parameter is the optional
+ source application port number.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.InUse
+
Push message is a kind of application message. If an agent register both
RegisterPushAgent and RegisterApplicationAgent, will the message be processed
Twice. Will you offer same way to avoid this?
I think we'll just have a single ApplicationAgent interface that works
with app ports. I was thinking it would be elegant to be able to
register an agent only using the WAP app ID, but perhaps that's just a
waste of time.
+ void IncomingMessage(string message, dict info)
+
+ New incoming text SMS received. Info has Sender,
+ LocalSentTime, and SentTime information.
+
Is the 'message' the text content of the income message(I mean the decoded
user data)?
Just the body of the message (UTF-8 string), just like in the signals.
+ void IncomingPush(array{byte} message, dict info)
+
+ New incoming push message received. Info has Sender,
+ LocalSentTime, SentTime, and ApplicationId
information.
+
+ void IncomingApplication(array{byte} message, dict info)
+
+ New incoming application message received. Info has
+ Sender, LocalSentTime, SentTime, DestinationPort, and
+ SourcePort information.
+
Is the 'message' the whole PDU or only the user data?
The user data excluding the user data header, which we decode and
provide in the dict.
+ void Release()
+
+ Agent is being released, possibly because of oFono
+ terminating, the MessageManager interface being torn
+ down or modem powering down.
--
1.7.0.4
Will you consider send push message and application message?
Ah, good point. Yes, we obviously need to support sending binary
messages as well.
Cheers,
Aki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: Atmodem PPP Link establishment issues
Hi Marcel,
Hi Arun,
please try to compose proper emails and not just forward or reply to
your own message to send it again.
We are using atmodem plugin and are trying to get the PPP up and
running. I am able to create and activate context, but the PPP link
establishment seems to have issues.
The list-context script returns:
[ /generic ]
[ /generic/primarycontext3 ]
Username =
Name = Internet access
Settings = { Interface=ppp0 Netmask=255.255.255.255
Method=static DomainNameServers=192.89.123.231,192.89.123.230,
Address=109.240.91.14 }
Active = 1
AccessPointName = internet
Password =
Type = internet
But for a PPP link, there needs to be two ip addresses, one local and
one of the peer. Here in the settings you see only one IP address.
No they don't have to be. Who says so. The second address of PPP is
totally irrelevant since it is a point-to-point link and we do interface
routing (route add default dev ppp0).
I collected the logs during the PPP link establishment, (frames and a
brief detail about it)
Sent from Ofono:
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x21 0x7d 0x21 0x7d 0x20
0x7d 0x2a 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x58 0x7b 0x7e
03 c021 1 (conf req) 1 (id) 0x000a (length) 2 (accm) 6 (length)
fcs
Recv from Modem:
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x21 0x7d 0x21 0x7d 0x20
0x7d 0x34 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x7d 0x25 0x7d 0x26 0xd2 0x8a 0xde 0xd2 0x7d 0x27 0x7d 0x22 0x7d 0x28
0x7d 0x22 0xbf 0x7d 0x35 0x7e
3 c021 1 (conf req) 1 (id) 0x0034 2 6 0 0 0 0 5(magic num) 6 d2 8a de
d2 7(protocol compression) 2 (id) 8 (addr, control compres) 2 fcs
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x22 0x7d 0x21 0x7d 0x20
0x7d 0x2a 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x31 0x7d 0x2f 0x7e
3 c021 2 (conf ack) 1 (id) 0x000a 2 6 0 0 0 0 fcs
Sent from ofono:
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x22 0x7d 0x21 0x7d 0x20
0x7d 0x34 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x7d 0x25 0x7d 0x26 0xd2 0x8a 0xde 0xd2 0x7d 0x27 0x7d 0x22 0x7d 0x28
0x7d 0x22 0x54 0x7c 0x7e
3 c021 2 (conf ack) 1 0x0034 2 6 5 6 d2 8a de d2 7 2 8 2 fcs
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x1 0x0 0x22 0x3 0x6 0x0 0x0 0x0
0x0 0x81 0x6 0x0 0x0 0x0 0x0 0x83 0x6 0x0 0x0 0x0 0x0 0x82 0x6 0x0 0x0
0x0 0x0 0x84 0x6 0x0 0x0 0x0 0x0 0x80 0x52 0x7e
3 8021 1 (conf req) 1 (id) 0x0022 (length) 3 (ip) 6 81(dns1) 6
83(nbns1) 6 82(dns2) 6 84 (nbns2) 6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x3 0x1 0x0 0x10 0x81 0x6 0xa 0xb 0xc
0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x4d 0x4d 0x7e
3 8021 3(conf nak) 1 (id) 0x010 81 (dns1) 6 abcd 83 (dns2) 6 abce fcs
Sent from ofono:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x2 0x0 0x22 0x3 0x6 0x0 0x0 0x0
0x0 0x81 0x6 0xa 0xb 0xc 0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x82 0x6 0x0 0x0
0x0 0x0 0x84 0x6 0x0 0x0 0x0 0x0 0xad 0x7a 0x7e
3 8021 1 (conf ack) 2 (id) 0x0022 3 6 81 6 abcd 83 6 abce 82 6
84 6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x3 0x2 0x0 0x10 0x81 0x6 0xa 0xb 0xc
0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x33 0x95 0x7e
3 8021 3(conf nak) 2 (id) 0x010 81 (dns1) 6 abcd 83 (dns2) 6 abce fcs
Sent from ofono:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x3 0x0 0x22 0x3 0x6 0x0 0x0 0x0
0x0 0x81 0x6 0xa 0xb 0xc 0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x82 0x6 0x0 0x0
0x0 0x0 0x84 0x6 0x0 0x0 0x0 0x0 0xce 0x3a 0x7e
3 8021 1 (conf req) 3 (id) 0x0022 3 6 81 6 abcd 83 6 abce 82 6
84 6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x1 0x0 0x4 0x0 0xb7 0x7e
3 8021 1 (conf req) 1 (id) 0 4 0 fcs
Frame: 0x7e 0xff 0x3 0x80 0x21 0x4 0x3 0x0 0x10 0x82 0x6 0x0 0x0 0x0
0x0 0x84 0x6 0x0 0x0 0x0 0x0 0x34 0xcc 0x7e
3 8021 4 (conf reject) 3(id) 0x0010 82 6 84 6 fcs
Sent from ofono:
Frame: 0xff 0x3 0x80 0x21 0x2 0x1 0x0 0x4 0xcd 0x92 0x7e
3 8021 2 (conf ack) 1 (id) 0 4
Frame: 0xff 0x3 0x80 0x21 0x1 0x4 0x0 0x16 0x3 0x6 0x0 0x0 0x0 0x0
0x81 0x6 0xa 0xb 0xc 0xd 0x83 0x6 0xa 0xb 0xc 0xe 0xe3 0x9 0x7e
3 8021 1 (conf req) 4 (id) 0x0016 3 6 81 6 abcd 83 6 abce fcs
Recv from modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x3 0x4 0x0 0x16 0x3 0x6 0x6d 0xf0 0x40
0xbe 0x81 0x6 0xc0 0x59 0x7b 0xe7 0x83 0x6 0xc0 0x59 0x7b 0xe6 0xc5
0xf1 0x7e
3 8021 3 (conf nak) 4 (id) 0x0016 3 (ip) 6 6d f0 40 be 81 (dns1) 6 c0
59 7b e7 83 (dns2) 6 c0 59 7b e6 fcs
Sent from ofono:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x5 0x0 0x16 0x3 0x6 0x6d 0xf0 0x40
0xbe 0x81 0x6 0xc0 0x59 0x7b 0xe7 0x83 0x6 0xc0 0x59 0x7b 0xe6 0x2
0x9c 0x7e
3 8021 1 (conf req) 5 (id) 0x0016 3 6 6d f0 40 be 81 6 c0 59 7b e7 83
6 c0 59 7b e6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x2 0x5 0x0 0x16 0x3 0x6 0x6d 0xf0 0x40
0xbe 0x81 0x6 0xc0 0x59 0x7b 0xe7 0x83 0x6
Atmodem PPP Link establishment issues
Hi,
We are using atmodem plugin and are trying to get the PPP up and
running. I am able to create and activate context, but the PPP link
establishment seems to have issues.
The list-context script returns:
[ /generic ]
[ /generic/primarycontext3 ]
Username =
Name = Internet access
Settings = { Interface=ppp0 Netmask=255.255.255.255
Method=static DomainNameServers=192.89.123.231,192.89.123.230,
Address=109.240.91.14 }
Active = 1
AccessPointName = internet
Password =
Type = internet
But for a PPP link, there needs to be two ip addresses, one local and
one of the peer. Here in the settings you see only one IP address.
I collected the logs during the PPP link establishment, (frames and a
brief detail about it)
Sent from Ofono:
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x21 0x7d 0x21 0x7d 0x20
0x7d 0x2a 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x58 0x7b 0x7e
03 c021 1 (conf req) 1 (id) 0x000a (length) 2 (accm) 6 (length)
fcs
Recv from Modem:
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x21 0x7d 0x21 0x7d 0x20
0x7d 0x34 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x7d 0x25 0x7d 0x26 0xd2 0x8a 0xde 0xd2 0x7d 0x27 0x7d 0x22 0x7d 0x28
0x7d 0x22 0xbf 0x7d 0x35 0x7e
3 c021 1 (conf req) 1 (id) 0x0034 2 6 0 0 0 0 5(magic num) 6 d2 8a de
d2 7(protocol compression) 2 (id) 8 (addr, control compres) 2 fcs
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x22 0x7d 0x21 0x7d 0x20
0x7d 0x2a 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x31 0x7d 0x2f 0x7e
3 c021 2 (conf ack) 1 (id) 0x000a 2 6 0 0 0 0 fcs
Sent from ofono:
Frame: 0x7e 0xff 0x7d 0x23 0xc0 0x21 0x7d 0x22 0x7d 0x21 0x7d 0x20
0x7d 0x34 0x7d 0x22 0x7d 0x26 0x7d 0x20 0x7d 0x20 0x7d 0x20 0x7d 0x20
0x7d 0x25 0x7d 0x26 0xd2 0x8a 0xde 0xd2 0x7d 0x27 0x7d 0x22 0x7d 0x28
0x7d 0x22 0x54 0x7c 0x7e
3 c021 2 (conf ack) 1 0x0034 2 6 5 6 d2 8a de d2 7 2 8 2 fcs
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x1 0x0 0x22 0x3 0x6 0x0 0x0 0x0
0x0 0x81 0x6 0x0 0x0 0x0 0x0 0x83 0x6 0x0 0x0 0x0 0x0 0x82 0x6 0x0 0x0
0x0 0x0 0x84 0x6 0x0 0x0 0x0 0x0 0x80 0x52 0x7e
3 8021 1 (conf req) 1 (id) 0x0022 (length) 3 (ip) 6 81(dns1) 6
83(nbns1) 6 82(dns2) 6 84 (nbns2) 6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x3 0x1 0x0 0x10 0x81 0x6 0xa 0xb 0xc
0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x4d 0x4d 0x7e
3 8021 3(conf nak) 1 (id) 0x010 81 (dns1) 6 abcd 83 (dns2) 6 abce fcs
Sent from ofono:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x2 0x0 0x22 0x3 0x6 0x0 0x0 0x0
0x0 0x81 0x6 0xa 0xb 0xc 0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x82 0x6 0x0 0x0
0x0 0x0 0x84 0x6 0x0 0x0 0x0 0x0 0xad 0x7a 0x7e
3 8021 1 (conf ack) 2 (id) 0x0022 3 6 81 6 abcd 83 6 abce 82 6
84 6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x3 0x2 0x0 0x10 0x81 0x6 0xa 0xb 0xc
0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x33 0x95 0x7e
3 8021 3(conf nak) 2 (id) 0x010 81 (dns1) 6 abcd 83 (dns2) 6 abce fcs
Sent from ofono:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x3 0x0 0x22 0x3 0x6 0x0 0x0 0x0
0x0 0x81 0x6 0xa 0xb 0xc 0xd 0x83 0x6 0xa 0xb 0xc 0xe 0x82 0x6 0x0 0x0
0x0 0x0 0x84 0x6 0x0 0x0 0x0 0x0 0xce 0x3a 0x7e
3 8021 1 (conf req) 3 (id) 0x0022 3 6 81 6 abcd 83 6 abce 82 6
84 6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x1 0x0 0x4 0x0 0xb7 0x7e
3 8021 1 (conf req) 1 (id) 0 4 0 fcs
Frame: 0x7e 0xff 0x3 0x80 0x21 0x4 0x3 0x0 0x10 0x82 0x6 0x0 0x0 0x0
0x0 0x84 0x6 0x0 0x0 0x0 0x0 0x34 0xcc 0x7e
3 8021 4 (conf reject) 3(id) 0x0010 82 6 84 6 fcs
Sent from ofono:
Frame: 0xff 0x3 0x80 0x21 0x2 0x1 0x0 0x4 0xcd 0x92 0x7e
3 8021 2 (conf ack) 1 (id) 0 4
Frame: 0xff 0x3 0x80 0x21 0x1 0x4 0x0 0x16 0x3 0x6 0x0 0x0 0x0 0x0
0x81 0x6 0xa 0xb 0xc 0xd 0x83 0x6 0xa 0xb 0xc 0xe 0xe3 0x9 0x7e
3 8021 1 (conf req) 4 (id) 0x0016 3 6 81 6 abcd 83 6 abce fcs
Recv from modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x3 0x4 0x0 0x16 0x3 0x6 0x6d 0xf0 0x40
0xbe 0x81 0x6 0xc0 0x59 0x7b 0xe7 0x83 0x6 0xc0 0x59 0x7b 0xe6 0xc5
0xf1 0x7e
3 8021 3 (conf nak) 4 (id) 0x0016 3 (ip) 6 6d f0 40 be 81 (dns1) 6 c0
59 7b e7 83 (dns2) 6 c0 59 7b e6 fcs
Sent from ofono:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x1 0x5 0x0 0x16 0x3 0x6 0x6d 0xf0 0x40
0xbe 0x81 0x6 0xc0 0x59 0x7b 0xe7 0x83 0x6 0xc0 0x59 0x7b 0xe6 0x2
0x9c 0x7e
3 8021 1 (conf req) 5 (id) 0x0016 3 6 6d f0 40 be 81 6 c0 59 7b e7 83
6 c0 59 7b e6 fcs
Recv from Modem:
Frame: 0x7e 0xff 0x3 0x80 0x21 0x2 0x5 0x0 0x16 0x3 0x6 0x6d 0xf0 0x40
0xbe 0x81 0x6 0xc0 0x59 0x7b 0xe7 0x83 0x6 0xc0 0x59 0x7b 0xe6 0xf4
0x6f 0x7e
3 8021 2 (conf ack) 5 (id) 0x0016 3 6 6d f0 40 be 81 6 c0 59 7b e7 83
6 c0 59 7b e6 fcs
I could not find any issues in the state transition w.r.t the RFC, but
I get only one IP address, what is going wrong? Could any one help?
--
RE: Atmodem PPP Link establishment issues
Hi, Please ignore this mail... This was mailed almost 1.5 months back and now it surfaced, at last. We could resolve the PPP issues. Hi Marcel, Hi Arun, please try to compose proper emails and not just forward or reply to your own message to send it again. We are using atmodem plugin and are trying to get the PPP up and running. I am able to create and activate context, but the PPP link establishment seems to have issues. The list-context script returns: Thanks Regards Arun ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v3 1/1] sim: Read EFsst
---
src/sim.c | 40 +--
src/simutil.c | 18
src/simutil.h | 63 +
3 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index fd9b412..ff559a9 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -101,6 +101,8 @@ struct ofono_sim {
unsigned char efust_length;
unsigned char *efest;
unsigned char efest_length;
+ unsigned char *efsst;
+ unsigned char efsst_length;
};
struct msisdn_set_request {
@@ -1072,6 +1074,27 @@ static void sim_retrieve_imsi(struct ofono_sim *sim)
sim-driver-read_imsi(sim, sim_imsi_cb, sim);
}
+static void sim_efsst_read_cb(int ok, int length, int record,
+ const unsigned char *data,
+ int record_length, void *userdata)
+{
+ struct ofono_sim *sim = userdata;
+
+ if (!ok)
+ goto out;
+
+ if (length 2) {
+ ofono_error(EFsst shall contain at least two bytes);
+ goto out;
+ }
+
+ sim-efsst = g_memdup(data, length);
+ sim-efsst_length = length;
+
+out:
+ sim_retrieve_imsi(sim);
+}
+
static void sim_efest_read_cb(int ok, int length, int record,
const unsigned char *data,
int record_length, void *userdata)
@@ -1192,9 +1215,14 @@ static void sim_initialize_after_pin(struct ofono_sim
*sim)
sim_cphs_information_read_cb, sim);
/* Also retrieve the GSM service table */
- ofono_sim_read(sim, SIM_EFUST_FILEID,
- OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
- sim_efust_read_cb, sim);
+ if (sim-phase = OFONO_SIM_PHASE_3G)
+ ofono_sim_read(sim, SIM_EFUST_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
+ sim_efust_read_cb, sim);
+ else
+ ofono_sim_read(sim, SIM_EFSST_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
+ sim_efsst_read_cb, sim);
}
static void sim_pin_query_cb(const struct ofono_error *error,
@@ -2046,6 +2074,12 @@ static void sim_free_state(struct ofono_sim *sim)
sim-efest_length = 0;
}
+ if (sim-efsst) {
+ g_free(sim-efsst);
+ sim-efsst = NULL;
+ sim-efsst_length = 0;
+ }
+
sim-mnc_length = 0;
if (sim-efimg) {
diff --git a/src/simutil.c b/src/simutil.c
index ac054ae..4af6810 100644
--- a/src/simutil.c
+++ b/src/simutil.c
@@ -1434,3 +1434,21 @@ gboolean sim_est_is_active(unsigned char *efest,
unsigned char len,
return (efest[index / 8] (index % 8)) 1;
}
+
+gboolean sim_sst_is_available(unsigned char *efsst, unsigned char len,
+ enum sim_sst_service index)
+{
+ if (index = len * 4u)
+ return FALSE;
+
+ return (efsst[index / 4] ((index % 4) * 2)) 1;
+}
+
+gboolean sim_sst_is_active(unsigned char *efsst, unsigned char len,
+ enum sim_sst_service index)
+{
+ if (index = len * 4u)
+ return FALSE;
+
+ return (efsst[index / 4] (((index % 4) * 2) + 1)) 1;
+}
diff --git a/src/simutil.h b/src/simutil.h
index 65e651a..0a94c67 100644
--- a/src/simutil.h
+++ b/src/simutil.h
@@ -28,6 +28,7 @@ enum sim_fileid {
SIM_EF_CPHS_INFORMATION_FILEID = 0x6f16,
SIM_EF_CPHS_MBDN_FILEID = 0x6f17,
SIM_EFUST_FILEID = 0x6f38,
+ SIM_EFSST_FILEID = 0x6f38, /* same as EFust */
SIM_EFMSISDN_FILEID = 0x6f40,
SIM_EFSPN_FILEID = 0x6f46,
SIM_EFSDN_FILEID = 0x6f49,
@@ -154,6 +155,64 @@ enum sim_est_service {
SIM_EST_SERVICE_ACL = 2
};
+/* 51.011 Section 10.3.7 */
+enum sim_sst_service {
+ SIM_SST_SERVICE_CHV1_DISABLE= 0,
+ SIM_SST_SERVICE_ADN = 1,
+ SIM_SST_SERVICE_FDN = 2,
+ SIM_SST_SERVICE_SMS = 3,
+ SIM_SST_SERVICE_AOC = 4,
+ SIM_SST_SERVICE_CCP = 5,
+ SIM_SST_SERVICE_PLMN_SELECTOR = 6,
+ SIM_SST_SERVICE_MSISDN = 8,
+ SIM_SST_SERVICE_EXT_1 = 9,
+ SIM_SST_SERVICE_EXT_2 = 10,
+ SIM_SST_SERVICE_SMSP= 11,
+ SIM_SST_SERVICE_LND = 12,
+ SIM_SST_SERVICE_CBS_ID = 13,
+ SIM_SST_SERVICE_GROUP_ID_LEVEL_1= 14,
+ SIM_SST_SERVICE_GROUP_ID_LEVEL_2= 15,
+ SIM_SST_SERVICE_PROVIDER_NAME = 16,
+
Re: Clarification on USSD support in ofono
Hi Jeevaka, Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet and sends it to the network. In this way, we will always send the data coding scheme as GSM 7-bit default alphabet or whatever the character set modem is configured. Why are we not sending the USSD string with DCS(Data coding scheme) as is to the network? There are USIM conformance test cases which expects the DCS(Data coding scheme) and USSD string sent as it is to the network. Also, as per the 3GPP TS 24.090, DCS and USSD string are sent as part of UnstructuredSS-Request to the network and MT is not expected to interpret the string. But ,here oFono doesn't have the interface to accept DCS(Data coding scheme) and also it expects the USSD string to be in UTF-8. the one main design goal behind oFono's D-Bus APIs is to make them useful for users. This means that the main input data type are strings and they are UTF-8. If you need magic binary APIs that are only used by specific application or even purely for conformance testing, then you need to propose an interface for these. By default we will not make application to any kind of conversation. Every single nasty conversion that has to be done by every single application using such an interface is wrong. Complexity belongs into oFono and not the application. The idea of just pushing complex tasks up into the application so that oFono doesn't have to deal with it is a really bad idea. Remember that one main goal of oFono is to make the usage of standard telephony functionality as easy as possible when you are developing telephony applications. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Atmodem PPP Link establishment issues
Hi Arun, Please ignore this mail... This was mailed almost 1.5 months back and now it surfaced, at last. We could resolve the PPP issues. okay. So what was the resolution on your side? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Atmodem PPP Link establishment issues
Hi Marcel, Hi Arun, Please ignore this mail... This was mailed almost 1.5 months back and now it surfaced, at last. We could resolve the PPP issues. okay. So what was the resolution on your side? The test scripts available with ofono itself provided the solutions. Regards Arun ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] Add agent API to message atom
Hi Aki,
+ void RegisterApplicationAgent(object path, uint dest, uint
src)
+
+ Registers an agent to receive application messages.
+
+ The object path defines the path of the agent that
+ will be called when an application message is ready
+ to be dispatched.
+
+ The dest parameter is the destination application
+ port number, and the src parameter is the optional
+ source application port number.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.InUse
+
+ void UnregisterAgent(object path)
+
+ Unregisters an agent. If no agent is registered
+ that matches the type of an arriving message, it is
+ silently dropped.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.NotFound
+ [service].Error.NotAuthorized
+
I prefer if we can do a RegisterAgent and UnregisterAgent like we have
in the STK interface. This makes it a lot more consistent throughout the
whole oFono APIs.
Ok.
This of course means that we need a bit more intelligent matching of the
handled types. In general I am against the overhead of regex for this. I
prefer glob style matching with just * and ?. That should be good
enough. If you really need regex pattern matching then then I think a
specialized oFono plugin with its own APIs is the way to go.
This was basically what I was thinking, too, with the addition of ^
and $ for matching at the end or beginning of a message.
within GLib we have glob pattern matching functions, but nothing that
additionally takes ^ and $. Why do you think this would be useful and
needed? How many message agents to you expect to be running that are not
using port numbers? Do you have some examples messages in mind?
+Methods void ImmediateMessage(string message, dict info)
+
+ New immediate (class 0) SMS received. Info has
Sender,
+ LocalSentTime, and SentTime information. Sender
+ address is given in string format. LocalSentTime and
+ SentTime are given in string form using ISO8601
format.
Should these really be delivered via an agent?
Why not?
These class 0 message are special and I think the home screen applet can
just use the current D-Bus signal to deal with them. I don't think that
we need special handling for them.
+ void IncomingMessage(string message, dict info)
+
+ New incoming text SMS received. Info has Sender,
+ LocalSentTime, and SentTime information.
+
+ void IncomingPush(array{byte} message, dict info)
+
+ New incoming push message received. Info has Sender,
+ LocalSentTime, SentTime, and ApplicationId
information.
+
+ void IncomingApplication(array{byte} message, dict info)
+
+ New incoming application message received. Info has
+ Sender, LocalSentTime, SentTime, DestinationPort, and
+ SourcePort information.
Why the difference between Push and Application. The dict could be
easily used here to differentiate.
True. And in fact we discussed this in IRC with Denis a bit and
decided that separating WAP push makes little sense overall. If the
agent needs to decode the WSP anyway, we're not providing much value
add in oFono just decoding the X-Wap-Application-Id header field. So
the agent might as well just use the application ports to register.
Personally I like the idea of doing the whole WSP decoding inside oFono,
but if we have WAP Push over IP transport and the WAP Push daemon has to
do the decoding again anyway, this seems to be not a good idea.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH v2] Add CDMA extension tasks
Hi Caiwen, +CDMA/EVDO += so Denis and I are still discussing some basic details on how to handle CDMA the right way. Especially in case you only have text SMS and non-pdu based SIM Toolkit. I give you an update soon. Is there any update? nothing substantial right now. If the modem manufactures only give you text SMS and non-PDU STK, then we have some serious problems. oFono's internal core talks only PDUs. You would have to do multiple level of conversions to get oFono work with your hardware. Personally I think the interface of your CDMA hardware is broken and should not be used at all. The fact that nobody got text SMS into any kind of consistent state and every single firmware out there has a different bug is a huge problem for us. oFono has to work with every single piece of hardware. I thought that the pure binary interfaces like ISI are a challenge, but that is nothing compared to what you are facing :( Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Marcel,
Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver
- AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet
and sends it to the network. In this way, we will always send the data
coding scheme as GSM 7-bit default alphabet or whatever the character
set modem is configured. Why are we not sending the USSD string with
DCS(Data coding scheme) as is to the network? There are USIM
conformance test cases which expects the DCS(Data coding scheme) and
USSD string sent as it is to the network. Also, as per the 3GPP TS
24.090, DCS and USSD string are sent as part of UnstructuredSS-Request
to the network and MT is not expected to interpret the string.
But ,here oFono doesn't have the interface to accept DCS(Data coding
scheme) and also it expects the USSD string to be in UTF-8.
the one main design goal behind oFono's D-Bus APIs is to make them
useful for users. This means that the main input data type are strings
and they are UTF-8.
If you need magic binary APIs that are only used by specific
application or even purely for conformance testing, then you need to
propose an interface for these. By default we will not make application
to any kind of conversation.
Every single nasty conversion that has to be done by every single
application using such an interface is wrong. Complexity belongs into
oFono and not the application. The idea of just pushing complex
tasks up into the application so that oFono doesn't have to deal with
it is a really bad idea. Remember that one main goal of oFono is to make
the usage of standard telephony functionality as easy as
possible when you are developing telephony applications.
I'm not proposing any changes to the dbus interface and I completely
understand that its a very bad idea to push the conversions to the
application side. USAT conformance specification expects that the
information sent by the application toolkit to be sent as it is to the
network. Conformance test setup is such that if the data received at the
network doesn't match with the data sent by the application toolkit then
the conformance test case is considered to be a failure case.
When a Send USSD proactive command is received, STK atom sends an
internal request to the USSD atom to send the string along with the DCS
supplied. So, for sending the USSD string and dcs received from the
proactive command, support needs to be added to the USSD driver
interface.
What I meant was to provide a driver API which will take both the dcs
and string as parameter. something like the following:
enum ofono_dcs{
OFONO_DCS_UNKNOWN,
OFONO_DCS_GSM_7BIT,
OFONO_DCS_8BIT,
OFONO_DCS_UCS2,
};
void (*request)(struct ofono_ussd *ussd, int dcs, const char *str,
ofono_ussd_cb_t, void *data);
If the dcs is set to OFONO_DCS_UNKNOWN, then the conversion from UTF-8
to GSM 7 bit default alphabet needs to be done. Anything other than
OFONO_DCS_UNKNOWN, modem driver doesn't need to do any conversion and
sends the dcs and string as it is to the network.
Regards,
jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka,
2010/8/31 jeevaka.badrap...@elektrobit.com:
What I meant was to provide a driver API which will take both the dcs
and string as parameter. something like the following:
enum ofono_dcs{
OFONO_DCS_UNKNOWN,
OFONO_DCS_GSM_7BIT,
OFONO_DCS_8BIT,
OFONO_DCS_UCS2,
};
void (*request)(struct ofono_ussd *ussd, int dcs, const char *str,
ofono_ussd_cb_t, void *data);
If the dcs is set to OFONO_DCS_UNKNOWN, then the conversion from UTF-8
to GSM 7 bit default alphabet needs to be done. Anything other than
OFONO_DCS_UNKNOWN, modem driver doesn't need to do any conversion and
sends the dcs and string as it is to the network.
Would it always make sense to do the conversion of the USSD string in
the core, not in the modem driver? So the API would be something like
void (*request)(struct ofono_ussd *ussd, int dcs, void const *data,
size_t len,
ofono_ussd_cb_t, void *data);
--
Pekka.Pessi mail at nokia.com
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] Add agent API to message atom
Hi Aki,
This of course means that we need a bit more intelligent matching of the
handled types. In general I am against the overhead of regex for this. I
prefer glob style matching with just * and ?. That should be good
enough. If you really need regex pattern matching then then I think a
specialized oFono plugin with its own APIs is the way to go.
This was basically what I was thinking, too, with the addition of ^
and $ for matching at the end or beginning of a message.
within GLib we have glob pattern matching functions, but nothing that
additionally takes ^ and $. Why do you think this would be useful and
needed? How many message agents to you expect to be running that are not
using port numbers? Do you have some examples messages in mind?
I'm still not seeing the usefulness of glob/regex matching for text
messages. Are we dealing with some legacy SMS format, like RFC 2822
compatibility? If so, making specific API might be better.
+Methods void ImmediateMessage(string message, dict info)
+
+ New immediate (class 0) SMS received. Info has
Sender,
+ LocalSentTime, and SentTime information. Sender
+ address is given in string format. LocalSentTime and
+ SentTime are given in string form using ISO8601
format.
Should these really be delivered via an agent?
Why not?
These class 0 message are special and I think the home screen applet can
just use the current D-Bus signal to deal with them. I don't think that
we need special handling for them.
I agree with Marcel here, immediate messages are destined for the home
screen and are not even tracked in history.
+ void IncomingMessage(string message, dict info)
+
+ New incoming text SMS received. Info has Sender,
+ LocalSentTime, and SentTime information.
+
+ void IncomingPush(array{byte} message, dict info)
+
+ New incoming push message received. Info has Sender,
+ LocalSentTime, SentTime, and ApplicationId
information.
+
+ void IncomingApplication(array{byte} message, dict info)
+
+ New incoming application message received. Info has
+ Sender, LocalSentTime, SentTime, DestinationPort, and
+ SourcePort information.
Why the difference between Push and Application. The dict could be
easily used here to differentiate.
True. And in fact we discussed this in IRC with Denis a bit and
decided that separating WAP push makes little sense overall. If the
agent needs to decode the WSP anyway, we're not providing much value
add in oFono just decoding the X-Wap-Application-Id header field. So
the agent might as well just use the application ports to register.
Personally I like the idea of doing the whole WSP decoding inside oFono,
but if we have WAP Push over IP transport and the WAP Push daemon has to
do the decoding again anyway, this seems to be not a good idea.
I said almost the same thing on IRC ;)
Someone also mentioned sending of binary SMS messages. I want to avoid
giving applications ability to do that over D-Bus completely. There are
only a few of these that are required, namely Send VCard and Send VCal,
so a dedicated set of methods would be better. If we go in this
direction, then receiving VCards and VCals should also have dedicated
DBus API.
This leaves App/Port addressing useful for WSPs and maybe carrier
specific Visual Voicemail messages. Given that, I'm not entirely
convinced RegisterApplicationAgent is a good idea...
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi, On 31 August 2010 15:59, jeevaka.badrap...@elektrobit.com wrote: If you need magic binary APIs that are only used by specific application or even purely for conformance testing, then you need to propose an interface for these. By default we will not make application to any kind of conversation. Every single nasty conversion that has to be done by every single application using such an interface is wrong. Complexity belongs into oFono and not the application. The idea of just pushing complex tasks up into the application so that oFono doesn't have to deal with it is a really bad idea. Remember that one main goal of oFono is to make the usage of standard telephony functionality as easy as possible when you are developing telephony applications. I'm not proposing any changes to the dbus interface and I completely understand that its a very bad idea to push the conversions to the application side. USAT conformance specification expects that the information sent by the application toolkit to be sent as it is to the network. Conformance test setup is such that if the data received at the network doesn't match with the data sent by the application toolkit then the conformance test case is considered to be a failure case. When a Send USSD proactive command is received, STK atom sends an internal request to the USSD atom to send the string along with the DCS supplied. So, for sending the USSD string and dcs received from the proactive command, support needs to be added to the USSD driver interface. What I meant was to provide a driver API which will take both the dcs and string as parameter. something like the following: Yes, the driver api may need a change like this. The current API was created based on the fact that many modems don't understand anything other than DCS = 15. However with STK's Send USSD command, sending the requested DCS as-is is probably our best bet. There is a hope that most modems implement Send USSD in their firmware so that ofono doesn't have to do anything (this is the case on the Texas Instruments Calypso modem), do you have a modem that you know does not handle Send USSD internally? Of course it makes sense to implement the fallback in ofono anyway. Have you been working on implementation of this command? I'm asking to avoid duplicating the effort. Best regards ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Jeevaka, Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet and sends it to the network. In this way, we will always send the data coding scheme as GSM 7-bit default alphabet or whatever the character set modem is configured. Why are we not sending the USSD string with DCS(Data coding scheme) as is to the network? There are USIM conformance test cases which expects the DCS(Data coding scheme) and USSD string sent as it is to the network. Also, as per the 3GPP TS 24.090, DCS and USSD string are sent as part of UnstructuredSS-Request to the network and MT is not expected to interpret the string. But ,here oFono doesn't have the interface to accept DCS(Data coding scheme) and also it expects the USSD string to be in UTF-8. the one main design goal behind oFono's D-Bus APIs is to make them useful for users. This means that the main input data type are strings and they are UTF-8. If you need magic binary APIs that are only used by specific application or even purely for conformance testing, then you need to propose an interface for these. By default we will not make application to any kind of conversation. Every single nasty conversion that has to be done by every single application using such an interface is wrong. Complexity belongs into oFono and not the application. The idea of just pushing complex tasks up into the application so that oFono doesn't have to deal with it is a really bad idea. Remember that one main goal of oFono is to make the usage of standard telephony functionality as easy as possible when you are developing telephony applications. I'm not proposing any changes to the dbus interface and I completely understand that its a very bad idea to push the conversions to the application side. USAT conformance specification expects that the information sent by the application toolkit to be sent as it is to the network. Conformance test setup is such that if the data received at the network doesn't match with the data sent by the application toolkit then the conformance test case is considered to be a failure case. When a Send USSD proactive command is received, STK atom sends an internal request to the USSD atom to send the string along with the DCS supplied. So, for sending the USSD string and dcs received from the proactive command, support needs to be added to the USSD driver interface. you have me confused now. Are you talking about the D-Bus based API towards applications or the SIM Toolkit support? SIM Toolkit is something totally different. Even for SMS we just deal with raw PDUs there. While the user side applications over D-Bus will never get access to the raw PDUs. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka, On 08/31/2010 03:58 AM, jeevaka.badrap...@elektrobit.com wrote: Hi, Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet and sends it to the network. In this way, we will always send the data coding scheme as GSM 7-bit default alphabet or whatever the character set modem is configured. Why are we not sending the USSD string with DCS(Data coding scheme) as is to the network? There are USIM conformance test cases which expects the DCS(Data coding scheme) and USSD string sent as it is to the network. Also, as per the 3GPP TS 24.090, DCS and USSD string are sent as part of UnstructuredSS-Request to the network and MT is not expected to interpret the string. But ,here oFono doesn't have the interface to accept DCS(Data coding scheme) and also it expects the USSD string to be in UTF-8. The original USSD API actually did look like this. It used binary data + dcs field. However, we quickly found that all modems are screwed up in this area. The specification added binary PDU mode to SMS and CBS, but never bothered with USSD. So all modems get this part wrong. Currently about the best we can do is pass UTF8 around. If you have a modem that gets this part right, we'd like to hear about it. If the Send USSD proactive command is not handled by the modem, then oFono will try to do its best. However, we make no guarantees ;) Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Marcel you have me confused now. Are you talking about the D-Bus based API towards applications or the SIM Toolkit support? SIM Toolkit is something totally different. Even for SMS we just deal with raw PDUs there. While the user side applications over D-Bus will never get access to the raw PDUs. I think I was not clear in my first mail:-). I'm talking about the driver API( Modifications to the ofono_ussd_driver:request). No changes to the D-Bus interface based API towards applications. Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi, Yes, the driver api may need a change like this. The current API was created based on the fact that many modems don't understand anything other than DCS = 15. However with STK's Send USSD command, sending the requested DCS as-is is probably our best bet. There is a hope that most modems implement Send USSD in their firmware so that ofono doesn't have to do anything (this is the case on the Texas Instruments Calypso modem), do you have a modem that you know does not handle Send USSD internally? Of course it makes sense to implement the fallback in ofono anyway. Have you been working on implementation of this command? I'm asking to avoid duplicating the effort. No, I dont have any modem which doesn't handle the Send USSD command internally. Yes, I have done some implementation. Planning to test it with the phonesim. If needed, I can do the implementation of the Send USSD command. Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Denis, The original USSD API actually did look like this. It used binary data + dcs field. However, we quickly found that all modems are screwed up in this area. The specification added binary PDU mode to SMS and CBS, but never bothered with USSD. So all modems get this part wrong. Currently about the best we can do is pass UTF8 around. If you have a modem that gets this part right, we'd like to hear about it. If the Send USSD proactive command is not handled by the modem, then oFono will try to do its best. However, we make no guarantees ;) I think its better to send the dcs and the binary data to the atom driver. If the modem doesn't support other than GSM 7-bit alphabet, then the conversion can be done in the atom driver. This way it will be general to any modem. Let me know your views on this. Regards, jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka, On 08/31/2010 10:48 AM, jeevaka.badrap...@elektrobit.com wrote: Hi Denis, The original USSD API actually did look like this. It used binary data + dcs field. However, we quickly found that all modems are screwed up in this area. The specification added binary PDU mode to SMS and CBS, but never bothered with USSD. So all modems get this part wrong. Currently about the best we can do is pass UTF8 around. If you have a modem that gets this part right, we'd like to hear about it. If the Send USSD proactive command is not handled by the modem, then oFono will try to do its best. However, we make no guarantees ;) I think its better to send the dcs and the binary data to the atom driver. If the modem doesn't support other than GSM 7-bit alphabet, then the conversion can be done in the atom driver. This way it will be general to any modem. The send part is not really the problem, and can be easily done as pdu + dcs. However, it is the reception that is screwed up. By convention, all APIs in oFono must be symmetric. E.g. what the driver sends it must also accept. According to 27.007, +CUSD is converted into the current character set used by CSCS. It is not a binary PDU at all. So the driver now has to fake this information... Go ahead and send your suggested approach as a patch to this mailing list and we can continue from there. Just remember the symmetry part ;) Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka, On 08/31/2010 10:39 AM, jeevaka.badrap...@elektrobit.com wrote: Hi, Yes, the driver api may need a change like this. The current API was created based on the fact that many modems don't understand anything other than DCS = 15. However with STK's Send USSD command, sending the requested DCS as-is is probably our best bet. There is a hope that most modems implement Send USSD in their firmware so that ofono doesn't have to do anything (this is the case on the Texas Instruments Calypso modem), do you have a modem that you know does not handle Send USSD internally? Of course it makes sense to implement the fallback in ofono anyway. Have you been working on implementation of this command? I'm asking to avoid duplicating the effort. No, I dont have any modem which doesn't handle the Send USSD command internally. Yes, I have done some implementation. Planning to test it with the phonesim. If needed, I can do the implementation of the Send USSD command. Can you send what you have so far to the list? Andrew and Yang are actually already looking into this, so it might be nice for the three of you to be on the same page and not duplicate effort. Thanks, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi, Can you send what you have so far to the list? Andrew and Yang are actually already looking into this, so it might be nice for the three of you to be on the same page and not duplicate effort. Ok, I'll try to send the patch by today. Thanks and Regards, Jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v3 1/1] sim: Read EFsst
Hi Yang, On 08/31/2010 04:58 AM, Yang Gu wrote: --- src/sim.c | 40 +-- src/simutil.c | 18 src/simutil.h | 63 + 3 files changed, 118 insertions(+), 3 deletions(-) Patch has been applied, thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] Add agent API to message atom
Hi Marcel, 2010/8/31 Marcel Holtmann mar...@holtmann.org: This was basically what I was thinking, too, with the addition of ^ and $ for matching at the end or beginning of a message. within GLib we have glob pattern matching functions, but nothing that additionally takes ^ and $. Why do you think this would be useful and needed? How many message agents to you expect to be running that are not using port numbers? Do you have some examples messages in mind? There are services that use SMS to send confirmation tokens in messages, and are not using application ports. But they also require the ability to stop such a message ending up in the UI. So perhaps this sort of thing is better done higher up the stack, like in the messaging application itself. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
