Subject: RE: [Sipping] Text support in SIP phones

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Jun 2003 14:14:04 +0100

I would suggest that treating these sort of things as MUST strength is best left to national regulatory requirements, along with other things like fitness for purpose and so on. I have no objection to their being mentioned. By the way, I understood this document was being progressed as authors individual submission, and was therefore not standards track.

Any such MUST would surely need to be qualified anyway. If the purpose of the devise is such that it renders a textual devise irrelevant, then why require one to be fitted. Suppose we were designing a SIP phone for the totally blind, and this was designed to be worn as a headset, a text device would be irrelevant to such a user, and positioning such a device where it could be seen would require an extra box hanging out of the side of the product.

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: 27 May 2003 17:18
> To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; 
> 'Sipforum-Discussion@Lists.
> Su. Se'
> Cc: 'Henry Sinnreich'
> Subject: RE: [Sipping] Text support in SIP phones
> 
> 
> Gunnar, this all seems very reasonable, and I will try to insert it
> properly.
> 
> Henry
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Gunnar Hellström
> > Sent: Thursday, May 22, 2003 6:54 PM
> > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se
> > Cc: Henry Sinnreich
> > Subject: [Sipping] Text support in SIP phones
> > 
> > 
> > Sorry, I missed out the reference to the SIP device specification.
> > 
> > Henry and all,
> > 
> > Some time ago, I suggested addition of support for real time 
> > text communication to the SIP device specification 
> > 
> http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt
> > 
> > This was the simple part of the proposal:
> > 
> > > SIP-zz, digital text support: SIP telephone devices MUST support
> > >   real time text conversation using RFC 2793 [y] for the 
> > text stream.
> > >   It MUST be possible to use text simultaneously with voice.
> > >
> > >
> > >
> > > ---------------------------------------------
> > > In 4.11 Ringer Behaviour  : add the section below for the 
> > purpose of 
> > > deaf, hearing impaired, deaf-blind people and people in the 
> > garden and 
> > > noisy
> > > locations:
> > >
> > > SIP Telephony devices MUST provide an external interface to an 
> > > external alerting system.
> > >
> > >
> > >
> > > Add to References
> > > -----------------
> > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC 2793, 
> > > IETF, May 2000.
> > >
> > > --------------------------------------------------------------
> > 
> > The reception of this proposal was very positive.
> > Now, I would like to see the final formulation, and check 
> > that we agree on it.
> > 
> > I regard this requirement to be very light. In the Interface 
> > section ( e.g.
> > Int-2) , there is already mentioning of mandatory text input 
> > mechanisms, and assumptions that a display would be normal, 
> > since handling of phone books and buddy lists are mandatory. 
> > To re-use these text interface devices during the call for 
> > standardised text conversation purposes seems straightforward.
> > 
> > It could be wise to add the T.140 text presentation protocol 
> > as a codec to the codec section. The normal SDP used together 
> > with RFC2793 for text could also be specified. Do you want 
> to do that?
> > 
> > 
> > -----
> > 
> > We also need to check the ideas around the other proposed 
> > requirements: The requirement to include text telephone modem 
> > in all designs where an RJ11 phone connector exists, and the 
> > requirement to support RFC 3351. I suggest that we start with 
> > the straightforward and mainstream requirement above. Is that 
> > accepted as it is?
> > 
> > 
> > Regards
> > 
> > Gunnar
> > -------------------------------------------
> > Gunnar Hellström, Omnitor, Renathvägen 2
> > SE 121 37 Johanneshov, SWEDEN
> > Tel: +46 8 556 002 03  Mob: +46 708204288
> > e-mail: [email-masked]
> > web: www.omnitor.se
> > 
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current 
> > sip Use [email-masked] for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 10 Jun 2003 11:01:35 -0500

Keith, thanks for bringing balance, I believe, to this discussion.

We could formulate soemthing like "SIP phones that have a text display
and advertised as supporting the hearing or speech disabled MUST..."

Would this be OK?

Henry

