[Announce] Intel and Nokia announce open source telephony project (oFono)

[Announce] Intel and Nokia announce open source telephony project (oFono)

[Aki Niemi]

Intel and Nokia are pleased to jointly announce the oFono project
(http://ofono.org), an open source project for developing an open source
telephony solution.

oFono.org is a place to bring developers together around designing an
infrastructure for building mobile telephony (GSM/UMTS) applications.
oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
API for use by telephony applications of any license.  oFono.org also
includes a low-level plug-in API for integrating with Open Source as
well as third party telephony stacks, cellular modems and storage
back-ends.  The plug-in API functionality is modeled on public
standards, in particular 3GPP TS 27.007 "AT command set for User
Equipment (UE)."

Source code is available on http://ofono.org/downloads and a high-level
architecture diagram is available on http://ofono.org/documentation.  To
join the mailing list, go to http://lists.ofono.org/listinfo/ofono.

Nokia and Intel will jointly maintain the oFono project.  We'd like to
invite all developers to join the oFono.org effort and community.

Marcel Holtmann <holtmann@linux.intel.com>, Intel Open Source Technology
Center
Aki Niemi <aki.niemi@nokia.com>, Nokia Devices R&D, Maemo Software

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Dan Williams]

On Mon, 2009-05-11 at 21:34 +0300, Aki Niemi wrote:
> Intel and Nokia are pleased to jointly announce the oFono project
> (http://ofono.org), an open source project for developing an open source
> telephony solution.
> 
> oFono.org is a place to bring developers together around designing an
> infrastructure for building mobile telephony (GSM/UMTS) applications.
> oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> API for use by telephony applications of any license.  oFono.org also
> includes a low-level plug-in API for integrating with Open Source as
> well as third party telephony stacks, cellular modems and storage
> back-ends.  The plug-in API functionality is modeled on public
> standards, in particular 3GPP TS 27.007 "AT command set for User
> Equipment (UE)."
> 
> Source code is available on http://ofono.org/downloads and a high-level
> architecture diagram is available on http://ofono.org/documentation.  To
> join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> 
> Nokia and Intel will jointly maintain the oFono project.  We'd like to
> invite all developers to join the oFono.org effort and community.

So a few questions...

- Where's the IS-707/IS-856 support?  Yes, many operators will be
transitioning to LTE by 2015, but there are 450 million CDMA subscribers
right now [1], and that number is expected to grow.  Having two modem
control stacks simply isn't an option.  Not having designed support for
CDMA into the service seems pretty short-sighted.  I know Nokia itself
doesn't care about CDMA any more, but still...

- GPS support?  In reality, there can only be one service arbitrating
access to modem serial ports, since not all serial-based modems provide
more than two ports, and one of those must be used for PPP, and the
other for signal strength, etc.  Logically, the service controlling
these ports for cellular should also be handling GPS requests on these
devices.

- Is there some reason we cannot coalesce around *one* userland cellular
service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
gsmd (C+dbus) already; it seems that for the sake of users, it would be
great to concentrate that effort in *one* place so that we don't have to
keep quirking every single modem in 4 different places.  TBH, I don't
care which one it is, as long as (a) it has a sane D-Bus interface, (b)
it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.

Dan

[1] http://www.cdg.org/technology/cdma_technology/cdma_stats.asp

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Marcel Holtmann]

Hi Dan,

