[RFC 0/5] Add support for TextTelephony call notifications

[RFC 0/5] Add support for TextTelephony call notifications

[Jeevaka Badrappan]

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

Hi,

  This is a proposal for adding TextTelephony notifications to the 
core and ifxmodem.

Regards,
Jeevaka

Jeevaka Badrappan (5):
  types: add tty flag to ofono_call
  voicecall: Add tty property support
  voicecall: Add ofono_voicecall_tty_notify api
  ifxmodem: Add support for tty call notifications
  doc: Describe TextTelephony property

 doc/voicecall-api.txt        |    7 +++++++
 drivers/ifxmodem/voicecall.c |   36 +++++++++++++++++++++++++++++++-----
 include/types.h              |    1 +
 include/voicecall.h          |    2 ++
 src/voicecall.c              |   32 ++++++++++++++++++++++++++++++++
 5 files changed, 73 insertions(+), 5 deletions(-)

[RFC 1/5] types: add tty flag to ofono_call

[Jeevaka Badrappan]

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

---
 include/types.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/types.h b/include/types.h
index 9fd174d..caf148c 100644
--- a/include/types.h
+++ b/include/types.h
@@ -98,6 +98,7 @@ struct ofono_call {
 	int direction;
 	int status;
 	ofono_bool_t mpty;
+	ofono_bool_t tty;
 	struct ofono_phone_number phone_number;
 	char name[OFONO_MAX_CALLER_NAME_LENGTH + 1];
 	int clip_validity;
-- 
1.7.0.4

[RFC 2/5] voicecall: Add tty property support

[Jeevaka Badrappan]

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

---
 src/voicecall.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/src/voicecall.c b/src/voicecall.c
index 97fc36b..da42fac 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -354,6 +354,7 @@ static void append_voicecall_properties(struct voicecall *v,
 	const char *name;
 	ofono_bool_t mpty;
 	dbus_bool_t emergency_call;
+	dbus_bool_t tty;
 
 	status = call_status_to_string(call->status);
 
@@ -391,6 +392,9 @@ static void append_voicecall_properties(struct voicecall *v,
 
 	ofono_dbus_dict_append(dict, "Multiparty", DBUS_TYPE_BOOLEAN, &mpty);
 
+	tty = call->tty;
+	ofono_dbus_dict_append(dict, "TextTelephony", DBUS_TYPE_BOOLEAN, &tty);
+
 	if (v->message)
 		ofono_dbus_dict_append(dict, "Information", DBUS_TYPE_STRING,
 					&v->message);
@@ -675,6 +679,21 @@ static void voicecall_emit_multiparty(struct voicecall *call, gboolean mpty)
 						&val);
 }
 
+static void voicecall_set_call_tty(struct voicecall *call, gboolean tty)
+{
+	if (call->call->tty != tty) {
+		DBusConnection *conn = ofono_dbus_get_connection();
+		const char *path = voicecall_build_path(call->vc, call->call);
+		dbus_bool_t val = tty;
+
+		call->call->tty = tty;
+		ofono_dbus_signal_property_changed(conn, path,
+						OFONO_VOICECALL_INTERFACE,
+						"TextTelephony",
+						DBUS_TYPE_BOOLEAN, &val);
+	}
+}
+
 static void voicecall_set_call_status(struct voicecall *call, int status)
 {
 	DBusConnection *conn = ofono_dbus_get_connection();
@@ -1924,6 +1943,7 @@ void ofono_voicecall_notify(struct ofono_voicecall *vc,
 
 	if (l) {
 		DBG("Found call with id: %d", call->id);
+		voicecall_set_call_tty(l->data, call->tty);
 		voicecall_set_call_status(l->data, call->status);
 		voicecall_set_call_lineid(l->data, &call->phone_number,
 						call->clip_validity);
-- 
1.7.0.4

[RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Jeevaka Badrappan]

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

---
 include/voicecall.h |    2 ++
 src/voicecall.c     |   12 ++++++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/include/voicecall.h b/include/voicecall.h
index e37d73b..6f1bdd2 100644
--- a/include/voicecall.h
+++ b/include/voicecall.h
@@ -144,6 +144,8 @@ void ofono_voicecall_notify(struct ofono_voicecall *vc,
 void ofono_voicecall_disconnected(struct ofono_voicecall *vc, int id,
 				enum ofono_disconnect_reason reason,
 				const struct ofono_error *error);
+void ofono_voicecall_tty_notify(struct ofono_voicecall *vc,
+				const struct ofono_call *call);
 
 int ofono_voicecall_driver_register(const struct ofono_voicecall_driver *d);
 void ofono_voicecall_driver_unregister(const struct ofono_voicecall_driver *d);
diff --git a/src/voicecall.c b/src/voicecall.c
index da42fac..b55c727 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -1990,6 +1990,18 @@ error:
 		g_free(v);
 }
 
+void ofono_voicecall_tty_notify(struct ofono_voicecall *vc,
+				const struct ofono_call *call)
+{
+	GSList *l;
+
+	l = g_slist_find_custom(vc->call_list, GUINT_TO_POINTER(call->id),
+				call_compare_by_id);
+
+	if (l)
+		voicecall_set_call_tty(l->data, TRUE);
+}
+
 static void generic_callback(const struct ofono_error *error, void *data)
 {
 	struct ofono_voicecall *vc = data;
-- 
1.7.0.4

Re: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Marcel Holtmann]

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

Hi Jeevaka,

>  include/voicecall.h |    2 ++
>  src/voicecall.c     |   12 ++++++++++++
>  2 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/include/voicecall.h b/include/voicecall.h
> index e37d73b..6f1bdd2 100644
> --- a/include/voicecall.h
> +++ b/include/voicecall.h
> @@ -144,6 +144,8 @@ void ofono_voicecall_notify(struct ofono_voicecall *vc,
>  void ofono_voicecall_disconnected(struct ofono_voicecall *vc, int id,
>  				enum ofono_disconnect_reason reason,
>  				const struct ofono_error *error);
> +void ofono_voicecall_tty_notify(struct ofono_voicecall *vc,
> +				const struct ofono_call *call);

what is the advantage of having this separate and not part of the
regular voicecall_notify and just extending struct ofono_call with a
field for TTY?

Regards

Marcel

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Jeevaka.Badrappan]

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

Hi Marcel,

ofono-bounces(a)ofono.org wrote:
> Hi Jeevaka,
> 
>>  include/voicecall.h |    2 ++
>>  src/voicecall.c     |   12 ++++++++++++
>>  2 files changed, 14 insertions(+), 0 deletions(-)
>> 
>> diff --git a/include/voicecall.h b/include/voicecall.h index
>> e37d73b..6f1bdd2 100644 --- a/include/voicecall.h
>> +++ b/include/voicecall.h
>> @@ -144,6 +144,8 @@ void ofono_voicecall_notify(struct
>> ofono_voicecall *vc,  void ofono_voicecall_disconnected(struct
>>  				ofono_voicecall *vc, int id, enum
ofono_disconnect_reason
>>  				reason, const struct ofono_error
*error);
>> +void ofono_voicecall_tty_notify(struct ofono_voicecall *vc,
>> +				const struct ofono_call *call);
> 
> what is the advantage of having this separate and not part of
> the regular voicecall_notify and just extending struct
> ofono_call with a field for TTY?
> 

Main reason for separate notification function is to avoid going through
all
the cases handled inside voicecall_notify. TTY field in ofono_call is
basically
for the GetProperties.

Regards,
Jeevaka  

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Marcel Holtmann]

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

Hi Jeevaka,

> >>  include/voicecall.h |    2 ++
> >>  src/voicecall.c     |   12 ++++++++++++
> >>  2 files changed, 14 insertions(+), 0 deletions(-)
> >> 
> >> diff --git a/include/voicecall.h b/include/voicecall.h index
> >> e37d73b..6f1bdd2 100644 --- a/include/voicecall.h
> >> +++ b/include/voicecall.h
> >> @@ -144,6 +144,8 @@ void ofono_voicecall_notify(struct
> >> ofono_voicecall *vc,  void ofono_voicecall_disconnected(struct
> >>  				ofono_voicecall *vc, int id, enum
> ofono_disconnect_reason
> >>  				reason, const struct ofono_error
> *error);
> >> +void ofono_voicecall_tty_notify(struct ofono_voicecall *vc,
> >> +				const struct ofono_call *call);
> > 
> > what is the advantage of having this separate and not part of
> > the regular voicecall_notify and just extending struct
> > ofono_call with a field for TTY?
> > 
> 
> Main reason for separate notification function is to avoid going through
> all
> the cases handled inside voicecall_notify. TTY field in ofono_call is
> basically
> for the GetProperties.

I see. So here is the main question that comes from this now. This seems
to be a bit IFX specific driven API. I still have no idea why they can
not just indicate this via +CRING and have to use CTM CALL for it.

Are we expecting that all modems will just establish a normal voice call
and only later on signal that it is a TTY call? Any input from different
vendors other than IFX. What about STE, ISI?

Regards

Marcel

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Jeevaka.Badrappan]

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

Hi Marcel,

ofono-bounces(a)ofono.org wrote:
>> Main reason for separate notification function is to avoid going
>> through all the cases handled inside voicecall_notify. TTY field in
>> ofono_call is basically for the GetProperties.
> 
> I see. So here is the main question that comes from this now.
> This seems to be a bit IFX specific driven API. I still have
> no idea why they can not just indicate this via +CRING and
> have to use CTM CALL for it.
> 
> Are we expecting that all modems will just establish a normal
> voice call and only later on signal that it is a TTY call?
> Any input from different vendors other than IFX. What about STE, ISI?

This notification is to inform the ME that the call is accepted as a TTY
call
on the remote side.

Regards,
Jeevaka

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Marcel Holtmann]

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

Hi Jeevaka,

> >> Main reason for separate notification function is to avoid going
> >> through all the cases handled inside voicecall_notify. TTY field in
> >> ofono_call is basically for the GetProperties.
> > 
> > I see. So here is the main question that comes from this now.
> > This seems to be a bit IFX specific driven API. I still have
> > no idea why they can not just indicate this via +CRING and
> > have to use CTM CALL for it.
> > 
> > Are we expecting that all modems will just establish a normal
> > voice call and only later on signal that it is a TTY call?
> > Any input from different vendors other than IFX. What about STE, ISI?
> 
> This notification is to inform the ME that the call is accepted as a TTY
> call
> on the remote side.

I see. Using a +X... IFX style notification would have been much nicer,
but so be it. The question still remains if all other modems do it
similar.

Btw. can you provide the mailing list with an example OFONO_AT_DEBUG=1
trace for a TTY call on IFX. I really like to see one of these.

Denis, do you want an extra voicecall_tty_notify() callback or just have
it go through the voicecall_notify() one?

Regards

Marcel

Re: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Denis Kenzior]

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

Hi Marcel,

On 01/12/2011 10:48 AM, Marcel Holtmann wrote:
> Hi Jeevaka,
> 
>>>> Main reason for separate notification function is to avoid going
>>>> through all the cases handled inside voicecall_notify. TTY field in
>>>> ofono_call is basically for the GetProperties.
>>>
>>> I see. So here is the main question that comes from this now.
>>> This seems to be a bit IFX specific driven API. I still have
>>> no idea why they can not just indicate this via +CRING and
>>> have to use CTM CALL for it.
>>>
>>> Are we expecting that all modems will just establish a normal
>>> voice call and only later on signal that it is a TTY call?
>>> Any input from different vendors other than IFX. What about STE, ISI?
>>
>> This notification is to inform the ME that the call is accepted as a TTY
>> call
>> on the remote side.
> 
> I see. Using a +X... IFX style notification would have been much nicer,
> but so be it. The question still remains if all other modems do it
> similar.
> 
> Btw. can you provide the mailing list with an example OFONO_AT_DEBUG=1
> trace for a TTY call on IFX. I really like to see one of these.
> 
> Denis, do you want an extra voicecall_tty_notify() callback or just have
> it go through the voicecall_notify() one?
> 

If this is indeed a delayed handshake after the call has gone to active
state, then using a separate notification seems reasonable enough to me.

Regards,
-Denis

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Kai.Vehmanen]

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

Hello Marcel,

On 12 Jan 2011, Marcel Holtmann wrote:
> Are we expecting that all modems will just establish a normal voice
> call
> and only later on signal that it is a TTY call? Any input from
> different
> vendors other than IFX. What about STE, ISI?

not later, but as part of standard call setup. E.g. on ISI, CTM is 
a property of a voice call. And this makes sense as TTY calls _are_ 
essentially voice calls, with just a bit indicating to the network that 
the voice circuit should be free of any transcoder/audioprocessing/etc 
that is not compatible with CTM. And this is negotiated as part of standard 
call setup (same way as supported codecs).

My understanding so far has been that TextTelephony.Enabled=TRUE 
means that the CTM bit is set in all subsequent MO calls, and
it is set by default when answering to MT calls. And the one special 
case is receiving a CTM-enabled call when TTY is not enabled (in oFono). 
In this case it should be possible to enable TTY (for at least that
call) and respond to the call (and ifxmodem seems to provide support 
for this scenario).

This should be standard stuff to all modems as this is a heavily 
regulated feature.

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Jeevaka.Badrappan]

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