> On Behalf Of Drage, Keith (Keith)
> Sent: Tuesday, June 10, 2003 8:14 AM
> To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. 
> Org'; 'Sipforum-Discussion@Lists. Su. Se'
> I would suggest that treating these sort of things as MUST 
> strength is best left to national regulatory requirements, 
> along with other things like fitness for purpose and so on. I 
> have no objection to their being mentioned. By the way, I 
> understood this document was being progressed as authors 
> individual submission, and was therefore not standards track.
> 
> Any such MUST would surely need to be qualified anyway. If 
> the purpose of the devise is such that it renders a textual 
> devise irrelevant, then why require one to be fitted. Suppose 
> we were designing a SIP phone for the totally blind, and this 
> was designed to be worn as a headset, a text device would be 
> irrelevant to such a user, and positioning such a device 
> where it could be seen would require an extra box hanging out 
> of the side of the product.
> 
> regards
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked] 
> 
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listi> nfo/sipping
> > > This list 
> is for NEW development of the 
> application of SIP Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > > 
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 11 Jun 2003 04:58:58 -0500

Gunnar, thanks for bringing this up! I believe now we can ask for
discussion time at the SIPPING WG meeting.

Henry

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Gunnar Hellström
> Sent: Tuesday, June 10, 2003 2:42 PM
> To: Henry Sinnreich; 'Drage, Keith (Keith)'; 'Sipping@Ietf. 
> Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support 
> in SIP phones
> 
> 
> I agree that this discussion starts to get balance into the 
> specification of the real time text conversation feature.
> 
> Firstly, I have discovered that I need to explain again that 
> what we talk about is a real time, character by character 
> transmission and display of text. You can see the thought as 
> it is growing and being formed into text. It is a very direct 
> way to have contact, and once you have used it, you realize 
> that in some applications it is essential to have access to 
> this feature. It has the same immediate flow as audio in 
> voice telephony and video in video telephony.
> 
> In fact, there is a name for the three media together, it is 
> called Total Conversation.
> 
> It is true that the force behind defining it has come from 
> the needs of people with communication related disabilities. 
> But I am sure that once commonly implemented, it will become 
> a natural and popular feature that is often used during voice 
> calls between most users.
> 
> Instant messaging is also a very handy service. But it goes 
> message by message, and therefore does not have the direct 
> touch as the real time conversational service in voice, text 
> and video has.
> 
> 
> 
> We have a forerunner in the specification of media for the 
> SIP based IP Multimedia phone in 3GPP. Maybe we can pick the 
> same style of specification. In 3GPP TS 26.235, "Packet 
> switched conversational multimedia applications, default 
> codecs", it is specified among the enumeration of supported media:
> 
> 6.3	Real time text
> 3G PS multimedia terminals offering real time text 
> conversation should support ITU-T Recommendation T.140 [25] 
> Text Conversation presentation coding.
> 
> And in the chapter on RTP payload, it is specified:
> 
> 9.2	RTP payload
> RTP payload formats specified by IETF shall be used for real 
> time media streams. RTP payload format for the AMR narrowband 
> speech codec is specified in annex B. RTP payload format for 
> the AMR wideband speech codec is specified in annex B. RTP 
> payload format for the ITU-T Recommendation H.263 [6] video 
> codec is specified in IETF RFC 2429 [3]. RTP payload format 
> for the MPEG-4 visual simple profile level 0 is specified in 
> IETF RFC 3016 [5]. RTP payload format for the ITU-T 
> Recommendation T.140 [25] text conversation coding is 
> specified in IETF RFC 2793 [24].
> 
> In the annex A on specific details, the following is 
> specified for text:
> 
> A.3	Text
> Use of the redundancy coding variant specified in RFC 2793 
> [24] is recommended for error resilience.
> 
> --------------------------------
> When this topic was handled in 3GPP, there was opposition 
> against mentioning the reason for introducing the text 
> feature as being something specific for disabled people.
> 
> I think that is still valid.
> 
> I suggest that the following formulation is used:
> **************************************************************
> **************
> **************************************
> SIP-zz, digital text support: SIP telephone devices SHOULD 
> support real time text conversation. If text is supported, it 
> MUST support RFC2793 [y], for text coding and packetization, 
> and it MUST be possible to use text simultaneously with voice.
> **************************************************************
> **************
> **************************************
> 
> 
> Gunnar
> > -----Ursprungligt meddelande-----
> > Från: [email-masked]
> > [mailto:[email-masked]]För Henry Sinnreich
> > Skickat: den 10 juni 2003 18:02
> > Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar 
> Hellström'; 
> > 'Sipping@Ietf. Org'; 'Sipforum-Discussion@Lists. Su. Se'
> > Ämne: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones
> >
> >
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Drage, Keith (Keith)
> > > To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. Org'; 
> > > 'Sipforum-Discussion@Lists. Su. Se'
> > > I would suggest that treating these sort of things as 
> MUST strength 
> > > is best left to national regulatory requirements, along 
> with other 
> > > things like fitness for purpose and so on. I have no objection to 
> > > their being mentioned. By the way, I understood this document was 
> > > being progressed as authors individual submission, and 
> was therefore 
> > > not standards track.
> > >
> > > Any such MUST would surely need to be qualified anyway. If the 
> > > purpose of the devise is such that it renders a textual devise 
> > > irrelevant, then why require one to be fitted. Suppose we were 
> > > designing a SIP phone for the totally blind, and this was 
> designed 
> > > to be worn as a headset, a text device would be 
> irrelevant to such a 
> > > user, and positioning such a device where it could be seen would 
> > > require an extra box hanging out of the side of the product.
> > >
> > > regards
> > >
> > > Keith
> > >
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: [email-masked]
> > >
> > > > 'Sipforum-Discussion@Lists. Su. Se'
> > > > Cc: 'Henry Sinnreich'
> > > > Gunnar, this all seems very reasonable, and I will try 
> to insert 
> > > > it properly.
> > > >
> > > > Henry
> > > >
> > > > > From: [email-masked] 
> [mailto:[email-masked]] On 
> > > > > Behalf Of Gunnar Hellström
> > > > > Now, I would like to see the final formulation, and 
> check that 
> > > > > we agree on it.
> > > > >
> > > > > since handling of phone books and buddy lists are 
> mandatory. To 
> > > > > re-use these text interface devices during the call for 
> > > > > It could be wise to add the T.140 text presentation 
> protocol as 
> > > > > a codec to the codec section. The normal SDP used 
> together with 
> > > > > RFC2793 for text could also be specified. Do you want
> > > > to do that?
> > > > >
> > > > >
> > > > > -----
> > > > >
> > > > > requirements: The requirement to include text 
> telephone modem in 
> > > > > all designs where an RJ11 phone connector exists, and the 
> > > > > [email-masked] for questions on current sip 
> > > > https://www1.ietf.org/mailman/listinfo/sipping

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 10 Jun 2003 21:41:48 +0200