> > Intel and Nokia are pleased to jointly announce the oFono project
> > (http://ofono.org), an open source project for developing an open source
> > telephony solution.
> > 
> > oFono.org is a place to bring developers together around designing an
> > infrastructure for building mobile telephony (GSM/UMTS) applications.
> > oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> > API for use by telephony applications of any license.  oFono.org also
> > includes a low-level plug-in API for integrating with Open Source as
> > well as third party telephony stacks, cellular modems and storage
> > back-ends.  The plug-in API functionality is modeled on public
> > standards, in particular 3GPP TS 27.007 "AT command set for User
> > Equipment (UE)."
> > 
> > Source code is available on http://ofono.org/downloads and a high-level
> > architecture diagram is available on http://ofono.org/documentation.  To
> > join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> > 
> > Nokia and Intel will jointly maintain the oFono project.  We'd like to
> > invite all developers to join the oFono.org effort and community.
> 
> So a few questions...
> 
> - Where's the IS-707/IS-856 support?  Yes, many operators will be
> transitioning to LTE by 2015, but there are 450 million CDMA subscribers
> right now [1], and that number is expected to grow.  Having two modem
> control stacks simply isn't an option.  Not having designed support for
> CDMA into the service seems pretty short-sighted.  I know Nokia itself
> doesn't care about CDMA any more, but still...

we did talk about CDMA voice support and so far nobody of us had good
enough experience with how it works on the voice level. Let me assure
you that we wanna definitely allow support for it.

> - GPS support?  In reality, there can only be one service arbitrating
> access to modem serial ports, since not all serial-based modems provide
> more than two ports, and one of those must be used for PPP, and the
> other for signal strength, etc.  Logically, the service controlling
> these ports for cellular should also be handling GPS requests on these
> devices.

I talked with our designers and engineers about it and we do see the
need to handle this properly for modem devices where the control part is
the same for the modem. We need to figure out on how to integrate this
properly with Gypsy. Advantage of oFono is that it has a generic plugin
infrastructure.

> - Is there some reason we cannot coalesce around *one* userland cellular
> service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
> gsmd (C+dbus) already; it seems that for the sake of users, it would be
> great to concentrate that effort in *one* place so that we don't have to
> keep quirking every single modem in 4 different places.  TBH, I don't
> care which one it is, as long as (a) it has a sane D-Bus interface, (b)
> it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.

I think that the basic modem detection/quirking has to be done with your
modem id tool from udev-extras.

Please keep in mind that oFono is also for voice call features and hence
has to integrate native with BlueZ and PulseAudio. We wanna create a
full features open source telephony stack.

Regards

Marcel

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Dan Williams]

On Mon, 2009-05-11 at 14:05 -0700, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > Intel and Nokia are pleased to jointly announce the oFono project
> > > (http://ofono.org), an open source project for developing an open source
> > > telephony solution.
> > > 
> > > oFono.org is a place to bring developers together around designing an
> > > infrastructure for building mobile telephony (GSM/UMTS) applications.
> > > oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> > > API for use by telephony applications of any license.  oFono.org also
> > > includes a low-level plug-in API for integrating with Open Source as
> > > well as third party telephony stacks, cellular modems and storage
> > > back-ends.  The plug-in API functionality is modeled on public
> > > standards, in particular 3GPP TS 27.007 "AT command set for User
> > > Equipment (UE)."
> > > 
> > > Source code is available on http://ofono.org/downloads and a high-level
> > > architecture diagram is available on http://ofono.org/documentation.  To
> > > join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> > > 
> > > Nokia and Intel will jointly maintain the oFono project.  We'd like to
> > > invite all developers to join the oFono.org effort and community.
> > 
> > So a few questions...
> > 
> > - Where's the IS-707/IS-856 support?  Yes, many operators will be
> > transitioning to LTE by 2015, but there are 450 million CDMA subscribers
> > right now [1], and that number is expected to grow.  Having two modem
> > control stacks simply isn't an option.  Not having designed support for
> > CDMA into the service seems pretty short-sighted.  I know Nokia itself
> > doesn't care about CDMA any more, but still...
> 
> we did talk about CDMA voice support and so far nobody of us had good
> enough experience with how it works on the voice level. Let me assure
> you that we wanna definitely allow support for it.

I meant data, not voice...  What I'd like to know (and I couldn't find
out from looking for the introspection data, or missing API
specification) is whether you've made provisions for CDMA devices in the
D-Bus API.