Hi Kai Vehmanen,

ofono-bounces(a)ofono.org wrote:

> not later, but as part of standard call setup. E.g. on ISI,
> CTM is a property of a voice call. And this makes sense as
> TTY calls _are_ essentially voice calls, with just a bit
> indicating to the network that the voice circuit should be
> free of any transcoder/audioprocessing/etc that is not
> compatible with CTM. And this is negotiated as part of
> standard call setup (same way as supported codecs).
> 

I agree but ofono_voicecall_tty_notify is to inform the
ME(MO originated ME) that the call is accepted as a TTY call on
the remote side. 

Regards,
Jeevaka

RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api

[Kai.Vehmanen]

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

Hi,

On 13 Jan 2011, Jeevaka.Badrappan(a)elektrobit.com wrote:
>> CTM is a property of a voice call. And this makes sense as
>> TTY calls _are_ essentially voice calls, with just a bit
>> indicating to the network that the voice circuit should be
>> free of any transcoder/audioprocessing/etc that is not
>> compatible with CTM. And this is negotiated as part of
>> standard call setup (same way as supported codecs).
> 
> I agree but ofono_voicecall_tty_notify is to inform the
> ME(MO originated ME) that the call is accepted as a TTY call on
> the remote side.

yup. So this is needed as it's possible that the established
voice channel is not fully CTM-compatible (either because of
network reasons, or because the called party does not have 
a TTY device attached, or does not have TTY support at all). In
this case, the TTY property for the call would be FALSE (even
if a TTY was attempted).

