From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: FW: [RFC 3/3] STE-plugin: Adding STE plugin
Date: Thu, 28 Jan 2010 10:25:34 -0600 [thread overview]
Message-ID: <201001281025.35704.denkenz@gmail.com> (raw)
In-Reply-To: <61D8D34BB13CFE408D154529C120E0790326B437@eseldmw101.eemea.ericsson.se>
[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]
Hi Sjur,
> > All of this logic needs to go away. The core already handles all of
> > this, including selection of ATH/CHLD, waiting/held. Please review
> > src/voicecall.c.
> > If the core logic is not sufficient or does not properly handle a
> > certain case, then lets see if we can fix the core first. Drivers
> > should not concern themselves with this stuff.
>
> OK, we can remove the state logic, but STE modem cannot terminate
> calls in state DIALING and ALERTING with CHLD=1X. We need to use
> ATH (or AT+CHUP) instead.
oFono already takes care of this for single calls (see src/voicecall.c
voicecall_hangup.) So this is only an issue in the case of three way calls,
is this what you're referring to here?
>
> For now I think we will remove the state logic from ste_release_specific as
> you suggest. Terminating calls in state DIALING and ALERTING must then be
> handled by the Core part. The simplest would probably be to use hangup in
> this case, but I suspect hangup work differently for different modems.
> So if you cannot use hangup as the general approach, maybe it could be
> implemented by adding callback functions release_dialing and
> release_alerting in struct ofono_voicecall_driver. The STE driver could
> send ATH from release_dialing and release_alerting, other drivers could
> leave them empty and this could default to use release_specific instead?
What I have been considering to take care of this case is to add end_all and
end_all_active callbacks. According to 27.007/22.030 ATH should end all calls
(active + held) except waiting calls, while +CHUP should only end the
currently active call. At least on one TI modem I tried this works as
expected. Do your modems implement the same behavior?
If so then we can always use end_all_active for dialing/incoming/alerting
cases.
>
> > With this in mind, you might not need to track any state in this
> > driver at all. See drivers/calypsomodem/voicecall.c for details.
> > TI's CPI notifications are almost exactly the same as the STE ECAV.
>
> The STE ECAV update is giving delta updates on the state information,
> right now I don't see how we can get the ofono_voicall_notify right
> without keeping some state information in ecav_notify.
>
Yes you're right, I was assuming ECAV gives you more information on whether
the call was released locally or remotely.
Regards,
-Denis
next prev parent reply other threads:[~2010-01-28 16:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 10:38 FW: [RFC 3/3] STE-plugin: Adding STE plugin Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-01-28 16:25 ` Denis Kenzior [this message]
2010-01-28 20:19 ` Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-01-28 20:49 ` Denis Kenzior
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=201001281025.35704.denkenz@gmail.com \
--to=denkenz@gmail.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