> > - GPS support?  In reality, there can only be one service arbitrating
> > access to modem serial ports, since not all serial-based modems provide
> > more than two ports, and one of those must be used for PPP, and the
> > other for signal strength, etc.  Logically, the service controlling
> > these ports for cellular should also be handling GPS requests on these
> > devices.
> 
> I talked with our designers and engineers about it and we do see the
> need to handle this properly for modem devices where the control part is
> the same for the modem. We need to figure out on how to integrate this
> properly with Gypsy. Advantage of oFono is that it has a generic plugin
> infrastructure.

I'd expect services like ModemManager or ofono to implement a standard
GPS D-Bus interface that consumers of GPS information could query as
long as they are pointed at the right bus name.  GPS queries are
specific to the modem in question.

> > - Is there some reason we cannot coalesce around *one* userland cellular
> > service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
> > gsmd (C+dbus) already; it seems that for the sake of users, it would be
> > great to concentrate that effort in *one* place so that we don't have to
> > keep quirking every single modem in 4 different places.  TBH, I don't
> > care which one it is, as long as (a) it has a sane D-Bus interface, (b)
> > it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.
> 
> I think that the basic modem detection/quirking has to be done with your
> modem id tool from udev-extras.

I think you misunderstand the scope of modem quirking.  Please read
something like:

http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/

There are like 5 different ways to specify 2G/3G preference; and while
having a plugin system is nice and solves it for a *single* modem
manager, the question I was asking was why we cannot all work on a
single modem manager service and do all this hardware support in one
place.

The situation we have now is like Linux vs. Solaris vs NetBSD vs
FreeBSD.  All can drive the same hardware, but you have to write support
for the same hardware in each different OS, though copy & paste helps
between the BSDs at least.

Why have to duplicate hardware support in 4 different places?  Why can
we not coalesce around one stack?  Why write a different stack when
there are existing ones that already work, where the voice support could
have been added?

Dan

> Please keep in mind that oFono is also for voice call features and hence
> has to integrate native with BlueZ and PulseAudio. We wanna create a
> full features open source telephony stack.
> 
> Regards
> 
> Marcel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Marcel Holtmann]

Hi Dan,

> > > > Intel and Nokia are pleased to jointly announce the oFono project
> > > > (http://ofono.org), an open source project for developing an open source
> > > > telephony solution.
> > > > 
> > > > oFono.org is a place to bring developers together around designing an
> > > > infrastructure for building mobile telephony (GSM/UMTS) applications.
> > > > oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> > > > API for use by telephony applications of any license.  oFono.org also
> > > > includes a low-level plug-in API for integrating with Open Source as
> > > > well as third party telephony stacks, cellular modems and storage
> > > > back-ends.  The plug-in API functionality is modeled on public
> > > > standards, in particular 3GPP TS 27.007 "AT command set for User
> > > > Equipment (UE)."
> > > > 
> > > > Source code is available on http://ofono.org/downloads and a high-level
> > > > architecture diagram is available on http://ofono.org/documentation.  To
> > > > join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> > > > 
> > > > Nokia and Intel will jointly maintain the oFono project.  We'd like to
> > > > invite all developers to join the oFono.org effort and community.
> > > 
> > > So a few questions...
> > > 
> > > - Where's the IS-707/IS-856 support?  Yes, many operators will be
> > > transitioning to LTE by 2015, but there are 450 million CDMA subscribers
> > > right now [1], and that number is expected to grow.  Having two modem
> > > control stacks simply isn't an option.  Not having designed support for
> > > CDMA into the service seems pretty short-sighted.  I know Nokia itself
> > > doesn't care about CDMA any more, but still...
> > 
> > we did talk about CDMA voice support and so far nobody of us had good
> > enough experience with how it works on the voice level. Let me assure
> > you that we wanna definitely allow support for it.
> 
> I meant data, not voice...  What I'd like to know (and I couldn't find
> out from looking for the introspection data, or missing API
> specification) is whether you've made provisions for CDMA devices in the
> D-Bus API.

