headers
Su, Yong | 1 Nov 2010 04:44
Favicon

RE: oFono SMS Validity Period and Message Class support


 Hi,

> -----Original Message-----
> From: Rajesh.Nagaiah@... 
> [mailto:Rajesh.Nagaiah@...] 
> Sent: 2010?10?29? 18:09
> To: ofono@...
> Subject: RE: oFono SMS Validity Period and Message Class support
> 
> Hi,
> 
> > Hi, all:
> >  
> > We are using ofono to send sms with validity period and 
> message class 
> > in our project.
> > but by checking source code, it seems ofono doesn't support 
> > these requirements.   
> > 
> > Current implemntation is the dbus interface "SendMessage" 
> > contains "To" and "Text" only.
> >  
> > Does oFono plan to support these extra fields when sending sms? 
> >  
> 
> Right now oFono uses hardcoded Relative validity period of value
> 167 (24hrs: 12hrs +(167-143)x30mins)for SUBMIT message. 
> 
> If later supported then the Validity period should be part of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Su, Yong | 1 Nov 2010 04:58
Favicon

RE: oFono SMS Validity Period and Message Class support


Hi,

> -----Original Message-----
> From: Denis Kenzior [mailto:denkenz@...] 
> Sent: 2010?10?30? 1:20
> To: ofono@...
> Cc: Su, Yong
> Subject: Re: oFono SMS Validity Period and Message Class support
> 
> Hi,
> 
> On 10/29/2010 03:43 AM, Su, Yong wrote:
> > Hi, all:
> >  
> > We are using ofono to send sms with validity period and 
> message class in our project.
> > but by checking source code, it seems ofono doesn't support 
> these requirements.   
> 
> oFono does not allow you to set the validity period and 
> simply hard-codes it (I believe 48 hours).  Unless you have a 
> really good reason why you want to set the validity period, 
> this isn't likely to change.
> 
> Sending SMS messages other than class unspecified makes no 
> sense and will not be supported.  If you have some extremely 
> specific use case in mind where this does make sense, please 
> write your own oFono plugin.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mika.Liljeberg | 1 Nov 2010 10:03
Picon

RE: [RFC PATCH 2/3] voicecall: emergency call handling added

Hi,

> > To give you a more complex example, it might well be that the gprs
> > connection needs to be torn down when making an emergency call in
> > 2G mode, there are such networks out there that prevents you from
> > making an emergency call if your device is attached to a 
> PDP context.
> > In this given situation it comes to the question how to 
> bring down the
> > gprs connection. It can be done such that the gprs atom 
> will tear down
> > the connection after receiving the EmergencyMode notification, or
> > another option is to have gprs connection handling functions made
> 
> Have we established that this is actually still needed?  I thought you
> guys said all the networks that have this problem have been 
> fixed by now?

AFAIK, this is still a product requirement for us. I can recheck, but I just asked last week and the answer was
a very definite "Yes, this is still required".

	MikaL
Permalink | Reply | 2 comments |
headers
Yang Gu | 1 Nov 2010 10:09
Picon
Favicon

[PATCH] TODO: update owner of see/cancel pending SMS task

---
 TODO |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index a01960e..5968c08 100644
--- a/TODO
+++ b/TODO
 <at>  <at>  -70,6 +70,7  <at>  <at>  SMS

   Priority: High
   Complexity: C2
+  Owner: Yang Gu <yang.gu@...>

 - Persist outgoing SMS messages.  Currently oFono persists incoming messages
   that are fragmented.  However oFono does not persist queued outgoing
--

-- 
1.7.2.3
Permalink | Reply | 1 comment |
headers
Mika.Liljeberg | 1 Nov 2010 10:18
Picon

RE: [PATCH 3/6] radio settings: add FastDormancy property

Hi Denis,

> One of the biggest principles in oFono is not to perform premature
> optimization.  Sure there is a potential issue, but nobody 
> knows whether
> it will actually manifest itself outside of malicious code (which we
> tell to bugger off) or what the most common manifestation 
> pattern will be.
> 
> If / once we know for sure this is a problem, then we can solve it
> properly.  So far this approach has been working very nicely for us.
> There are countless occasions where taking the wait-and-see 
> approach and
> gathering more information allowed us to devise a much better solution
> than we would have originally.
> 
> So the general rule is: Do the simplest thing that is likely to work.
> If it doesn't work, improve it.

Can't fault the approach, it's generally a good one. That said, I see this more as an API quality issue rather
than an optimization issue. Anyway, I've raised the concern. Let's hope my worries are unfounded.

Br,

	MikaL
Permalink | Reply | 0 comments |
headers
Marcel Holtmann | 1 Nov 2010 10:41

RE: [RFC PATCH 2/3] voicecall: emergency call handling added

Hi Mika,

