From: Frederic Danis <frederic.danis@linux.intel.com>
To: ofono@ofono.org
Subject: Re: [PATCH 2/4] voicecall: add ATD support for HFP emulator
Date: Thu, 19 May 2011 18:16:34 +0200 [thread overview]
Message-ID: <4DD54262.3090008@linux.intel.com> (raw)
In-Reply-To: <4DD3F042.4050506@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]
Hello Denis,
Le 18/05/2011 18:13, Denis Kenzior a écrit :
> Hi Frederic,
>
>>>> + if (!strncmp(number, "*31#", 4)) {
>>>> + number += 4;
>>>> + clir = OFONO_CLIR_OPTION_INVOCATION;
>>>> + } else if (!strncmp(number, "#31#", 4)) {
>>>> + number += 4;
>>>> + clir = OFONO_CLIR_OPTION_SUPPRESSION;
>>>> + } else
>>>> + clir = OFONO_CLIR_OPTION_DEFAULT;
>>>> +
>>>
>>> Actually this is not quite right. The clir option is determined by the
>>> presence of 'I'/'i' characters at the end of the dial string. Refer to
>>> 27.007 for more details.
>>>
>>> oFono does not actually recognize temporary forms of *31/#31
>>> invocation yet.
>>>
>> I added *31/#31 as I found them in telephony-ofono implementation of
>> BlueZ HFP AG,
>> but 27.007 uses I/i,
>> and HFP 1.5 does not seem to support clir option (ATDdd...dd;)
>>
>> Should I remove this part of code and only be compatible with HFP specs ?
>>
>
> Might as well handle the I/i and G/g part according to 27.007 since that
> is pretty easy and we'll have to do it anyway. *31/#31 is really an MMI
> code, it should never be sent to the modem, so please remove that for now.
>
OK, so I will remove this part and will send a patch on I/i,G/g support
later.
>>>> + err = voicecall_dial(vc, number, clir, emulator_dial_callback, vc);
>>>> + switch (err) {
>>>> + case DIAL_NO_ERROR:
>>>> + result.type = OFONO_ERROR_TYPE_NO_ERROR;
>>>> + break;
>>>> +
>>>> + case DIAL_NO_NETWORK:
>>>> + result.error = 30;
>>>> + result.type = OFONO_ERROR_TYPE_CME;
>>>> + break;
>>>
>>> This might need to be NO CARRIER
>>>
>> As far as I understand, when there is no network, ATD should reply NO
>> CARRIER if CMEE error mode is set to 0, or +CME ERROR: 30 if it is set
>> to 1.
>
> Not quite. CMEE controls the presentation of 'extended' CME ERROR code.
> Either as ERROR, CME ERROR:<num> or CME ERROR:<str>. NO CARRIER is
> not an extended error code at all, and so is only affected by ATV
> setting, not CMEE.
>
OK, thanks for your explanation.
>> So, I think that voicecall should return an OFONO_ERROR_TYPE_CME 30, and
>> ofono_emulator_send_final should take care of replying the right string.
>>
>
> Nope, you have to take your pick, either CME ERROR: 30, or NO CARRIER.
> I'd expect most implementations to reply with a NO CARRIER in this case,
> but can you check what other implementations do in reality?
>
In paragraph 6.2.13.11 of tr002v15, in reply to ATD command without
network, the flowchart shows usage of +CME ERROR: 30 or ERROR reply (no
usage of NO CARRIER).
Paragraph 4.33.2 of HFP 1.5 specification said that NO CARRIER (and
BUSY, NO ANSWER, ...) "are in addition to the +CME ERROR: reponses".
My understanding of specs is that we should send the CME ERROR and, if
we want, NO CARRIER in addition.
Regards
Fred
--
Frederic Danis Open Source Technology Centre
frederic.danis(a)intel.com Intel Corporation
next prev parent reply other threads:[~2011-05-19 16:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-12 14:40 [PATCH 0/4] Add dial support for HFP emulator =?unknown-8bit?q?Fr=C3=A9d=C3=A9ric?= Danis
2011-05-12 14:40 ` [PATCH 1/4] voicecall: create generic dial function =?unknown-8bit?q?Fr=C3=A9d=C3=A9ric?= Danis
2011-05-18 4:46 ` Denis Kenzior
2011-05-12 14:40 ` [PATCH 2/4] voicecall: add ATD support for HFP emulator =?unknown-8bit?q?Fr=C3=A9d=C3=A9ric?= Danis
2011-05-18 4:53 ` Denis Kenzior
2011-05-18 15:33 ` Frederic Danis
2011-05-18 16:13 ` Denis Kenzior
2011-05-19 16:16 ` Frederic Danis [this message]
2011-05-19 16:39 ` Denis Kenzior
2011-05-12 14:40 ` [PATCH 3/4] voicecall: save last dialed number =?unknown-8bit?q?Fr=C3=A9d=C3=A9ric?= Danis
2011-05-12 14:40 ` [PATCH 4/4] voicecall: add +BLDN support for HFP emulator =?unknown-8bit?q?Fr=C3=A9d=C3=A9ric?= Danis
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=4DD54262.3090008@linux.intel.com \
--to=frederic.danis@linux.intel.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