so far not much time has been spent to integrate the data part. We are
concentrating on getting voice going.

We want CDMA support for voice and data, but as I said, most of us are
not using that technology on a regular basis. We haven't forgotten about
it though :)

> > > - GPS support?  In reality, there can only be one service arbitrating
> > > access to modem serial ports, since not all serial-based modems provide
> > > more than two ports, and one of those must be used for PPP, and the
> > > other for signal strength, etc.  Logically, the service controlling
> > > these ports for cellular should also be handling GPS requests on these
> > > devices.
> > 
> > I talked with our designers and engineers about it and we do see the
> > need to handle this properly for modem devices where the control part is
> > the same for the modem. We need to figure out on how to integrate this
> > properly with Gypsy. Advantage of oFono is that it has a generic plugin
> > infrastructure.
> 
> I'd expect services like ModemManager or ofono to implement a standard
> GPS D-Bus interface that consumers of GPS information could query as
> long as they are pointed at the right bus name.  GPS queries are
> specific to the modem in question.

It is not that simple. Let me ensure you that I am aware of this mess
with mixing GPS and modem hardware and their control endpoints. For us
the Gypsy has the better interfaces in conjunction with GeoClue.

On a side note here. We also wanna support proper cell tower
triangulation for location based services.

> > > - Is there some reason we cannot coalesce around *one* userland cellular
> > > service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
> > > gsmd (C+dbus) already; it seems that for the sake of users, it would be
> > > great to concentrate that effort in *one* place so that we don't have to
> > > keep quirking every single modem in 4 different places.  TBH, I don't
> > > care which one it is, as long as (a) it has a sane D-Bus interface, (b)
> > > it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.
> > 
> > I think that the basic modem detection/quirking has to be done with your
> > modem id tool from udev-extras.
> 
> I think you misunderstand the scope of modem quirking.  Please read
> something like:
> 
> http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/
> 
> There are like 5 different ways to specify 2G/3G preference; and while
> having a plugin system is nice and solves it for a *single* modem
> manager, the question I was asking was why we cannot all work on a
> single modem manager service and do all this hardware support in one
> place.
> 
> The situation we have now is like Linux vs. Solaris vs NetBSD vs
> FreeBSD.  All can drive the same hardware, but you have to write support
> for the same hardware in each different OS, though copy & paste helps
> between the BSDs at least.
> 
> Why have to duplicate hardware support in 4 different places?  Why can
> we not coalesce around one stack?  Why write a different stack when
> there are existing ones that already work, where the voice support could
> have been added?

We are currently deriving from voice features and there was nothing that
satisfied us. Especially when it comes to support fully non AT modem
drivers. Cellphones do use special cellular modem protocols. For example
the ones from Nokia.

Regards

Marcel

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Dan Williams]

