Subject: [Enum] Comment on draft-ietf-enum-voice-01.txt about calls needing text capability

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 2 Nov 2005 00:14:33 +0100

I have a question related to draft-ietf-enum-voice-01.txt

( http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt  )

In PSTN, we have a service called text telephony. You can use real time text
and voice alternating if you use text telephony. You can also on the same
number use text in some calls and voice in others. You usually combine a
terminal by a telephone and a text telephone. The text telephone makes use
of some modem transmission for the text, but is made silent when there is a
wish to talk instead.

On the IP side you may have real time transmission of text and voice
simultaneously in a terminal including a voice codec and a text codec. Text
is text coded and packetized. ( RFC 4103 is the currently only defined
transport for real time text with IP terminals ). It is also popular to
combine with video.

Now, too many gateways have been deployed without support for translating
between PSTN text and IP text. So, for calling between these environments,
you need a way to route the call to the right gateway, with text capability.
But note, it shall only have text capability. In most cases it should start
silent, just monitoring the two sides for text activity, and then activate
text functionality towards PSTN.

Sadly, PSTN users have the habit to bring their text telephones and plug
them into the telephone connection without setting up any NAPTR records for
an occasional visit. So, I have some urgent questions if enum can contribute
to finding the right gateway supported path for the calls that might contain
text.

When reading draft-ietf-enum-voice-01.txt , I get the impression that we
would need something similar for the "text and voice" service. For now, let
us call it the "rtext" enumservice. ( or do you want to se it called
"votex"? ). I have prepared a draft, based on one of the other enumservice
registration documents, and am prepared to submit it if you find it
motivated.

But first some questions:

1. Do you find it feasible to register an enumservice "rtext" for real time
text possibly combined with voice in the same call?

2. Will the "voice" enumservice imply something for the possibility to use
other media in the same call?

Regards

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Wed, 2 Nov 2005 00:34:54 +0000

Hi Gunnar, folks,
Background: Almost all of these PSTN Enumservices are tricky.
They don't define a means to make the connection, as that could be  
direct or indirect.
They don't care how the ENUM Client's terminal does it - the  
Enumservice spec just
tells him or her what to expect if this contact is used (i.e. it's  
something like
a teleservice identifier tagged along with a tel: URI)

So... If a NAPTR has voice:tel as its Enumservice (with a tel: URI in  
the REGEXP
field) then this says that a voice call cal be made to this telephone  
number.

If a NAPTR has an sms:tel Enumservice, then it says that the  
destination reached
by this telephone number can handle SMS messages.

Most mobile phones can do both, so it is perfectly valid to have a  
single NAPTR
with both Enumservices in it - something like:
$ORIGIN 0.0.0.0.6.9.4.1.4.1.4.4.e164.arpa.
.  IN NAPTR 100 10 "u" "E2U+voice:tel+sms:tel" "!^.*$!tel: 
+447700900000!" .

In effect, this compound NAPTR says that you can make a voice call or  
send an
SMS to this number.

Now... if you are suggesting that the ugly audio+text abominations  
that still
exist do multiplexed voice AND text at the same time, then this seems  
to me to
be a different teleservice from "pure" voice.

If this is true, then I'd suggest that it needs a different  
Enumservice specification
- the recipient of the NAPTR will not expect to be able to plug in an  
old-style text
phone if they see E2U+voice:tel. However, if this telephone number  
also handles normal
voice calls as well (as I guess it will), then showing both  
Enumservices in a single
NAPTR would be perfectly valid.

Hence an appropriate example would be:
$ORIGIN 1.0.0.0.9.6.4.7.0.2.4.4.e164.arpa.
.  IN NAPTR 100 10 "u" "E2U+voice:tel+vortex:tel" "!^.*$!tel: 
+442079460001!" .

Quick question:
If there are broken old gateways that can't handle conversion from  
old-style
PSTN text phone signals to 4103 style IP real time text, then how  
does one
use these boxes to bridge between a conversational text device on the  
Internet
to some text phone connected to the PSTN?
PSTN->IP looks like a nightmare, whilst IP->PSTN is still a  
challenge, if the
gateway doesn't do conversion to and from 4103.

In that case, I would have thought it was easier to have a PC with a  
4103-capable
program running rather than use a PSTN-connected text phone - just  
use the
Internet and forget the old gateways and the PSTN altogether. What am  
I missing?

----
Of course, if you were doing something sensible like using 4103, then  
be aware
that you are vanishingly unlikely to get an Enumservice approved that  
indicates
that your SIP AoR is associated with a permanently registered device  
that can
handle 4103-style text conversations. To do so would be wrong, and  
such heresy
will not be anointed with an RFC. It's a funny world, isn't it.

all the best and good luck,
   Lawrence

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 2 Nov 2005 08:37:34 +0100

Lawrence and all,
Thanks for good explanations, hints and leads to further discussions.
And thanks for the name proposal "vortex" for the combined voice and text
service ;-

We have a pile of situations to solve in order to guide calls between PSTN
text telephones and text capable IP terminals. Proper use of enum seems to
be one good piece in the puzzle.

We also have a need for smart invocation of translation services where enum
also could play a role.

The need
---------
Humans need to communicate in conversational mode with at least voice, text
and video. They should not need to bother much about what kind of network
the other party is connected to. But the tools and transmission technology
varies between the networks.

For voice there is reasonable coverage in interoperable networks. But for
the text medium, the development has not been that forceful. We have RFC
4103 that is used to carry text in IP calls, and you can do it in a full
multimedia fashion, with simultaneous voice and text. But there are too few
gateways between PSTN calls containing text and IP calls with text.

So, one need is to have a means to route calls PSTN -> IP and IP -> PSTN
through the right kind  of text enabled gateway. The gateway may very well
also be able to handle pure voice. It may also be a series connection of a
voice gateway and an IP located transcoder between audio and IP text.

IP -> PSTN
----------
Let us start with IP -> PSTN . Assigning an enumservice name for the
text+voice service in PSTN would make it possible to show to the IP caller
that this PSTN terminal can handle text AND that it can be reached through a
suitable gateway. But enum itself would not give the hint on how to find
that gateway, only that it can be requested. That is at least halfway.

Now, assume that the PSTN textphone user is in a hotel room with PSTN
connection. He cannot influence the NAPTR record but want to get an incoming
text call. The calling IP endpoint would not get assured that it is possible
to call by text, so what does he do to make the call . Should it take that
as an indicator that there is a need to invoke a separate transcoding
service between RFC 4103 and audio coded text?  ( there must be a similar
situation for FAX, how have you solved that ? )

Also assume in a bright future, all gateways will be capable of doing bot
voice gatewaying and voice+text gatewaying. Then all enum lookups for these
services could look for either "voice" or "voicetext" with the same good
result. How can we at that time reduce complexity in our NAPTR records and
return to one simple specification of just one of them?

Name "rtxt" "text" "voicetext" vortex" "txp" "votext" ?
-------------------------------------------------------
Please help to assign a name for the service! In an offline discussion we
were close to assigning "rtxt" or "text" to it when we hesitated because it
may be good to show its voice capabilities as well in the name.

As soon as we have a proposed name, I can submit a draft proposing
registering it as an enumservice for the scheme "tel".

Regards
Gunnar
----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked] <mailto:[email-masked]>
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se <http://www.omnitor.se>

Subject: Re: [Enum] Comment on draft-ietf-enum-voice-01.txt about
callsneeding text capability

Hi Gunnar, folks,

Quick question:

----