All of lore.kernel.org
 help / color / mirror / Atom feed
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 14:49:37 -0600	[thread overview]
Message-ID: <201001281449.37476.denkenz@gmail.com> (raw)
In-Reply-To: <61D8D34BB13CFE408D154529C120E0790326B620@eseldmw101.eemea.ericsson.se>

[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]

Hi Sjur,

> > 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?
> 
> Kind of. This is very good, it takes care of the situation with emergency
>  call which cannot be terminated with CHLD commands.
> 
> But I think there are more issues. If I am not mistaken STE-modems have
> the following behavior:
> CHLD=1X can only terminate call in state ACTIVE or HELD. (I think
> this is as STE interprets the standards).

The standards specify that CHLD=1X can only terminate an ACTIVE call.  Most 
modems implement it this way.  There are vendor extensions that provide this 
functionality (e.g. CHLD=7X on TI.)  By default oFono assumes that 
release_specific will simply fail if a user attempts to use it on an e.g. HELD 
call with no modem support.

> 
> a) If you are in a active call and receives a new incoming call (ALERTING)
> and want to reject the new ALERTING call, then STE modem cannot
> terminate this call with CHLD=1X. It has to be terminated with CHLD=0
> (cause=BUSY) or ATH (possible CHUP).

Ok, lets get the terminology clear here.  In this case the incoming call is 
not ALERTING, it is WAITING.  WAITING calls are always rejected by using 
CHLD=0.  ALERTING calls are always outgoing calls that transitioned from 
DIALING to alerting the user.

> 
> b) Or you may have the following situation. One call on HOLD,
> another ACTIVE call, and then you receive a new incoming call ALERTING.
> If you try to terminate the new incoming (ALERTING) call with CHLD=0,
> I think you as a side effect will terminate the call on hold as well.
> If I am not mistaken ATH (possible CHUP) would be the correct in this
> situation for STE modems

The standards are quite clear here, the WAITING call always takes precedence 
and thus only the WAITING call is affected. Can you check that STE modems do 
indeed get this wrong?  If the modem is standards compliant, oFono does the 
right thing here.

> 
> c) If you have an call on hold and initiate a new call, but want to
> terminate the newly initiated call (DIALING), then this call cannot be
> terminated with CHLD=1X, but you would have to use ATH (or possible CHUP).

Yes, so this is the case that we do need to take care of in the core.  Most 
modems let us get away with sending release_specific up to this point.

> > 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?
> 
> No, I don't think so. I think ATH will only terminate one call.
> In order to terminate all calls you would probably need to do something
> like: AT+CHLD=0;H But I'm not sure this works in all possible scenarios
> either...

Can you check the behavior of ATH vs CHUP on STE modems?  We need to send the 
right one here or both HELD and ACTIVE/DIALING/ALERTING will be terminated.  
If using CHUP and ATH doesn't work out we'll have to come up with another 
solution.

Regards,
-Denis

      reply	other threads:[~2010-01-28 20:49 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
2010-01-28 20:19   ` Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-01-28 20:49     ` Denis Kenzior [this message]

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=201001281449.37476.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.