On Mon, 2009-05-11 at 16:22 -0700, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > Intel and Nokia are pleased to jointly announce the oFono project
> > > > > (http://ofono.org), an open source project for developing an open source
> > > > > telephony solution.
> > > > > 
> > > > > oFono.org is a place to bring developers together around designing an
> > > > > infrastructure for building mobile telephony (GSM/UMTS) applications.
> > > > > oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> > > > > API for use by telephony applications of any license.  oFono.org also
> > > > > includes a low-level plug-in API for integrating with Open Source as
> > > > > well as third party telephony stacks, cellular modems and storage
> > > > > back-ends.  The plug-in API functionality is modeled on public
> > > > > standards, in particular 3GPP TS 27.007 "AT command set for User
> > > > > Equipment (UE)."
> > > > > 
> > > > > Source code is available on http://ofono.org/downloads and a high-level
> > > > > architecture diagram is available on http://ofono.org/documentation.  To
> > > > > join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> > > > > 
> > > > > Nokia and Intel will jointly maintain the oFono project.  We'd like to
> > > > > invite all developers to join the oFono.org effort and community.
> > > > 
> > > > So a few questions...
> > > > 
> > > > - Where's the IS-707/IS-856 support?  Yes, many operators will be
> > > > transitioning to LTE by 2015, but there are 450 million CDMA subscribers
> > > > right now [1], and that number is expected to grow.  Having two modem
> > > > control stacks simply isn't an option.  Not having designed support for
> > > > CDMA into the service seems pretty short-sighted.  I know Nokia itself
> > > > doesn't care about CDMA any more, but still...
> > > 
> > > we did talk about CDMA voice support and so far nobody of us had good
> > > enough experience with how it works on the voice level. Let me assure
> > > you that we wanna definitely allow support for it.
> > 
> > I meant data, not voice...  What I'd like to know (and I couldn't find
> > out from looking for the introspection data, or missing API
> > specification) is whether you've made provisions for CDMA devices in the
> > D-Bus API.
> 
> so far not much time has been spent to integrate the data part. We are
> concentrating on getting voice going.
> 
> We want CDMA support for voice and data, but as I said, most of us are
> not using that technology on a regular basis. We haven't forgotten about
> it though :)
> 
> > > > - GPS support?  In reality, there can only be one service arbitrating
> > > > access to modem serial ports, since not all serial-based modems provide
> > > > more than two ports, and one of those must be used for PPP, and the
> > > > other for signal strength, etc.  Logically, the service controlling
> > > > these ports for cellular should also be handling GPS requests on these
> > > > devices.
> > > 
> > > I talked with our designers and engineers about it and we do see the
> > > need to handle this properly for modem devices where the control part is
> > > the same for the modem. We need to figure out on how to integrate this
> > > properly with Gypsy. Advantage of oFono is that it has a generic plugin
> > > infrastructure.
> > 
> > I'd expect services like ModemManager or ofono to implement a standard
> > GPS D-Bus interface that consumers of GPS information could query as
> > long as they are pointed at the right bus name.  GPS queries are
> > specific to the modem in question.
> 
> It is not that simple. Let me ensure you that I am aware of this mess
> with mixing GPS and modem hardware and their control endpoints. For us
> the Gypsy has the better interfaces in conjunction with GeoClue.
> 
> On a side note here. We also wanna support proper cell tower
> triangulation for location based services.
> 
> > > > - Is there some reason we cannot coalesce around *one* userland cellular
> > > > service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
> > > > gsmd (C+dbus) already; it seems that for the sake of users, it would be
> > > > great to concentrate that effort in *one* place so that we don't have to
> > > > keep quirking every single modem in 4 different places.  TBH, I don't
> > > > care which one it is, as long as (a) it has a sane D-Bus interface, (b)
> > > > it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.
> > > 
> > > I think that the basic modem detection/quirking has to be done with your
> > > modem id tool from udev-extras.
> > 
> > I think you misunderstand the scope of modem quirking.  Please read
> > something like:
> > 
> > http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/
> > 
> > There are like 5 different ways to specify 2G/3G preference; and while
> > having a plugin system is nice and solves it for a *single* modem
> > manager, the question I was asking was why we cannot all work on a
> > single modem manager service and do all this hardware support in one
> > place.
> > 
> > The situation we have now is like Linux vs. Solaris vs NetBSD vs
> > FreeBSD.  All can drive the same hardware, but you have to write support
> > for the same hardware in each different OS, though copy & paste helps
> > between the BSDs at least.
> > 
> > Why have to duplicate hardware support in 4 different places?  Why can
> > we not coalesce around one stack?  Why write a different stack when
> > there are existing ones that already work, where the voice support could
> > have been added?
> 
> We are currently deriving from voice features and there was nothing that
> satisfied us. Especially when it comes to support fully non AT modem
> drivers. Cellphones do use special cellular modem protocols. For example
> the ones from Nokia.

