From: Andras Domokos <andras.domokos@nokia.com>
To: ofono@ofono.org
Subject: Re: [RFC PATCH 2/3] voicecall: emergency call handling added
Date: Mon, 01 Nov 2010 13:23:38 +0200 [thread overview]
Message-ID: <4CCEA33A.70406@nokia.com> (raw)
In-Reply-To: <4CCB0531.2040208@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3814 bytes --]
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.
>>>
>>>
>>>
>> The idea with the emergency watch is that any subsystem can get the
>> notification when the emergency mode is entered and react on it.
>>
> Don't get me wrong, it might be useful in the future. But for the
> context of supporting emergency calls in the voicecall driver the
> emergency watch is not really needed. In general I prefer to review
> code which has an immediate or foreseeable need.
>
> In this case if we detect an emergency call dial and we're offline, we:
>
> - Save the pending call
> - establish an online watch
> - ofono_modem_inc_emergency_mode()
>
> Once we are online:
> - Dial the call
>
> Once the call ends
> - ofono_modem_dec_emergency_mode()
>
> Nowhere do we actually need to use an emergency watch itself.
>
>
>> 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?
>
> If this is still required, I suggest you group the emergency watch
> functions with patches implementing the above functionality.
>
>
>> available by gprs and to deal with the gprs connection within voicecall
>> (or somewhere else). The online/offline mode change handling in fact is
>> bringing up the some issue, how the mode change handling should be
>> implemented when making the emergency call. My idea was let every
>> subsystem deal with the specifics of its own subsystem.
>>
> Let the modem figure out the specifics. Basically as long as the count
> for emergency is greater than 1, Offline mode should not be entered.
> Once it reaches 0, the online mode should go back to the previous value.
>
Based on the comments and after some clarifications made in our
team, I consider the emergency watch unnecessary. We can forget
about the very corner case and go with the simpler approach.
OK, I am going to come up with a new set of patches.
> Regards,
> -Denis
>
Regards,
Andras
next prev parent reply other threads:[~2010-11-01 11:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 16:47 Emergency Calls Andras Domokos
2010-10-22 16:47 ` [RFC PATCH 1/3] modem: modem state watch added Andras Domokos
2010-10-28 3:31 ` Denis Kenzior
2010-10-22 16:47 ` [RFC PATCH 2/3] voicecall: emergency call handling added Andras Domokos
2010-10-28 3:48 ` Denis Kenzior
2010-10-29 9:29 ` Andras Domokos
2010-10-29 12:36 ` Marcel Holtmann
2010-10-29 17:32 ` Denis Kenzior
2010-11-01 9:03 ` Mika.Liljeberg
2010-11-01 9:41 ` Marcel Holtmann
2010-11-01 11:11 ` Mika.Liljeberg
2010-11-01 11:23 ` Andras Domokos [this message]
2010-10-22 16:47 ` [RFC PATCH 3/3] modem: emergency state " Andras Domokos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CCEA33A.70406@nokia.com \
--to=andras.domokos@nokia.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox