TODO

   1 Background
   2 ==========
   3
   4 - Priority scale: High, Medium and Low
   5
   6 - Complexity scale: C1, C2, C4 and C8.  The complexity scale is exponential,
   7   with complexity 1 being the lowest complexity.  Complexity is a function
   8   of both task 'complexity' and task 'scope'.
   9
  10   The general rule of thumb is that a complexity 1 task should take 1-2 weeks
  11   for a person very familiar with oFono codebase.  Higher complexity tasks
  12   require more time and have higher uncertainty.
  13
  14   Higher complexity tasks should be refined into several lower complexity tasks
  15   once the task is better understood.
  16
  17
  18 SMS
  19 ===
  20
  21 - Add support for Enhanced SMS (EMS) from 3GPP 23.040.  These SMS messages
  22   support a richer set of formatting elements, including bold/italic and
  23   font size selection.  Embedding images and sounds into the SMS is also
  24   supported.  This task should add support for receiving such SMS messages.
  25
  26   Proposed solution is to convert such messages to HTML and embed image /
  27   sound data as embedded MIME in the generated HTML stream.  The EMS messages
  28   will have to be detected (by the presence of particular tags in the SMS)
  29   and signaled separately from simple SMS messages.
  30
  31   Priority: Low
  32   Complexity: C8
  33
  34 - See / Cancel pending SMS messages over DBus.  When oFono sends SMS messages
  35   the method call is only returned when the message has been submitted to the
  36   network.  Instead we should return an object path and allow cancellation of
  37   pending messages.
  38
  39   Priority: High
  40   Complexity: C2
  41   Owner: Yang Gu <yang.gu@intel.com>
  42
  43 - Persist outgoing SMS messages.  Currently oFono persists incoming messages
  44   that are fragmented.  However oFono does not persist queued outgoing
  45   messages.  oFono should persist such messages and restore / requeue them
  46   on the next oFono startup.
  47
  48   Priority: High
  49   Complexity: C1
  50   Owner: Kristen Carlson Accardi <kristen@linux.intel.com>
  51
  52 - Asynchronously acknowledge SMS DELIVER messages sent by the SMS driver
  53   to core using ofono_sms_deliver_notify().  This may require the struct
  54   ofono_sms_driver to be extended with one more function pointer like:
  55     void (*deliver_ack)(unsigned char *pdu, int len, cb_t cb, void *data)
  56   because currently messages are automatically acknowledged by either the
  57   modem (this is the case of some AT modems) or the driver right after
  58   ofono_sms_deliver_notify() and a failure to deliver at an upper level is
  59   ignored.  The PDU can be an RP-ACK or RP-ERROR message with optional
  60   TP-User-Content element, for example if returned from USIM Data Download.
  61
  62   Priority: Low
  63   Complexity: C2
  64
  65 SIM / SIM File system
  66 =====================
  67
  68 - SIM Call History plugin.  New UICCs support four new SIM elementary files
  69   for storing call history information on the SIM: EFici, EFict, EFoci, EFoct.
  70   A plugin should be developed for oFono that will write to these files.
  71
  72   Priority: Low
  73   Complexity: C2
  74
  75 - Add support for SIM 'ready' notifications from the driver to the core.  Most
  76   modem manufacturers initialize the SIM (e.g. cache SIM file system, STK
  77   initialization, etc) internally before allowing the telephony stack to
  78   access these portions.  When the PIN is locked, this can lead to oFono being
  79   too fast for the modem and asking it for things before the firmware is ready.
  80
  81   The proposal is to introduce a new sim function:
  82     void ofono_sim_ready_notify(struct ofono_sim *sim);
  83
  84   When oFono determines the SIM PIN is READY, it checks whether
  85   ofono_sim_ready_notify has been called.  If it hasn't, then it stalls the
  86   initialization procedure (and calling post_sim) until
  87   ofono_sim_ready_notify is called.
  88
  89   Priority: High
  90   Complexity: C2
  91   Owner: Pekka Pessi <pekka.pessi@nokia.com>
  92
  93 - Check SIM pin status if sim_change_pin fails. If it is anything other than
  94   READY, we must tear the state back to pre_sim state and set the modem offline.
  95
  96   Priority: Medium
  97   Complexity: C1
  98   Owner: Marit Henriksen <marit.henriksen@stericsson.com>
  99
 100 - Add support for CPHS Customer Service Profile (CSP).  This task adds support
 101   for reading the EFcsp file and in particular, interpreting the PLMN mode bit
 102   within the 'Value Added Services' service group.
 103
 104   Based on the PLMN mode value, manual network selection needs to either be
 105   enabled or disabled in the netreg atom.  Also to accommodate this, there
 106   probably needs to be a new 'forced' mode to indicate that manual network
 107   selection is disabled.
 108
 109   Priority: Medium
 110   Complexity: C1
 111   Owner: Aki Niemi <aki.niemi@nokia.com>
 112
 113 Modem Emulator
 114 ==============
 115
 116 - Support HFP AG emulator.  We should provide a new HFP_AG_EMULATOR atom type
 117   that will implement the Bluetooth HFP AG profile.  Voicecall atom, netreg
 118   atoms can register command handlers for this atom appropriately.
 119
 120   Complexity: C4
 121   Priority: Medium
 122   Owner: Frédéric Danis <frederic.danis@linux.intel.com>
 123
 124 - Support extensions to HFP AG emulator.  Some carkits support additional
 125   AT command extensions to the Bluetooth HFP AG standard.  Refer to CE4A
 126   white paper: "AT-commands for Automotive Premium Phone Integration".
 127   Plugins can register additional command handlers appropriately to handle
 128   such commands.
 129
 130   Complexity: C4
 131   Priority: Medium
 132   Depends: HFP AG emulator
 133   Owner: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
 134
 135 - Support HSP AG.  Similar to HFP AG emulator but implements the much reduced
 136   Bluetooth HSP AG profile.
 137
 138   Priority: Low
 139   Complexity: C1
 140
 141 - Support DUN emulator. Implement the Bluetooth DUN profile with only mandatory
 142   AT command support. Implement USB DUN as well.
 143
 144   Complexity: C4
 145   Priority: Medium
 146   Owner: Gustavo F Padovan <padovan@profusion.mobi>
 147
 148   Depends: PPP Server mode
 149
 150 - Support Bluetooth SPP profile.
 151
 152   Complexity: C4
 153   Priority: Medium
 154
 155
 156 Flight Mode
 157 ===========
 158
 159 - Flight Mode support.  Add an 'Online' property to the Modem interface that
 160   will control the online state of the modem.  When Online state is True all
 161   atoms are available.  When Online state is False, all network related items
 162   are removed (e.g. CallSettings) or enter into reduced functionality set
 163   where only the SIM is available (e.g. DataConnectionManager, SimManager, etc)
 164
 165   Complexity: C4
 166   Priority: High
 167   Owner: Pekka Pessi <pekka.pessi@nokia.com>
 168
 169
 170 GPRS
 171 ====
 172
 173 - PPP Server support.  Extend GAtPPP to support PPP Server role, similarly to
 174   how existing GSM modems support PPP GPRS contexts.
 175
 176   Priority: High
 177   Complexity: C2
 178
 179 - IPv6 CP support.  To support IPv6 based GPRS contexts via PPP, GAtPPP
 180   needs to be updated to support IPv6CP from RFC 2472.
 181
 182   Priority: Low
 183   Complexity: C4
 184
 185 - Add support for IPv6 GPRS contexts.
 186
 187   Priority: Medium
 188   Complexity: C1
 189
 190
 191 Location Services
 192 =================
 193
 194 - Neighbor Cell Info.  Add dedicated atom, D-Bus API and atom driver(s) for
 195   Neighbor Cell information.
 196
 197   This feature is not discussed in 27.007, thus manufacturer specific commands
 198   are required.
 199
 200   Complexity: C4
 201   Priority: Medium
 202   Owner: Antti Paila <antti.paila@nokia.com>
 203
 204
 205 Supplementary Services
 206 ======================
 207
 208 - Closed User Group (CUG) support.
 209
 210   Priority: Low
 211   Complexity: C8
 212
 213 - Call Completion to Busy Subscriber (CCBS) support
 214
 215   This feature is not discussed in 27.007, thus manufacturer specific commands
 216   are required.
 217
 218   Priority: Low
 219   Complexity: C8
 220
 221 - User to User Signaling (UUS) support
 222
 223   Priority: Low
 224   Complexity: C8
 225
 226 - Multiple Subscriber Profile (MSP) support
 227
 228   Priority: Low
 229   Complexity: C2
 230
 231 - Called Line Identification.  This affects both call_settings and voicecall
 232   atoms.  3GPP service is accessed by the +CDIP command.
 233
 234   Priority: Low
 235   Complexity: C4
 236   Owner: Lucas De Marchi <lucas.demarchi@profusion.mobi>
 237
 238 - CPHS Support.  This includes ALS and CPHS specific elementary files.
 239
 240   Priority: Low
 241   Complexity: C8
 242
 243
 244 Voicecall
 245 =========
 246
 247 - Supplementary service notifications on remote party actions:
 248   - call has been put on hold (+CSSU: 2)
 249   - call has been retrieved (+CSSU: 3), and
 250   - joining call to a multiparty conference (+CSSU: 4)
 251
 252   Priority: Medium
 253   Complexity: C1
 254   Owner: Pekka Pessi <pekka.pessi@nokia.com>
 255
 256 - Long phone numbers. According to 3GPP TS 24.008, the callee address
 257   can be up to 80 digits long.
 258
 259   Priority: Medium
 260   Complexity: C2
 261   Owner: Rafael Ignacio Zurita <rafael.zurita@profusion.mobi>
 262
 263 - Dial strings. Include CLIR prefixes and 2nd stage dial strings in the
 264   DialString call property. Add dialstring accessor method to C API.
 265
 266   Priority: Medium
 267   Complexity: C4
 268
 269 - Provide feedback of sent DTMF tones. Emit SendingTones signal if modem can
 270   provide approximate starting and stopping times for DTMF tones. Signal
 271   argument contains a string of DTMF tones to be sent, or empty string when
 272   all tones has been sent.
 273
 274   Priority: Medium
 275   Complexity: C2
 276   Owner: Pekka Pessi <pekka.pessi@nokia.com>
 277
 278 - Blacklisting. According to 3GPP TS 22.001 annex E, the TE must provide
 279   automatic calling repeat call attempt restrictions.
 280
 281   There should be a method to manually reset blacklisting.
 282
 283   Priority: Medium
 284   Complexity: C1
 285
 286
 287 Sim Toolkit
 288 ===========
 289
 290 - Support Refresh proactive command.  The specification defines 7 types
 291   of Refresh types:
 292         - NAA Initialization
 293         - NAA File Change Notification
 294         - NAA Initialization and File Change Notification
 295         - NAA Initialization and Full File Change Notification
 296         - UICC Reset
 297         - NAA Application Reset (2G only)
 298         - NAA Session Reset (3G only)
 299
 300   The 'NAA Initialization' type will be ignored by oFono, it is assumed
 301   this is handled by the modem.
 302
 303   For 'UICC Reset', 'NAA Application Reset' and 'NAA Session Reset' oFono
 304   will first check whether there are any calls or ussd operations active.
 305   If there are, the appropriate response will be sent (e.g. busy on call
 306   or screen busy terminal response.)  Otherwise a positive response will be
 307   sent to the driver.  In the case of a 'UICC Reset' the driver / modem
 308   can interpret this that it is safe to reset the UICC.
 309
 310   Alternatively, the driver / modem can notify the core of the SIM removal
 311   / SIM insertion events without using the Refresh proactive command.  It
 312   is up to the driver / modem to perform a warm reset.  In particular, 3GPP
 313   31.111 mandates that any change to EFimsi is done by using 'UICC Reset',
 314   'NAA Application Reset' or 'NAA Session Reset'.  Please see 3GPP 31.111
 315   Section 6.4.7.1.
 316
 317   Other types will be handled by oFono flushing the EF cache of the files
 318   affected (or the entire SIM cache in case of Full File Change Notifications)
 319   and re-reading the affected files.  Any properties derived from these
 320   Elementary Files will be updated and signaled using PropertyChanged.
 321
 322   Priority: High
 323   Complexity: C8
 324
 325
 326 Emergency Calls
 327 ===============
 328
 329 - Modem Emergency mode.  Support network registration and online/offline
 330   mode during the emergency calls and related network activity (e.g.,
 331   network-initiated location request via supplementary service channel).
 332
 333   Proposed solution is to introduce a new Emergency boolean property to the
 334   Modem D-Bus interface and new functions to modem interface:
 335
 336   - ofono_modem_emergency_mode_inc()
 337   - ofono_modem_emergency_mode_dec()
 338   - ofono_modem_emergency_mode_get()
 339   - ofono_modem_add_emergency_mode_watch()
 340   - ofono_modem_remove_emergency_mode_watch()
 341
 342   When emergency mode is requested, modem is set to online (if needed) and
 343   the watchers are notified. There can be multiple parties requesting
 344   emergency mode.  When all of them have completed the emergency-related
 345   operation and called ofono_modem_emergency_mode_dec(), modem is set to
 346   offline (if needed) and the watchers are again notified.
 347
 348   Priority: High
 349   Complexity: C2
 350
 351 - Country / Operator specific emergency numbers.  Figure out how to support
 352   countries / operators with specific mandated emergency numbers which are
 353   not part of the standard emergency number list. This needs to be queried
 354   by the voicecall atom every time a new SIM is inserted.  The list is
 355   assumed to be managed by the modem.  If no such functionality is available,
 356   then the 3GPP mandated behavior is used.
 357
 358   Priority: High
 359   Complexity: C2
 360
 361 - Network updating the emergency number list. Support the list of emergency
 362   numbers dynamically updated by the network.
 363
 364   Priority: High
 365   Complexity: C2
 366   Owner: Petteri Tikander <petteri.tikander@ixonos.com>
 367
 368
 369 Miscellaneous
 370 =============
 371
 372 - Bluetooth SAP Client support.  The Telit UC864-G devices support Bluetooth
 373   SAP client mode.  This requires the use of a modem side-channel to read the
 374   APDU & CPDU data and send it to the remote phone device over Bluetooth RFCOMM
 375   channel.
 376
 377   Complexity: C4
 378   Priority: Low
 379
 380 - PolicyKit support.  Add support for PolicyKit checking of all oFono D-Bus
 381   interfaces.
 382
 383   Complexity: C4
 384   Priority: Low
 385
 386 - Internet Access Provider database.  Have oFono automatically configure
 387   GPRS contexts based on an internal database.  Database format to be decided.
 388   If there are multiple matches in the database, then some user intervention
 389   might be required.
 390
 391   Priority: Medium
 392   Complexity: C8
 393   Owner: Jukka Saunamäki <jukka.saunamaki@nokia.com>
 394
 395 - Add support for GPS power control atom.  Many modem manufacturers provide
 396   a GPS unit with their modem hardware.  This unit can be turned on or off
 397   and frequently takes over one of the tty ports that the modem provides.
 398
 399   This feature is not discussed in 27.007, thus manufacturer specific commands
 400   are required.
 401
 402   Priority: Low
 403   Complexity: C4
 404   Owner: Rafael Ignacio Zurita <rafael.zurita@profusion.mobi>
 405
 406 - Add Location Service API for providing basic E911 support.
 407   This will be based on the 27.007 defined AT commands using
 408   XML for transport of positioning request and responses.
 409
 410   Priority: Medium
 411   Complexity: C2
 412   Owner: Sjur Brændeland <sjur.brandeland@stericsson.com>
 413
 414 - Add support for main.conf.  This task will add support for general
 415   as well as per-atom configuration options that are read and parsed
 416   at startup from a configuration file under /etc/ofono.
 417
 418   Priority: Medium
 419   Complexity: C1
 420   Owner: Aki Niemi <aki.niemi@nokia.com>
 421
 422 CDMA Voicecall
 423 ==============
 424
 425 - Add support for Mobile Originated and Mobile Terminated Voice Call over
 426   a CDMA network. This includes management of call state and providing
 427   appropriate values for the LineIdentification in each case.
 428
 429   Priority: High
 430   Complexity: C2
 431   Owner: Dara Spieker-Doyle <dara.spieker-doyle@nokia.com>
 432
 433 - Add support for Three-Way Calling over a CDMA network. Three-Way Calling
 434   provides the subscriber with the capability to add a third party to an
 435   established two-party call, so that all three parties may communicate in a
 436   three-way call.
 437
 438   In CDMA mode, the originating subscriber of a current conversation can
 439   request for a third party to be added to a conversation by sending a Flash
 440   With Information Message (FWIM) with dialed digits to the network. Upon
 441   setting up a two-way conversation with the added party, the originating
 442   subscriber can request to establish a three-way conversation by sending
 443   another Flash With Information Message. Upon receiving the second Flash With
 444   Information Message, the MSC reconnects the original party to the
 445   conversation thus completing the setup of a three-way conversation.
 446
 447   CDMA Three-Way Calling is described by Figure B-5 in 3GPP2 C.S0005-E Version
 448   2.0.
 449
 450   Priority: High
 451   Complexity: C2
 452
 453 - Add support for Call Waiting over a CDMA network. Call Waiting (CW) provides
 454   notification of an incoming call to an originating subscriber, while the
 455   subscriber's call is in the 2-way state. Subsequently, the originating
 456   subscriber can either answer or ignore the incoming call. If the originating
 457   subscriber answers the second call, it may alternate between the two calls.
 458
 459   In CDMA mode, the originating subscriber of a current conversation will
 460   receive either a Flash With Information Message or an Alert With Information
 461   Message from the network if there is an additional mobile terminated voice
 462   call incoming. The originating subscriber can change conversation parties by
 463   sending a Flash With Information Message to the network and the MSC will
 464   toggle the speech path between the two conversations.
 465
 466   CDMA Call Waiting is described by Figure B-6 in 3GPP2 C.S0005-E Version
 467   2.0.
 468
 469   Priority: High
 470   Complexity: C2
 471
 472 - Support sending DTMF tones over CDMA network.
 473
 474   Priority: High
 475   Complexity: C2
 476
 477 - Support optional network-based Plus Code Dialing for international calls over
 478   a CDMA network. An input key, e.g. the "+" key, or a functional equivalent
 479   can be used to replace the international access prefix when dialing. When
 480   received, transmitted or stored, an international indicator can be included
 481   with the address digits although it is the responsibility of the network to
 482   ignore the international indicator when attached to a national number. This
 483   is described in Section 2.7.1.3.2.4 of 3GPP2 C.S0005-E v2.0 and Section 1.2
 484   of 3GPP2 N.S0027 v1.0.
 485
 486   Priority: High
 487   Complexity: C2
 488
 489 CDMA SMS
 490 ==============
 491
 492 - Support CDMA SMS stack in PDU mode. This includes basic support of
 493   SMS Point-to-Point Message, SMS Broadcast Message and SMS Acknowledge
 494   Message as per 3GPP2 C.S0015-B version 2.0.
 495
 496   Priority: High
 497   Complexity: C4
 498
 499 - Support sending Wireless Messaging Teleservice (WMT) Submit Message and
 500   receiving WMT Deliver Message as defined 3GPP2 C.S0015-B version 2.0.
 501
 502   Priority: High
 503   Complexity: C4
 504
 505 - Support Delivery Acknowledgment. oFono allows requesting of CDMA SMS
 506   Delivery Acknowledgment via the MessageManager's
 507   UseDeliveryAcknowledgement property. If enabled, oFono's CDMA SMS stack
 508   will encode the Reply Option subparameter in the Submit message and
 509   process incoming SMS Delivery Acknowledgment Message. oFono will notify
 510   UI either via DBus or history plugin API.
 511
 512   Priority: Medium
 513   Complexity: C2
 514
 515 - Support receiving Voice Mail Notification (VMN) Teleservice Deliver
 516   message. CDMA network uses VMN Teleservice to deliver the number of
 517   messages stored at the Voice Mail System to the CDMA mobile subscriber.
 518
 519   Priority: High
 520   Complexity: C4
 521
 522 - Support sending Wireless Enhanced Messaging Teleservice (WEMT) Submit
 523   Message and receiving WEMT Deliver Messsage as defined 3GPP2 C.S0015-B
 524   version 2.0.
 525
 526   WMT does not support message fragmentation thus can not be used to for
 527   long message. WEMT is devised to support long message and Enhanced
 528   Messaging Service (EMS). The WEMT SMS message's CHARi field of the
 529   subparameter User Data encapsulate GSM-SMS TP-User Data as defined in
 530   Section 9.2.3.24 of 3GPP TS 23.040.
 531
 532   Priority: Medium
 533   Complexity: C4
 534
 535 - Support sending Wireless Application Protocol (WAP) Teleservice Submit
 536   Message and receiving WAP Deliver Messsage as defined 3GPP2 C.S0015-B
 537   version 2.0.
 538
 539   Priority: Medium
 540   Complexity: C4
 541
 542 - Support Call-Back Number. The Call-Back Number subparameter indicates
 543   the number to be dialed in reply to a received SMS message.
 544
 545   In transmit direction, oFono allows setting of Call-Back Number. If the
 546   Call Back Number property is set, CDMA SMS stack will encode Call-Back
 547   Number subparameter in the Submit Message.
 548
 549   In receiving direction, oFono will process the Call-Back Number
 550   subparameter in the incoming Deliver Message and notify UI of the
 551   Call-Back Number together with the newly received text message.
 552
 553   Priority: Medium
 554   Complexity: C2
 555
 556 - Support immediately displayed message. oFono CDMA SMS stack will
 557   process the optional Message Display Mode subparameter in the incoming
 558   SMS message. If Message Display Mode subparameter indicates the
 559   message display mode is Immediate Display, oFono will send
 560   ImmediateMessage signal, otherwise oFono will send IncomingMessage
 561   signal.
 562
 563   Priority: Medium
 564   Complexity: C2
 565
 566
 567 CDMA CMAS
 568 ==============
 569
 570 - Support Commercial Mobile Alert Service (CMAS) over CDMA systems. CMAS
 571   over CDMA system is defined in TIA-1149. The CMAS message is carried in
 572   the CHARi field of the User Data subparameter of CDMA SMS Broadcast
 573   message.
 574
 575   Priority: Medium
 576   Complexity: C4
 577
 578 CDMA NETWORK ACQUISITION
 579 ========================
 580
 581 - Support reporting of the received signal strength indicator (RSSI)
 582   measurement and of the pilot energy ratio (Ec/Io) measurement, for the
 583   currently acquired CDMA network.
 584
 585   Priority: Medium
 586   Complexity: C1
 587   Owner: Dara Spieker-Doyle <dara.spieker-doyle@nokia.com>
 588
 589 - Support reporting of the received signal strength indicator (RSSI)
 590   measurement and of the signal to interference-plus-noise ratio (SINR)
 591   measurement, for the currently acquired 1xEV-DO data network.
 592
 593   Priority: Medium
 594   Complexity: C1
 595
 596 - Support reporting of the Enhanced Roaming Indicators (ERI) to indicate the
 597   current roaming condition of the CDMA mobile device. Each indicator maps to
 598   a unique display number within the Standard and Non-Standard service ranges,
 599   as described in Section 8 of 3GPP2 C.R1001-C v1.0.
 600   These numbers are stored on the device in the (Enhanced) Preferred Roaming
 601   List (PRL) and it is the responsibility of the modem to broadcast the
 602   relevant indicator for a currently acquired system. Further details of the
 603   system acquisition process are described in 3GPP2 C.S0016-B v1.0.
 604
 605   Priority: Medium
 606   Complexity: C2
 607
 608 - Support reporting of identifiers of the currently acquired CDMA network,
 609   including the System Identifier (SID) and the Network Identifier (NID),
 610   It is the responsibility of the modem to broadcast the relevant identifiers
 611   for a currently acquired system, and these identifiers are provided by the
 612   network. This is described in 3GPP2 C.S0005-E v2.0.
 613
 614   Priority: Medium
 615   Complexity: C2
 616
 617 - Support International Roaming, including support for reporting the Mobile
 618   Country Code (MCC) and the Mobile Network Code (MNC) for the currently
 619   acquired network. International Roaming is provided via enhancements to the
 620   PRL by encoding the MCC and the (two digit only) MNC in existing SID/NID
 621   fields, as described in the CDMA Development Group standards Document "IPRL
 622   Enhancements for International Roaming - CDG Doc #86". It is the
 623   responsibility of the modem to broadcast the values for the currently
 624   acquired system.
 625
 626   Priority: Medium
 627   Complexity: C2