Right, so why couldn't Phonenet support be added to something like
ModemManager, which also uses a plugin-based infrastructure and does not
expose AT stuff over the D-Bus interface?

What we have here is a huge duplication of effort, yet again.

Dan

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Dan Williams]

On Mon, 2009-05-11 at 16:22 -0700, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > Intel and Nokia are pleased to jointly announce the oFono project
> > > > > (http://ofono.org), an open source project for developing an open source
> > > > > telephony solution.
> > > > > 
> > > > > oFono.org is a place to bring developers together around designing an
> > > > > infrastructure for building mobile telephony (GSM/UMTS) applications.
> > > > > oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> > > > > API for use by telephony applications of any license.  oFono.org also
> > > > > includes a low-level plug-in API for integrating with Open Source as
> > > > > well as third party telephony stacks, cellular modems and storage
> > > > > back-ends.  The plug-in API functionality is modeled on public
> > > > > standards, in particular 3GPP TS 27.007 "AT command set for User
> > > > > Equipment (UE)."
> > > > > 
> > > > > Source code is available on http://ofono.org/downloads and a high-level
> > > > > architecture diagram is available on http://ofono.org/documentation.  To
> > > > > join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> > > > > 
> > > > > Nokia and Intel will jointly maintain the oFono project.  We'd like to
> > > > > invite all developers to join the oFono.org effort and community.
> > > > 
> > > > So a few questions...
> > > > 
> > > > - Where's the IS-707/IS-856 support?  Yes, many operators will be
> > > > transitioning to LTE by 2015, but there are 450 million CDMA subscribers
> > > > right now [1], and that number is expected to grow.  Having two modem
> > > > control stacks simply isn't an option.  Not having designed support for
> > > > CDMA into the service seems pretty short-sighted.  I know Nokia itself
> > > > doesn't care about CDMA any more, but still...
> > > 
> > > we did talk about CDMA voice support and so far nobody of us had good
> > > enough experience with how it works on the voice level. Let me assure
> > > you that we wanna definitely allow support for it.
> > 
> > I meant data, not voice...  What I'd like to know (and I couldn't find
> > out from looking for the introspection data, or missing API
> > specification) is whether you've made provisions for CDMA devices in the
> > D-Bus API.
> 
> so far not much time has been spent to integrate the data part. We are
> concentrating on getting voice going.
> 
> We want CDMA support for voice and data, but as I said, most of us are
> not using that technology on a regular basis. We haven't forgotten about
> it though :)

So even though I had Sprint when I started 3G support in NM, I went out
and got a T-Mobile plan.  I now spend $55 a month to ensure that GSM
*and* CDMA both work with NetworkManager and ModemManager.  If you're
serious about actually supporting the technology that's out there, I'd
recommend putting your money where your mouth is and picking up a data
plan with Sprint or Verizon and just figuring it out.  It's not that
hard.

But it still comes back to the question of:  why was an existing tool
not sufficient, or why could an existing service not be updated with
voice support?  In the end it's your decision, but splitting effort
makes the baby jeebus cry.

Dan

