9:54 p.m.
Hi,
As we are currently implementing the CTM modem driver for ifxmodem, I would like to bring
a couple of things in the discussion.
Today, patches for our modem driver are ready by before submitting them on the mailing
list, I have 2 items to discuss:
1) First, it might a good proposal to merge the TextTelephony and the AudioSettings atoms.
Enabling and disabling CTM on a platform require to configure the audio settings on the
modem side (audio routing parameters changes). Today, in my patches, I have nearly the
same code as the AudioSetting modem driver for configuring the audio. Another proposal
would be that the TextTelephony atom indicates to the AudioSetting atom that CTM is enable
or disable but that would be good also to merge the 2.
Any idea?
2) Secondly, I think that 2 properties can be added in the TextTelephony atom and/or the
AudioSetting atom (or the "merged" atom described in 1). The first property is
when the device receives an incoming CTM call. Even if the type is still a voice call,
upper layers should be notified that the incoming is a TTY call to display some UI stuff
or to turn on the TTY mode in case the device is not already TTY enabled (this is totally
UI dependant but at least we leave the flexibility to the UI to decide).
The second property is for MO calls. Remote user can accept the call as a TTY enable
device or not. This is supported by the standard. In our case, we are receiving
unsolicited AT commands "CTM CALL" when the remote party has accepted the call
as a TTY enabled device and "NO CTM CALL" when the remote has accepted the call
but his device is not TTY enabled.
Let me know your thinking
Regards
Fred
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
9:02 a.m.
Hi Fred,
As we are currently implementing the CTM modem driver for ifxmodem, I
would like to bring a couple of things in the discussion.
Today, patches for our modem driver are ready by before submitting them on the mailing
list, I have 2 items to discuss:
1) First, it might a good proposal to merge the TextTelephony and the AudioSettings
atoms. Enabling and disabling CTM on a platform require to configure the audio settings on
the modem side (audio routing parameters changes). Today, in my patches, I have nearly the
same code as the AudioSetting modem driver for configuring the audio. Another proposal
would be that the TextTelephony atom indicates to the AudioSetting atom that CTM is enable
or disable but that would be good also to merge the 2.
Any idea?
to be fairly honest, the CTM stuff is not my strong suit. The
AudioSettings atom was just designed to give PulseAudio the change to
handle the voice uplink/downlink setup and processing of the data. And
mainly only because following the call states is not enough.
So adding a parameter that indicates CTM might be a good idea. I am not
100% sure about this. So I am happy to hear thoughts from the audio
experts on this list.
The more and more I think about this, I come to the conclusion that we
might needed a better cmtspeech to PA interaction and not do this via
oFono at all. Something similar to what the ISI modem and cmtspeech
actually did. So that you have a proper signaling of types from the
kernel directly into PA and not just via oFono. Just an idea.
2) Secondly, I think that 2 properties can be added in the
TextTelephony atom and/or the AudioSetting atom (or the "merged" atom described
in 1). The first property is when the device receives an incoming CTM call. Even if the
type is still a voice call, upper layers should be notified that the incoming is a TTY
call to display some UI stuff or to turn on the TTY mode in case the device is not already
TTY enabled (this is totally UI dependant but at least we leave the flexibility to the UI
to decide).
The second property is for MO calls. Remote user can accept the call as a TTY enable
device or not. This is supported by the standard. In our case, we are receiving
unsolicited AT commands "CTM CALL" when the remote party has accepted the call
as a TTY enabled device and "NO CTM CALL" when the remote has accepted the call
but his device is not TTY enabled.
I think we need a property inside the voice call that indicates that
this is a TTY call. You have played with TTY hardware which I have not.
So we might need to figure what the UI requirement for TTY really is.
This is still pretty much unclear to me how this all needs to be
indicated to the actual impaired user. Any experts here?
Regards
Marcel
9:30 a.m.
Hi,
On 05 Jan 2011, Marcel Holtmann wrote:
> our case, we are receiving unsolicited AT commands "CTM
CALL" when the
> remote party has accepted the call as a TTY enabled device and "NO CTM
> CALL" when the remote has accepted the call but his device is not TTY
> enabled.
I think we need a property inside the voice call that indicates that
this is a TTY call. You have played with TTY hardware which I have not.
yes, but we need to be clear on semantics. So specifically,
I'm assuming "TTY call" here would mean that MS has indicated CTM
support in its bearer capability flags (24.008). This is sent when
establishing calls, and is sent both for MO&MT calls. This is
common to all modems supporting CTM.
So we might need to figure what the UI requirement for TTY really
is.
This is still pretty much unclear to me how this all needs to be
indicated to the actual impaired user. Any experts here?
Not an expert either, but as nobody else seems to be commenting,
I'll give it a go. ;) For really high-level explanation, see:
http://www.nokiaaccessibility.com/textphones.html
So the configuration is fairly static. User needs to select
TTY mode in device settings _and_ connect the textphone. Only
if these conditions are met, should the CTM flag be set for
established calls.
So basicly just having org.ofono.TextTelephony.Enabled (controlling
whether CTM is enabled or not for any created calls) is enough
for a basic implementation.
If I've understood correctly, ifxmodem allows additionally
to enable CTM when a) you get a MT call with CTM flag
set, and b) org.ofono.TextTelephony.Enabled==FALSE is before
the call. So if this is exposed as a voicecall property, UI can
notify the user to connect the textphone (in case TTY is enabled
in device settings). But I'm guessing a bit here, so Fred and
others, please correct any mistakes in this.
PS This is not to be confused what actually happens on the traffic
channel. There's also inband negotiation specified for CTM
(in 26.226), but AFAIK nobody is proposing to expose any
of this via oFono (and if it was, this would be highly modem
specific as the CTM codec is not necessarily even implemented
in the modem).
8:26 a.m.
Hi,
On 22 Dec 2010, Predon, Frederic wrote:
1) First, it might a good proposal to merge the TextTelephony and
the
AudioSettings atoms. Enabling and disabling CTM on a platform require
to configure the audio settings on the modem side (audio routing
parameters changes). Today, in my patches, I have nearly the same code
this area is slightly confusing as there are many atoms related
to calls (e.g org.ofono.CallVolume, AudioSettings, CallSettings).
The AudioSettings is AFAIK meant for modems where the audio is
routed to/from the host (e.g. N900/isimodem or ifxmodem), and to
me it would be a good idea to keep it clean (only features that affect
modems of this type).
Controlling TTY/CTM applies to all kinds of modems, independently
of how they manage (or don't manage audio), so that to me hints
that the TextTelephony should be a separate atom.
Of course if the CTM implementation needs cooperation with
the host audio stack (in case host is involved in the audio path),
then CTM support will impact other atoms as well (AudioSettings in
case of ifxmodem).
2) Secondly, I think that 2 properties can be added in the
TextTelephony atom and/or the AudioSetting atom (or the "merged" atom
described in 1). The first property is when the device receives an
incoming CTM call. Even if the type is still a voice call, upper layers
Now continuing the above reasoning, I'd say this should go to
TextTelephony as modems not implementing AudioSettings can
still implement this, and this property is useful to show in the UI
despite the audio implementation details.
But as the ifxmodem interface is per-call (I guess this maps to the CTM
bearer capability flag in SETUP and its replies), this could
perhaps be a property of org.ofono.VoiceCall as well.
The second property is for MO calls. Remote user can accept the call
as
a TTY enable device or not. This is supported by the standard. In our
So same for this (either to TextTelephony, or perhaps also a property of
voicecalls).
4268
days inactive
4288
days old
3 comments
3 participants
participants (3)
-
Kai.Vehmanen＠nokia.com -
Marcel Holtmann -
Predon, Frederic