I agree that this discussion starts to get balance into the specification of
the real time text conversation feature.

Firstly, I have discovered that I need to explain again that what we talk
about is a real time, character by character transmission and display of
text. You can see the thought as it is growing and being formed into text.
It is a very direct way to have contact, and once you have used it, you
realize that in some applications it is essential to have access to this
feature. It has the same immediate flow as audio in voice telephony and
video in video telephony.

In fact, there is a name for the three media together, it is called Total
Conversation.

It is true that the force behind defining it has come from the needs of
people with communication related disabilities. But I am sure that once
commonly implemented, it will become a natural and popular feature that is
often used during voice calls between most users.

Instant messaging is also a very handy service. But it goes message by
message, and therefore does not have the direct touch as the real time
conversational service in voice, text and video has.

We have a forerunner in the specification of media for the SIP based IP
Multimedia phone in 3GPP. Maybe we can pick the same style of specification.
In 3GPP TS 26.235, "Packet switched conversational multimedia applications,
default codecs", it is specified among the enumeration of supported media:

6.3	Real time text
3G PS multimedia terminals offering real time text conversation should
support ITU-T Recommendation T.140 [25] Text Conversation presentation
coding.

9.2	RTP payload
RTP payload formats specified by IETF shall be used for real time media
streams.
RTP payload format for the AMR narrowband speech codec is specified in annex
B.
RTP payload format for the AMR wideband speech codec is specified in annex
B.
RTP payload format for the ITU-T Recommendation H.263 [6] video codec is
specified in IETF RFC 2429 [3].
RTP payload format for the MPEG-4 visual simple profile level 0 is specified
in IETF RFC 3016 [5].
RTP payload format for the ITU-T Recommendation T.140 [25] text conversation
coding is specified in IETF RFC 2793 [24].