> > > > - GPS support?  In reality, there can only be one service arbitrating
> > > > access to modem serial ports, since not all serial-based modems provide
> > > > more than two ports, and one of those must be used for PPP, and the
> > > > other for signal strength, etc.  Logically, the service controlling
> > > > these ports for cellular should also be handling GPS requests on these
> > > > devices.
> > > 
> > > I talked with our designers and engineers about it and we do see the
> > > need to handle this properly for modem devices where the control part is
> > > the same for the modem. We need to figure out on how to integrate this
> > > properly with Gypsy. Advantage of oFono is that it has a generic plugin
> > > infrastructure.
> > 
> > I'd expect services like ModemManager or ofono to implement a standard
> > GPS D-Bus interface that consumers of GPS information could query as
> > long as they are pointed at the right bus name.  GPS queries are
> > specific to the modem in question.
> 
> It is not that simple. Let me ensure you that I am aware of this mess
> with mixing GPS and modem hardware and their control endpoints. For us
> the Gypsy has the better interfaces in conjunction with GeoClue.
> 
> On a side note here. We also wanna support proper cell tower
> triangulation for location based services.
> 
> > > > - Is there some reason we cannot coalesce around *one* userland cellular
> > > > service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
> > > > gsmd (C+dbus) already; it seems that for the sake of users, it would be
> > > > great to concentrate that effort in *one* place so that we don't have to
> > > > keep quirking every single modem in 4 different places.  TBH, I don't
> > > > care which one it is, as long as (a) it has a sane D-Bus interface, (b)
> > > > it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.
> > > 
> > > I think that the basic modem detection/quirking has to be done with your
> > > modem id tool from udev-extras.
> > 
> > I think you misunderstand the scope of modem quirking.  Please read
> > something like:
> > 
> > http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/
> > 
> > There are like 5 different ways to specify 2G/3G preference; and while
> > having a plugin system is nice and solves it for a *single* modem
> > manager, the question I was asking was why we cannot all work on a
> > single modem manager service and do all this hardware support in one
> > place.
> > 
> > The situation we have now is like Linux vs. Solaris vs NetBSD vs
> > FreeBSD.  All can drive the same hardware, but you have to write support
> > for the same hardware in each different OS, though copy & paste helps
> > between the BSDs at least.
> > 
> > Why have to duplicate hardware support in 4 different places?  Why can
> > we not coalesce around one stack?  Why write a different stack when
> > there are existing ones that already work, where the voice support could
> > have been added?
> 
> We are currently deriving from voice features and there was nothing that
> satisfied us. Especially when it comes to support fully non AT modem
> drivers. Cellphones do use special cellular modem protocols. For example
> the ones from Nokia.
> 
> Regards
> 
> Marcel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Announce] Intel and Nokia announce open source telephony project (oFono)

[Dan Williams]

On Mon, 2009-05-11 at 16:22 -0700, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > Intel and Nokia are pleased to jointly announce the oFono project
> > > > > (http://ofono.org), an open source project for developing an open source
> > > > > telephony solution.
> > > > > 
> > > > > oFono.org is a place to bring developers together around designing an
> > > > > infrastructure for building mobile telephony (GSM/UMTS) applications.
> > > > > oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
> > > > > API for use by telephony applications of any license.  oFono.org also
> > > > > includes a low-level plug-in API for integrating with Open Source as
> > > > > well as third party telephony stacks, cellular modems and storage
> > > > > back-ends.  The plug-in API functionality is modeled on public
> > > > > standards, in particular 3GPP TS 27.007 "AT command set for User
> > > > > Equipment (UE)."
> > > > > 
> > > > > Source code is available on http://ofono.org/downloads and a high-level
> > > > > architecture diagram is available on http://ofono.org/documentation.  To
> > > > > join the mailing list, go to http://lists.ofono.org/listinfo/ofono.
> > > > > 
> > > > > Nokia and Intel will jointly maintain the oFono project.  We'd like to
> > > > > invite all developers to join the oFono.org effort and community.
> > > > 
> > > > So a few questions...
> > > > 
> > > > - Where's the IS-707/IS-856 support?  Yes, many operators will be
> > > > transitioning to LTE by 2015, but there are 450 million CDMA subscribers
> > > > right now [1], and that number is expected to grow.  Having two modem
> > > > control stacks simply isn't an option.  Not having designed support for
> > > > CDMA into the service seems pretty short-sighted.  I know Nokia itself
> > > > doesn't care about CDMA any more, but still...
> > > 
> > > we did talk about CDMA voice support and so far nobody of us had good
> > > enough experience with how it works on the voice level. Let me assure
> > > you that we wanna definitely allow support for it.
> > 
> > I meant data, not voice...  What I'd like to know (and I couldn't find
> > out from looking for the introspection data, or missing API
> > specification) is whether you've made provisions for CDMA devices in the
> > D-Bus API.
> 
> so far not much time has been spent to integrate the data part. We are
> concentrating on getting voice going.
> 
> We want CDMA support for voice and data, but as I said, most of us are
> not using that technology on a regular basis. We haven't forgotten about
> it though :)
> 
> > > > - GPS support?  In reality, there can only be one service arbitrating
> > > > access to modem serial ports, since not all serial-based modems provide
> > > > more than two ports, and one of those must be used for PPP, and the
> > > > other for signal strength, etc.  Logically, the service controlling
> > > > these ports for cellular should also be handling GPS requests on these
> > > > devices.
> > > 
> > > I talked with our designers and engineers about it and we do see the
> > > need to handle this properly for modem devices where the control part is
> > > the same for the modem. We need to figure out on how to integrate this
> > > properly with Gypsy. Advantage of oFono is that it has a generic plugin
> > > infrastructure.
> > 
> > I'd expect services like ModemManager or ofono to implement a standard
> > GPS D-Bus interface that consumers of GPS information could query as
> > long as they are pointed at the right bus name.  GPS queries are
> > specific to the modem in question.
> 
> It is not that simple. Let me ensure you that I am aware of this mess
> with mixing GPS and modem hardware and their control endpoints. For us
> the Gypsy has the better interfaces in conjunction with GeoClue.

