All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andras Domokos <andras.domokos@nokia.com>
To: ofono@ofono.org
Subject: Re: [PATCH 0/3] Long dial string support (2nd)
Date: Wed, 24 Nov 2010 11:14:51 +0200	[thread overview]
Message-ID: <4CECD78B.8080602@nokia.com> (raw)
In-Reply-To: <4CEC3A5C.8030509@gmail.com>

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

Hi Denis,

On 11/24/2010 12:04 AM, ext Denis Kenzior wrote:
> Hi Andras,
>
>    
>> Even if we don't support FDN at this point, there is still a remaining
>> related issue, who we are going to dial numbers like:
>>
>> 12345456p1234#1111
>>
>> I think the the dial string could still be passed to the voicecall driver
>> that will take care of the modem specific details, most importantly
>> playing the DTMF tones and generating the tone events that would be
>> propagated back to voicecall manager and to D-Bus from there.
>>      
> So we looked into what it would take to implement dial strings with AT
> modems.  The consensus was that passing the entire string to the driver
> was a bad idea as most modems simply do not support pause characters and
> have strict limitations on the number length.
>
> The best idea we have came up with so far is to parse the string passed
> to dial and separate the actual number from the dial string.  The dial
> string then gets assigned to a separate property on the voice call
> object (see Dial String task in the TODO).
>
> We would then extend the call state logic to queue the dial string the
> same as a DTMF once the call is active.  If you study the DTMF logic,
> you will note that Andrew has recently made it into a tone queue.
>
> Today we burst up to 8 (arbitrarily picked number) DTMF tones per driver
> request.  What we could do is send a single tone at a time.  In theory
> this would allow us to emit the Tone Started / Tone Stopped signals
> (please see the provide feedback of sent DTMF tones task) as well.
>
> It sounds like the ISI modems already work this way and are nicely
> covered by this approach...
>    
Thanks for your clarification. I also had a thorough look at the
the DTMF tones handling implementation. Based on these infos
and assuming that we don't want to implement (full) FDN
support, these patches are not needed indeed.

> Regards,
> -Denis
>    

Regards,
Andras

      reply	other threads:[~2010-11-24  9:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 16:36 [PATCH 0/3] Long dial string support (2nd) Andras Domokos
2010-11-22 16:36 ` [RFC PATCH 1/3] common: add long dial string support Andras Domokos
2010-11-22 16:36 ` [RFC PATCH 2/3] voicecall: " Andras Domokos
2010-11-22 16:36 ` [RFC PATCH 3/3] isimodem/voicecall: " Andras Domokos
2010-11-22 20:58 ` [PATCH 0/3] Long dial string support (2nd) Rajesh.Nagaiah
2010-11-24  9:17   ` Andras Domokos
2010-11-23 17:41 ` Denis Kenzior
2010-11-23 18:19   ` Andras Domokos
2010-11-23 22:04     ` Denis Kenzior
2010-11-24  9:14       ` Andras Domokos [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=4CECD78B.8080602@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 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.