In the annex A on specific details, the following is specified for text:

A.3	Text
Use of the redundancy coding variant specified in RFC 2793 [24] is
recommended for error resilience.

--------------------------------
When this topic was handled in 3GPP, there was opposition against mentioning
the reason for introducing the text feature as being something specific for
disabled people.

I suggest that the following formulation is used:
****************************************************************************
**************************************
SIP-zz, digital text support: SIP telephone devices SHOULD support real time
text conversation.
If text is supported, it MUST support RFC2793 [y], for text coding and
packetization, and it MUST be possible to use text simultaneously with
voice.
****************************************************************************
**************************************

Gunnar

> Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar Hellström';

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 11 Jun 2003 23:39:46 +0200

OK, I think it would be fine to bring the introduction of real time text
conversation up for discussion in the SIPPING group.

I think that the small requirement statements we have discussed so far for
the sipdev specification are sufficient for that level.

But I have noticed some uncertainty from developers on what SDP to use to
open the RFC2793 text channel, and about some other good implementation
habits around the text channel. We need to be sure that there is good
agreement on such issues, so that we get maximum harmonization and
interoperability between implementations. ( real time text conversation in
the PSTN has a terrible history of fragmentation and incompatibility, and it
is time to make sure that is history now )

I want to have your advice if you want to see also SDP examples for the text
channel in the sipdev spec, in a separate Text Conversation Best Code of
Practice spec, or if there is any plan for a sipdev-technical guideline spec
where it could fit.

Gunnar

> Från: Henry Sinnreich [mailto:[email-masked]]
> Skickat: den 11 juni 2003 11:59
> Till: 'Gunnar Hellström'; 'Sipping@Ietf. Org';
> 'Sipforum-Discussion@Lists. Su. Se'; 'Drage, Keith (Keith)'
> Ämne: RE: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones
>
>

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 13 Jun 2003 13:17:57 -0500

> I want to have your advice if you want to see also SDP 
> examples for the text channel in the sipdev spec, in a 
> separate Text Conversation Best Code of Practice spec, or if 
> there is any plan for a sipdev-technical guideline spec where 
> it could fit.

I believe a short I-D with SDP examples for the text channel would very
productive and could serve as reference for the SIP Telephony Device I-D
and other.

Thanks, Henry