And this is still standard procedure (applies to all GSM modems
supporting CTM).

[RFC 4/5] ifxmodem: Add support for tty call notifications

[Jeevaka Badrappan]

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

---
 drivers/ifxmodem/voicecall.c |   36 +++++++++++++++++++++++++++++++-----
 1 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/ifxmodem/voicecall.c b/drivers/ifxmodem/voicecall.c
index d43e6f9..7401337 100644
--- a/drivers/ifxmodem/voicecall.c
+++ b/drivers/ifxmodem/voicecall.c
@@ -81,7 +81,8 @@ static int class_to_call_type(int cls)
 
 static struct ofono_call *create_call(struct ofono_voicecall *vc, int type,
 					int direction, int status,
-					const char *num, int num_type, int clip)
+					const char *num, int num_type, int clip,
+					gboolean tty)
 {
 	struct voicecall_data *d = ofono_voicecall_get_data(vc);
 	struct ofono_call *call;
@@ -95,6 +96,7 @@ static struct ofono_call *create_call(struct ofono_voicecall *vc, int type,
 	call->type = type;
 	call->direction = direction;
 	call->status = status;
+	call->tty = tty;
 
 	if (clip != 2) {
 		strncpy(call->phone_number.number, num,
@@ -280,7 +282,7 @@ static void atd_cb(gboolean ok, GAtResult *result, gpointer user_data)
 	}
 
 	/* Generate a voice call that was just dialed, we guess the ID */
-	call = create_call(vc, 0, 0, 2, num, type, validity);
+	call = create_call(vc, 0, 0, 2, num, type, validity, FALSE);
 	if (call == NULL) {
 		ofono_error("Unable to malloc, call tracking will fail!");
 		return;
@@ -546,6 +548,7 @@ static void cring_notify(GAtResult *result, gpointer user_data)
 	GAtResultIter iter;
 	const char *line;
 	int type;
+	gboolean tty = FALSE;
 
 	/* Handle the following situation:
 	 * Active Call + Waiting Call.  Active Call is Released.  The Waiting
@@ -575,11 +578,14 @@ static void cring_notify(GAtResult *result, gpointer user_data)
 	/* Ignore everything that is not voice for now */
 	if (!strcasecmp(line, "VOICE"))
 		type = 0;
-	else
+	else if (!strcasecmp(line, "CTM")) {
+		type = 0;
+		tty = TRUE;
+	} else
 		type = 9;
 
 	/* Generate an incoming call */
-	create_call(vc, type, 1, 4, NULL, 128, 2);
+	create_call(vc, type, 1, 4, NULL, 128, 2, tty);
 
 	/* Assume the CLIP always arrives, and we signal the call there */
 	DBG("cring_notify");
@@ -682,7 +688,7 @@ static void ccwa_notify(GAtResult *result, gpointer user_data)
 	DBG("ccwa_notify: %s %d %d %d", num, num_type, cls, validity);
 
 	call = create_call(vc, class_to_call_type(cls), 1, 5,
-				num, num_type, validity);
+				num, num_type, validity, FALSE);
 	if (call == NULL) {
 		ofono_error("Unable to malloc. Call management is fubar");
 		return;
@@ -692,6 +698,25 @@ static void ccwa_notify(GAtResult *result, gpointer user_data)
 		ofono_voicecall_notify(vc, call);
 }
 
+static void ctm_notify(GAtResult *result, gpointer user_data)
+{
+	struct ofono_voicecall *vc = user_data;
+	struct voicecall_data *vd = ofono_voicecall_get_data(vc);
+	GSList *l;
+	struct ofono_call *call;
+
+	l = g_slist_find_custom(vd->calls, GINT_TO_POINTER(0),
+				at_util_call_compare_by_status);
+	if (l == NULL) {
+		ofono_error("CTM for unknown call");
+		return;
+	}
+
+	call = l->data;
+
+	ofono_voicecall_tty_notify(vc, call);
+}
+
 static void ifx_voicecall_initialized(gboolean ok, GAtResult *result,
 					gpointer user_data)
 {
@@ -706,6 +731,7 @@ static void ifx_voicecall_initialized(gboolean ok, GAtResult *result,
 	g_at_chat_register(vd->chat, "+XEM:", xem_notify, FALSE, vc, NULL);
 	g_at_chat_register(vd->chat, "+XCALLSTAT:", xcallstat_notify,
 							FALSE, vc, NULL);
+	g_at_chat_register(vd->chat, "CTM CALL", ctm_notify, FALSE, vc, NULL);
 
 	ofono_voicecall_register(vc);
 }
-- 
1.7.0.4

Re: [RFC 4/5] ifxmodem: Add support for tty call notifications

[Denis Kenzior]

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

Hi Jeevaka,

> +static void ctm_notify(GAtResult *result, gpointer user_data)
> +{
> +	struct ofono_voicecall *vc = user_data;
> +	struct voicecall_data *vd = ofono_voicecall_get_data(vc);
> +	GSList *l;
> +	struct ofono_call *call;
> +
> +	l = g_slist_find_custom(vd->calls, GINT_TO_POINTER(0),
> +				at_util_call_compare_by_status);

So here we find the first call in the active state.  This is not
necessarily guaranteed to be the only active call.  Ideally this
notification should also provide the call id.

So the question is, is this safe enough and not subject to race conditions?

> +	if (l == NULL) {
> +		ofono_error("CTM for unknown call");
> +		return;
> +	}
> +
> +	call = l->data;
> +
> +	ofono_voicecall_tty_notify(vc, call);
> +}
> +

Regards,
-Denis

[RFC 5/5] doc: Describe TextTelephony property

[Jeevaka Badrappan]

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

---
 doc/voicecall-api.txt |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
index 4f38e6a..8df8fd2 100644
--- a/doc/voicecall-api.txt
+++ b/doc/voicecall-api.txt
@@ -100,6 +100,13 @@ Properties	string LineIdentification [readonly]
 			Notifications if a call becomes part or leaves a
 			multipart call are sent.
 
+		boolean TextTelephony [readonly]
+
+			Contains the indication if the voice call is a
+			text telephony call or not.
+
+			Notifications if a call is a text telephony call.
+
 		string State [readonly]
 
 			Contains the state of the current call.  The state
-- 
1.7.0.4

Re: [RFC 5/5] doc: Describe TextTelephony property

[Marcel Holtmann]

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

Hi Jeevaka,

>  doc/voicecall-api.txt |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
> index 4f38e6a..8df8fd2 100644
> --- a/doc/voicecall-api.txt
> +++ b/doc/voicecall-api.txt
> @@ -100,6 +100,13 @@ Properties	string LineIdentification [readonly]
>  			Notifications if a call becomes part or leaves a
>  			multipart call are sent.
>  
> +		boolean TextTelephony [readonly]
> +
> +			Contains the indication if the voice call is a
> +			text telephony call or not.
> +
> +			Notifications if a call is a text telephony call.
> +
>  		string State [readonly]
>  
>  			Contains the state of the current call.  The state

I am fine with actually.

Denis, any objections?

regards

Marcel

Re: [RFC 5/5] doc: Describe TextTelephony property

[Denis Kenzior]

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

Hi Marcel,

On 01/12/2011 12:00 AM, Marcel Holtmann wrote:
> Hi Jeevaka,
> 
>>  doc/voicecall-api.txt |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
>> index 4f38e6a..8df8fd2 100644
>> --- a/doc/voicecall-api.txt
>> +++ b/doc/voicecall-api.txt
>> @@ -100,6 +100,13 @@ Properties	string LineIdentification [readonly]
>>  			Notifications if a call becomes part or leaves a
>>  			multipart call are sent.
>>  
>> +		boolean TextTelephony [readonly]
>> +
>> +			Contains the indication if the voice call is a
>> +			text telephony call or not.
>> +
>> +			Notifications if a call is a text telephony call.
>> +
>>  		string State [readonly]
>>  
>>  			Contains the state of the current call.  The state
> 
> I am fine with actually.
> 
> Denis, any objections?
> 

Based on what I have heard so far, this seems fine.  However see my
concern in my reply to the IFX driver patch.

Regards,
-Denis