> > > To give you a more complex example, it might well be that the gprs
> > > connection needs to be torn down when making an emergency call in
> > > 2G mode, there are such networks out there that prevents you from
> > > making an emergency call if your device is attached to a 
> > PDP context.
> > > In this given situation it comes to the question how to 
> > bring down the
> > > gprs connection. It can be done such that the gprs atom 
> > will tear down
> > > the connection after receiving the EmergencyMode notification, or
> > > another option is to have gprs connection handling functions made
> > 
> > Have we established that this is actually still needed?  I thought you
> > guys said all the networks that have this problem have been 
> > fixed by now?
> 
> AFAIK, this is still a product requirement for us. I can recheck, but I just asked last week and the answer
was a very definite "Yes, this is still required".

as Denis and I mentioned, we have been told that this is not needed
anymore. So where is this still needed?

And again, this is something that the modem firmware should be doing
anyway (if it is needed). The modem firmware knows best. And we do have
the GPRS suspend support already to signal this back to the user.

Regards
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mika.Liljeberg | 1 Nov 2010 12:11
Picon

RE: [RFC PATCH 2/3] voicecall: emergency call handling added

Hi Marcel, 

> > > Have we established that this is actually still needed?  
> I thought you
> > > guys said all the networks that have this problem have been 
> > > fixed by now?
> > 
> > AFAIK, this is still a product requirement for us. I can 
> recheck, but I just asked last week and the answer was a very 
> definite "Yes, this is still required".
> 
> as Denis and I mentioned, we have been told that this is not needed
> anymore. So where is this still needed?

Ok, I double checked the product requirements and it turns out that you're right. The requirement is no
longer there for oFono based stuff. Seems we've had some wires crossed at our end, so the situation was not
entirely clear.

Sorry for the confusion,

	MikaL
Permalink | Reply | 0 comments |
headers
Andras Domokos | 1 Nov 2010 12:23
Picon

Re: [RFC PATCH 2/3] voicecall: emergency call handling added

Hi Denis,

On 10/29/2010 08:32 PM, ext Denis Kenzior wrote:
> Hi Andras,
>
>    
>>> Just some general comments, but this patch seems to be backwards from
>>> the earlier proposal.  Namely EmergencyMode is a property on the Modem
>>> interface, not on the VoiceCallManager.  See doc/modem-api.txt,
>>> Emergency property.
>>>
>>>        
>> I thought it was more logical to have the EmergencyMode property
>> linked to voicecall since it is about a special call case, but I am fine
>> with moving that property up to modem level.
>>
>>      
> Oh I can see that as well, but I think earlier we agreed that it should
> be on the Modem interface.  This has several advantages: offline /
> online toggling has to happen in the modem and it is easier for the
> power management framework to monitor it there.  So unless you feel
> really strongly against that I suggest we stick with the earlier proposal.
>
>    
I see the advantage of using the Modem interface and I am fine
with basing the implementation on it.
>>> In general I think that the emergency_watch is unnecessary.  Having a
>>> reference counted emergency tracking inside the modem object and a modem
>>> online state watch should be sufficient.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mika Liljeberg | 1 Nov 2010 16:53
Picon

[PATCH 1/2] isigen: fix phonet address initialization

---
 plugins/isigen.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/plugins/isigen.c b/plugins/isigen.c
index 0ea2db3..493d926 100644
--- a/plugins/isigen.c
+++ b/plugins/isigen.c
 <at>  <at>  -286,9 +286,10  <at>  <at>  static int isigen_probe(struct ofono_modem *modem)
 	}

 	if (address) {
-		int error = g_pn_netlink_set_address(idx, PN_DEV_PC);
+		int error = g_pn_netlink_set_address(idx, address);
 		if (error && error != -EEXIST) {
 			DBG("g_pn_netlink_set_address: %s\n", strerror(-error));
+			g_pn_netlink_stop(link);
 			return -errno;
 		}
 	}
--

-- 
1.7.0.4
Permalink | Reply | 1 comment |
headers
Mika Liljeberg | 1 Nov 2010 16:53
Picon

[PATCH 2/2] main: add capabilities for phonet

Phonet sockets require CAP_SYS_ADMIN and SO_BINDTODEVICE socket
option requires CAP_NET_RAW.
---
 src/main.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/main.c b/src/main.c
index 93149bc..eca008e 100644
--- a/src/main.c
+++ b/src/main.c
 <at>  <at>  -140,7 +140,8  <at>  <at>  int main(int argc, char **argv)
 	/* Drop capabilities */
 	capng_clear(CAPNG_SELECT_BOTH);
 	capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED,
-				CAP_NET_BIND_SERVICE, CAP_NET_ADMIN, -1);
+				CAP_NET_BIND_SERVICE, CAP_NET_ADMIN,
+				CAP_NET_RAW, CAP_SYS_ADMIN, -1);
 	capng_apply(CAPNG_SELECT_BOTH);
 #endif

--

-- 
1.7.0.4
Permalink | Reply | 1 comment |

Gmane