> Sent: Wednesday, June 11, 2003 4:40 PM
> To: Henry Sinnreich; 'Sipping@Ietf. Org'; 
> OK, I think it would be fine to bring the introduction of 
> real time text conversation up for discussion in the SIPPING group.
> 
> I think that the small requirement statements we have 
> discussed so far for the sipdev specification are sufficient 
> for that level.
> 
> But I have noticed some uncertainty from developers on what 
> SDP to use to open the RFC2793 text channel, and about some 
> other good implementation habits around the text channel. We 
> need to be sure that there is good agreement on such issues, 
> so that we get maximum harmonization and interoperability 
> between implementations. ( real time text conversation in the 
> PSTN has a terrible history of fragmentation and 
> incompatibility, and it is time to make sure that is history now )
> 
> I want to have your advice if you want to see also SDP 
> examples for the text channel in the sipdev spec, in a 
> separate Text Conversation Best Code of Practice spec, or if 
> there is any plan for a sipdev-technical guideline spec where 
> it could fit.
> 
> 
> Gunnar
> 
> > > [mailto:[email-masked]] On Behalf 
> Of Gunnar 
> > > Hellström
> > > To: Henry Sinnreich; 'Drage, Keith (Keith)'; 'Sipping@Ietf. Org'; 
> > > Subject: SV: [Sipforum-discussion] RE: [Sipping] Text 
> support in SIP 
> > > phones
> > >
> > >
> > > Firstly, I have discovered that I need to explain again 
> that what we 
> > > talk about is a real time, character by character 
> transmission and 
> > > display of text. You can see the thought as it is growing 
> and being 
> > > formed into text. It is a very direct way to have 
> contact, and once 
> > > you have used it, you realize that in some applications it is 
> > > essential to have access to this feature. It has the same 
> immediate 
> > > flow as audio in voice telephony and video in video telephony.
> > >
> > > In fact, there is a name for the three media together, it 
> is called 
> > > Total Conversation.
> > >
> > > It is true that the force behind defining it has come 
> from the needs 
> > > of people with communication related disabilities. But I am sure 
> > > that once commonly implemented, it will become a natural 
> and popular 
> > > feature that is often used during voice calls between most users.
> > >
> > > Instant messaging is also a very handy service. But it 
> goes message 
> > > by message, and therefore does not have the direct touch 
> as the real 
> > > time conversational service in voice, text and video has.
> > >
> > >
> > >
> > > We have a forerunner in the specification of media for 
> the SIP based 
> > > IP Multimedia phone in 3GPP. Maybe we can pick the same style of 
> > > specification. In 3GPP TS 26.235, "Packet switched conversational 
> > > multimedia applications, default codecs", it is specified 
> among the 
> > > enumeration of supported media:
> > >
> > > 6.3	Real time text
> > > 3G PS multimedia terminals offering real time text conversation 
> > > should support ITU-T Recommendation T.140 [25] Text Conversation 
> > > presentation coding.
> > >
> > > RTP payload formats specified by IETF shall be used for real time 
> > > media streams. RTP payload format for the AMR narrowband speech 
> > > codec is specified in annex B. RTP payload format for the AMR 
> > > wideband speech codec is specified in annex B. RTP payload format 
> > > for the ITU-T Recommendation H.263 [6] video codec is 
> specified in 
> > > IETF RFC 2429 [3]. RTP payload format for the MPEG-4 
> visual simple 
> > > profile level 0 is specified in IETF RFC 3016 [5]. RTP payload 
> > > format for the ITU-T Recommendation T.140 [25] text conversation 
> specified for 
> > > text:
> > > When this topic was handled in 3GPP, there was opposition against 
> > > mentioning the reason for introducing the text feature as being 
> > > something specific for disabled people.
> > >
> > > SIP-zz, digital text support: SIP telephone devices 
> SHOULD support 
> > > real time text conversation. If text is supported, it 
> MUST support 
> > > RFC2793 [y], for text coding and packetization, and it MUST be 
> > > possible to use text simultaneously with voice.
> > > > > things like fitness for purpose and so on. I have no 
> objection 
> > > > > to their being mentioned. By the way, I understood 
> this document 
> > > > > was being progressed as authors individual submission, and
> > > was therefore
> > > > > not standards track.
> > > > >
> > > > > > > The reception of this proposal was very positive. Now, I 
> > > > > > > would like to see the final formulation, and
> > > check that
> > > > > > > we agree on it.
> > > > > > >
> > > > > > > requirement to support RFC 3351. I suggest that we start 
> > > > > > > with the straightforward and mainstream 
> requirement above. 
> > > > > > > Is that accepted as it is?
> > > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Gunnar
> > > > > > > [email-masked] for questions on current

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 13 Jun 2003 14:18:58 -0500

> Text Conversation presentation coding.

This is a very usefyl reference! It does not say "ALL" or "MUST", but
"terminals offering real time text conversation should support ITU-T
Recommendation T.140". I guess in IETF language the "should" would be
"SHOULD".

Thanks, Henry