Not really convinced.  Quite a few modems don't just expose NMEA ports,
quite a few allow you to get GPS data through AT commands.  It makes a
ton of sense to consolidate the phone-specific command handling in *one*
place, in the same daemon that is handling the port arbitration for the
modem.  Leaving discreet GPS units to Gypsy is fine; but IMHO having the
modem daemon handle GPS provided by modems is the right path here.

> On a side note here. We also wanna support proper cell tower
> triangulation for location based services.

Right, GPS is only part of the story, you'll also want to collect the
unsolicited messages for cell tower notifications and expose that.
That's not really workable in Gypsy either, since this is often specific
to the phone itself.

Dan

> > > > - Is there some reason we cannot coalesce around *one* userland cellular
> > > > service?  There's Wader/VMC (python+dbus) and ModemManager (C+dbus) and
> > > > gsmd (C+dbus) already; it seems that for the sake of users, it would be
> > > > great to concentrate that effort in *one* place so that we don't have to
> > > > keep quirking every single modem in 4 different places.  TBH, I don't
> > > > care which one it is, as long as (a) it has a sane D-Bus interface, (b)
> > > > it supports CDMA, (c) it uses DeviceKit, and (d) it's GPLv2.
> > > 
> > > I think that the basic modem detection/quirking has to be done with your
> > > modem id tool from udev-extras.
> > 
> > I think you misunderstand the scope of modem quirking.  Please read
> > something like:
> > 
> > http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/
> > 
> > There are like 5 different ways to specify 2G/3G preference; and while
> > having a plugin system is nice and solves it for a *single* modem
> > manager, the question I was asking was why we cannot all work on a
> > single modem manager service and do all this hardware support in one
> > place.
> > 
> > The situation we have now is like Linux vs. Solaris vs NetBSD vs
> > FreeBSD.  All can drive the same hardware, but you have to write support
> > for the same hardware in each different OS, though copy & paste helps
> > between the BSDs at least.
> > 
> > Why have to duplicate hardware support in 4 different places?  Why can
> > we not coalesce around one stack?  Why write a different stack when
> > there are existing ones that already work, where the voice support could
> > have been added?
> 
> We are currently deriving from voice features and there was nothing that
> satisfied us. Especially when it comes to support fully non AT modem
> drivers. Cellphones do use special cellular modem protocols. For example
> the ones from Nokia.
> 
> Regards
> 
> Marcel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html