KPN ondersteunt chatten zonder verzendknop tijdens bellen

De Nederlandse provider KPN begint met de ondersteuning voor realtimetext (rtt), een manier om te chatten waarbij elke letter die een gebruiker typt bij de andere partij meteen op het scherm verschijnt. Dat kan alleen tijdens bellen.

Bij het bellen zal, als beide telefoons en providers het ondersteunen, een knop komen voor rtt, schrijft KPN. Vervolgens opent zich tijdens de telefoonverbinding een chatvenster, waarbij de andere gebruiker live kan meelezen met elke letter die de gebruiker typt. Op termijn gaat de technologie ook werken bij contact met hulpdiensten, zegt KPN.

Voorlopig komt de functie via een update op telefoons van Samsung en later dit jaar volgt ondersteuning voor andere merken. De technologie werkt al bij gebruikers in de VS en Canada, maar binnen Europa claimt KPN de eerste te zijn. De provider noemt het vooral een functie om de toegankelijkheid te verbeteren. "Het biedt een oplossing voor mensen met spraak- of gehoorproblemen." Wanneer ondersteuning bij andere providers en telefoons precies volgt, is vooralsnog onduidelijk. De wetgeving die het aanbieden van rtt verplicht stelt, gaat eind deze maand in. Het werkt vooralsnog alleen tussen KPN-klanten.

Reacties (77)

[ultimasnake]

"Het biedt een oplossing voor mensen met spraak- of gehoorproblemen."

Dit zal dus vooral uitkomst bieden als een telemarketeer je belt en je hem/haar niet kan vertellen hoe/wat? Want als een bekende je zou willen bellen had ie dit al geweten en niet gebeld?

[jpfx]

Ik snap uberhaupt niet waarom dat een oplossing voor mensen met spraak - of gehoor problemen oplevert.
Of je letter-voor-letter leest, of zin-voor-zin nadat op verzenden is gedrukt. Het enige wat het veroorzaakt is dat men NOG-MEER gefocused is op het mobieltje, want je zal maar eens een letter missen....

[GertMenkel]

Het protocol dat gebruikt wordt is ter vervanging van een bestaand real-time-protocol dat doven in staat stelt om de telefoon te gebruiken in combinatie met een soort typmachine en een tolk aan de andere kant. Het protocol is ontstaan als toegankelijkheidsoptie, maar er is geen technische reden waarom de optie niet in ieder gesprek beschikbaar is. Het is en blijft een SIP/RTP-berichtje dat nu toevallig door de dialer van je telefoon begrepen wordt in plaats van genegeerd.

Als je een vraag stelt via een telefonische doventolk, kan de andere kant een heel verhaal gaan vertellen, en wil je niet per se wachten tot de tolk het bericht in stukken heeft afgetypt. Mogelijk wil je inhaken, of halverwege een vraag stellen. Overigens is de techniek nu zo ver dat beeldbellen en andere opties een stuk beter zijn geworden, maar het originele typmachine-met-draad-aan-telefoon-protocol is de oorsprong van RTT.

In theorie kan de dialer een optie "direct sturen" en "doventolkmodus" bieden. Misschien gaat dat ook gewoon gebeuren zodra niet-Samsung-providers het protocol implementeren. Maar in feite is de hele functie vooral beschikbaar omdat het meer moeite kost om het alleen voor (nood)oproepen voor doven te implementeren dan voor ieder telefoontje van iedereen.

[laptopleon]

OK, dat is wel een zeer specifieke situatie die niet blijkt uit het artikel, maar dan nog begrijp ik niet waarom het per se letter voor letter realtime zichtbaar moet zijn.

[Reactie gewijzigd door laptopleon op 3 juni 2025 11:21]

[GertMenkel]

Het artikel is geschreven vanuit het oogpunt van de telefoonmakers die deze feature willen verkopen aan hun klanten. Ik denk dat de redactie van Tweakers wel betere dingen te doen heeft dan een doolhof van 3GPP/ITU/ETSI-specificaties lezen, dus dat is ook niet zo heel gek.

Op dit moment moet je op Android nog een TTY-apparaat aansluiten op je telefoon om RRT/TTY te gebruiken (YouTube: RelaySD: Making and receiving a TTY call laat zo'n ding zien), dus ik denk dat mensen die hier gebruik van maken hier heel blij mee zullen zijn.

[laptopleon]

Begrijp me goed; dat ik het grote voordeel niet zie, betekent natuurlijk nog niet dat het voor anderen niet heel fijn en praktisch kan zijn.

Ooit, pre-2000 gebruikte ik op de Mac een chat app waarbij je ook elke letter zag worden ingetypt en eventueel worden weggehaald (kan even niet op de naam komen) en dat geeft toch meer het gevoel dat je echt met elkaar aan het converseren bent.

[bogy]

Ik kan me ook nog een chatapp herinneren die elke letter die je typte liet zien, en ook weer als je bv backspace gebruikt...

Ik herinner me nog goed dat die app niet lang populair was want iedereen komt wel eens in de situatie dat je iets typt dat je eigenlijk beter niet zegt en dat je dus weer wist voordat je op Enter/Send drukt/klikt... Met die instant-chat krijgt de tegenpartij dus wel te zien dat je vindt dat ie iets debiels zegt, ook al wis je het later weer om te zeggen dat zijn opmerking ondoordacht is...

Ik denk dat de "funfactor" er op een weekje gebruiken al weer uit was en iedereen ging toen terug naar ICQ of msn.
die rtt functie is echt iets wat niet meer dan een gadget, mensen met gehoorproblemen kunnen gewoon sms'en of whatsappen, ze kunnen zelfs via whatsapp hun gebarentaal gewoon live gebruiken, daar dient een videochat toch voor?

die rtt is in mijn ogen zoals iemand die afkomt met een 8-hoekig wiel terwijl we het ronde wiel al lang hebben uitgevonden...

[Aldy]

Begrijp me goed; dat ik het grote voordeel niet zie, betekent natuurlijk nog niet dat het voor anderen niet heel fijn en praktisch kan zijn.

Misschien fijn als er iemand is die uit kan leggen wat hier het voordeel van is. Alle voorbeelden die ik voorbij heb zien komen werden á la minuut weer weerlegd.

Ik hou graag mijn telefoon tegen mijn oor, dus dat wordt moeilijk. Voor mijn mond, zoals ik vaak zie en iedereen mijn telefoongesprek mee kan luisteren? Afgezien dat ik vind dat dit privé is, vind ik het ook asociaal om anderen met mijn gesprek te storen.

Nogmaals, misschien dat iemand uit kan leggen wat het voordeel is.

[TheMak]

Dat is wel de bedoeling van een telefoongesprek. Ik bel niet zovaak, maar als ik bel dan is het wel de bedoeling dat ik de focus heb van de ander. En dat mijn bericht niet tussen de andere tekstberichten verdwijnt.

[ultimasnake]

Ik snap het ook niet helemaal (vooral letter voor letter), maar ik ken iemand met een gehoorsprobleem en als die zijn apparaatjes niet in heeft heeft ie op z'n iPhone gewoon een reactie ingesteld staan die hij standaard verstuurd "Sorry ik kan je helaas niet horen als ik opneem, ik stuur je een berichtje via Whatsapp" waarna hij dit ook doet en je dus zo verder kan praten :-)

En ik meen dat ook Android dergelijke opties heeft.


Dat werkt natuurlijk niet naar een bedrijf, maar of die deze optie plots gaan ondersteunen betwijfel ik

[Cid Highwind]

In de regel is het gehoorprobleem echter aan de kant van de telemarketeer. Hoe dit daarvoor een oplossing gaat zijn is mij een raadsel.

[Dark Angel 58]

"Het biedt een oplossing voor mensen met spraak- of gehoorproblemen."

Dit zal dus vooral uitkomst bieden als een telemarketeer je belt en je hem/haar niet kan vertellen hoe/wat? Want als een bekende je zou willen bellen had ie dit al geweten en niet gebeld?

Over telemarketeer gesproken, dat kan binnenkort niet meer... ze moeten echt je toestemming hebben om jou te mogen bellen Ik geloof dat het volgende jaar 1 juli 2026 ingaat. Best wel fijn voor de doven, omdat telemarketeer echt stopt als je nee of dat je niet meer gebeld wil worden zegt. Daarom deugt vervanging van "bel mij niet meer register" wet helemaal niet.

[ultimasnake]

Dat is een fijn idee, of ze zich er aan houden? Of laat ik het zo zeggen: Of je niet ergens toch ooit een random vinkje hebt gezet ter akkoord van een 400 pagina tellend voorwaarden document waardoor ze je tot einde der tijd mogen bellen ongeacht het product....

Misschien ook wel het einde van volgens mij het meest nare beroep op aarde.....

[Reactie gewijzigd door ultimasnake op 2 juni 2025 15:48]

[Dark Angel 58]

Volgens mij komt er een aparte vraag: mogen telemarketeers (of de mensen van bedrijf) met je telefonisch contact opnemen? Hopelijk is het nieuwe wettelijk verplicht. Zet het dan op "nee" of het niet aanvinken. Dus laat ze maar per e-mail sturen.
Dat heb ik een paar keer gezien.


EN ja dat hoop ik zo... van mij mag telemarketing voorgoed afgeschaft worden, want het is duivels uitvinding om mensen te blijven irriteren. Na hoeveelste nee word je echt gek van? Ik had al plannen gemaakt om ze voorgoed naar de mijnen te sturen

[Reactie gewijzigd door Dark Angel 58 op 2 juni 2025 16:12]

[Groentjuh]

Dus dan hebben we RTT, maar RCS (opvolger SMS) lijkt nog ergens in de pijplijn te zitten.

[lenwar]

Persoonlijk heb ik liever dat de grote messaging-systemen door elkaar heen gebruikt kunnen gaan worden. (dus iMessage/Signal/WhatsApp/enz.) dan dat ik een afhankelijkheid krijg van m'n telecomboer.

RCS is niet versleuteld (qua protocol), die andere systemen zijn dat wel.

(uiteraard heeft de Google-berichten-app een versleutelingsfunctie, maar dat is dan dus niet hard in het protocol. Dat komt er op neer dat je een bericht versleuteld en dan met http over de lijn stuurt. Technisch niets mis mee, maar het is niet hetzelfde.)

[GertMenkel]

Hoewel de implementatie nog verre van af is voor cross-platform-RCS, is Android-naar-Android-RCS al wel versleuteld (via Signal's protocol en MLS in een base64 wrapper). RCS heeft niet de "wie praat met wie"-anonimiteit die Signal aanbiedt, maar daar is Signal ook de enige in.

Ook wordt RCS-versleuteling gestandaardiseerd door de GSMA die Apple en Google beiden gaan ondersteunen. Zodra dat gebeurd is, zou ik RCS niet als meer of minder veilig dan iMessage of WhatsApp beschouwen (Signal blijft nog altijd de veiligste).

Een goed versleuteld protocol werkt ook over onveilige verbindingen. Een versleutelde RCS-payload moet onkraakbaar aankomen over HTTP, anders is de versleuteling niet goed (en die is gebaseerd op open standaarden die door experts zijn ontwikkeld). In de praktijk zal RCS hopelijk over HTTPS gaan i.p.v. HTTP, maar omdat je 4G/5G-verbinding toch al versleuteld is tussen jou en je provider voegt dat niet direct iets toe.

Google's RCS is voor zover ik weet niet anders dan normale RCS behalve dat hun server buiten het netwerk van de telecomprovider staat en dus wel over TLS wordt verstuurd voor extra veiligheid. Het gestandaardiseerde protocol gebruikt eigenlijk alle onderdelen die Google ook al in hun semi-open specificatie gebruikte. Niet gek, aangezien ze zowel de grootste RCS-client (Android Messages) onder beheer hebben als de populairste RCS-server (Google Jibe, zowel hun eigen als de versie die je als provider van ze kunt afnemen). Als enige echte RCS-implementatie die succes heeft geboekt, hebben ze praktisch het protocol kunnen schrijven, maar omdat ze met andere providers moesten samenwerken is het gelukkig niet Google-gecentreerd uit de pers komen rollen.

[lenwar]

Klopt. Maar laten we eerlijk zijn. We leven in 2025. We zijn druk bezig met alles te versleutelen.

RCS is als mechanisme in 2008 bedacht en sinds 2016 voor het echie in gebruik (De Universal Profile). Wie in z'n gezonde verstand heeft in die periode bedacht om een niet-versleuteld standaardprotocol uit te brengen? (Antwoord: De adverteerders.) Ter context. Het Signal-protocol is uit 2013 en TLS1.2 is uit 2008.

[quote]...toch al versleuteld is tussen jou en je provider voegt dat niet direct iets toe.[/quote] Waarom zou je accepteren dat je ISP en (malware op) je besturingssysteem je berichtjes mee kan lezen/advertenties kan injecteren/enz.?

Juist door het al te versleutelen binnen de app, zorgt ervoor dat andere processen (binnen het) besturingssysteem niet mee kunnen kijken. (zie hier de toegevoegde waarde van DoH binnen een browser/applicatie )

[GertMenkel]

Als iemand versleuteling op RCS wil voorkomen, is het in elk geval niet de adverteerders. De grote adverteerder hier, de enige die wat met RCS kan, heeft de client en sleutels al in beheer, en kan ieder bericht onversleuteld lezen als ze dat zouden willen.

RCS is vanaf 2010 in gebruik geweest bij providers. Apps zijn ontwikkeld, en tientallen, misschien zelfs honderden mensen hebben die gedownloaded om gratis berichtjes te kunnen sturen over WiFi. Het protocol werd ontwikkeld lang voordat chatapplicaties E2EE deden, en was al in gebruik in productie nog voor de eerste alfa van een veilige chatdienst daadwerkelijk gebruiksvriendelijk werd. Ook is het niet een volledige herontwikkeling, RCS vind haar basis in MMS, dat ook al effectief via gestructureerde tekst werkte maar dan bizar lage beperkingen hadden zelfs in de tijd dat het populair was.

Communicatie tussen telefoon en provider gaat gewoon beveiligd (zelfs 2G was al versleuteld, al is die niet zo goed als TLS) dus HTTP tussen telefoon en provider-infra moet gewoon kunnen. TLS is een mooie toevoeging maar in feite zit je dan versleuteld verkeer te versleutelen, wat alleen maar compatibiliteitsissues kan geven en weinig toevoegt voor iets dat toch al decennia plaintext is en waarvan de E2EE-eigenschap door de chat-app wordt gehandhaafd.

Juist door het al te versleutelen binnen de app, zorgt ervoor dat andere processen (binnen het) besturingssysteem niet mee kunnen kijken.

En dat is dus ook precies wat er nu gebeurt, de Google Messages-app doet de versleuteling. Iedere ontwikkelaar voor alternatieve SMS-clients vinden dat maar niks, omdat de Messages-app geen openbare API aanbiedt. Dat was ook de hoofdreden die Signal gaf om geen SMS'jes meer te ondersteunen, omdat de antwoorden van RCS-capable-contacten niet in de Signal-app aankwamen maar SMS'jes wel (en dat is nogal vage user experience, natuurlijk).

Het mooiste zou natuurlijk zijn als je net zoals de SMS/MMS-API gewoon een RCS-API zou hebben die de telefoon veilig voor je beheert, zodat je alternatieve SMS-app niet de hele RCS-stack hoeft te implementeren, maar daar zijn we nog lang niet, lijkt het. Je OS kan toch al bij al je geheimen (desnoods patcht het de instructies van je messaging-app) en heeft ook al je SMS'jes en MMS'jes al in beheer. Dat zou ook meteen het probleem oplossen dat je krijgt als je van Google Messages overstapt naar een alternatieven messages-app, want dan kunnen de sleutels blijven zoals ze zijn en kun je direct bij al je chats.

[lenwar]

In Nederland zijn we het niet gewend maar in de VS is/was het heel gebruikelijk dat ISPs advertenties injecteren in http-streams/sms/mms. Goede kans dat ze dit ook bij RCS doen/proberen.

En dat is dus ook precies wat er nu gebeurt, de Google Messages-app doet de versleuteling. Iedere ontwikkelaar voor alternatieve SMS-clients vinden....

Ik doel dus op het protocol, niet de app die met het protocol gebruikt. Het is prima mogelijk om bijvoorbeeld het Signal-protocol cross-app te implementeren. (En er zijn ook andere bestaande protocollen)

[GertMenkel]

In Nederland zijn we het niet gewend maar in de VS is/was het heel gebruikelijk dat ISPs advertenties injecteren in http-streams/sms/mms. Goede kans dat ze dit ook bij RCS doen/proberen.

Ik weet dat providers meehelpen je SMS-spam te verkopen en dat ze hebben geklooid met HTTP in het verleden (al was dat volgens mij vooral voor tracking met een speciale Verizon-header en het injecteren van script dat laat zien dat je databundel bijna leeg is), maar ik heb nog niet gehoord dat ze daadwerkelijk midden in je SMS'je advertenties stoppen, eerlijk gezegd. Zelfs in Amerika is dat vreemd.

Ze kunnen het bij RCS proberen maar aangezien de software op de telefoon de versleuteling doet, kunnen ze er bar weinig mee. Alleen chats met iPhone-gebruikers erin vallen daar misschien ten prooi aan, maar als ze dat proberen te flikken zullen ze een hoop klanten kwijtraken.

De enige chatuitzondering voor E2EE zijn chatbots, die enorm capabel zijn met RCS. De standaard is nog lang niet volledige geïmplementeerd, maar chatbots kunnen alles van interactieve kaarten tonen to geld overmaken.

Ik doel dus op het protocol, niet de app die met het protocol gebruikt. Het is prima mogelijk om bijvoorbeeld het Signal-protocol cross-app te implementeren. (En er zijn ook andere bestaande protocollen)

Niet alleen is dat mogelijk, maar dat is een van de doelen van MLS (de envelop die RCS gebruikt voor versleuteling), al is de MIMI-RFC die dat mogelijk moet maken nog niet af.

Signal kun je echter niet zomaar implementeren. Signal kan niet samenwerken tussen verschillende servers, het werkt puur en alleen met de officiële Signal-server, of alleen met een server die je zelf hebt opgetuigd. Dat is een keuze geweest van Signal zelf om anonimiteit te bewaken (XMPP en Matrix, die E2EE federeren, en MLS, de aankomende standaard, laten zien in plaintext voor wie je bericht bestemd is zodat berichten gerouteerd kunnen worden).

Je loopt echter tegen het probleem aan dat RCS-servers wel gefedereerd zijn, maar alleen die van je eigen provider en die van Google zomaar via internet te bereiken zijn. Op berichtniveau kunnen Matrix/Jabber/etc. straks wellicht wel berichten uitwisselen met RCS-servers, maar op netwerkniveau zijn ze gescheiden. Hetzelfde geldt wel voor meer diensten, je kunt ook niet even contact leggen met de voicemailserver van Odido als je daar geen klant bent.

[theguyofdoom]

RCS gaat op termijn MLS gebruiken voor de crypto, dat scheelt al een stukje. Maar dat duurt nog wel even.

[GertMenkel]

RTT is een uitbreiding op de bestaande SIP+RTP+etc.-infrastructuurt die achter VoLTE en nieuwer schuil gaat. Effectief zijn deze berichten niets anders dan SIP- of RTP-pakketjes die als het goed is toch al gerouteerd zouden moeten worden (maar dat wellicht om veiligheids- of implementatieredenen nog niet deden).

RCS vereist opslagservers, netwerkconfiguratie en -authorisatie, speciale aftapinfrastructuur, en interoperabiliteitstesten aangezien het een volledig nieuw protocol is. Nu is de populairste RCS-server gewoon een server die je van Google huurt, maar ik kan me voorstellen dat voor de belangen van de nationale veiligheid door KPN wordt gekozen om lokaal wat te (laten) ontwikkelen dat aan de standaard voldoet.

Overigens heeft KPN al eerder RCS aangekondigd toen Vodafone het nog aanbood als "Message+" en T-Mobile Duitsland nog "Joyn" gebruikte. RCS is jaren geleden een stille dood gestorven omdat niemand het gebruikte en is pas recent weer in trek, maar ik verwacht niet dat providers zin hebben nog een keer nutteloze serverinfrastructuur op te gaan zetten.

[Oon]

Nu hebben we bijna feature parity met AIM 25 jaar geleden

Ik mis het nut hiervan een beetje, is een leuke gimmick maar helemaal tijdens het bellen heb je er toch weinig aan om realtime te zien wat de ander typt (of de ander te laten zien wat jij typt)?

edit:

toegevoegd dat mijn punt het stukje realtime was, niet het berichten sturen tijdens het typen

[Reactie gewijzigd door Oon op 2 juni 2025 14:07]

[AMDLegion]

Ordernummer of mail adres doorgeven aan klantenservice werkt beter als je het kan typen

[The Zep Man]

Of IBAN's. Die zijn best wel lang en klungelig.

[kamerplant]

Copy and paste? Dat ga je toch niet intypen 😳😃

[dutchgio]

Ja maar dat kan dan dus wel tijdens het telefoongesprek, dan hoef je het niet telefonisch door te geven

[GertMenkel]

Waarom plakken als je telefoon een hele duidelijke tekst-to-speech heeft

[Christoxz]

Wel als je deze telefonisch te horen krijgt, en dus moet intypen. (E.G. Telefonische bestelling etc)

[Elorad]

Maar dat kan toch ook gewoon als je op enter/send drukt? Het hoeft toch niet in realtime?

[moonlander]

Of gewoon het telefoon nummer waarmee je belt meteen koppelen aan je bestellingen in de backoffice van de callcentermedewerker??

[codeneos]

Ja, Nee. Privacy

En misschien belde je wel over de bestelling van je moeder, oma, buurvrouw. Of vader, opa, buurman.

[Reactie gewijzigd door codeneos op 2 juni 2025 15:19]

[moonlander]

Heeft niks met privacy te maken, hebben ze vast wel ergens in de voorwaarden staan. En als het om de bestelling van een ander gaat kun je dan de ordernummers wel doorgeven. Denk je nou echt dat een medewerker eerst gaat afwachten wat je gaat intypen terwijl je het zo kunt zeggen?

[Kriekel]

En dan gaat iemand aan de slag met je ordernummer dat 1 cijfer te kort is omdat je wat traag was met het laatste cijfer...

[AMDLegion]

Nee en voor dezelfde reden dat mensen niet direct aan de slag gaan als je 7 van de 8 cijfers hebt gespeld 1 voor 1 tijdens het bellen. Heel raar argument haha

[The Zep Man]

Ik mis het nut hiervan een beetje,

Uit het artikel:

Op termijn gaat de technologie ook werken bij contact met hulpdiensten, zegt KPN.

Voldoende situaties te bedenken dat dit nuttig kan zijn. Denk aan situaties waarin iemand wel kan luisteren maar niet kan spreken.

[Oon]

(CC @AMDLegion @Robbaman)
Mijn punt was vooral dat er weinig nut is voor het realtime gedeelte tijdens bellen. Dat je een berichtje kan sturen tijdens het bellen is prima, daar zijn wel usecases voor te bedenken, maar dat de ander het ziet terwijl je typt heeft geen enkele toegevoegde waarde t.o.v. gewoon een berichtje sturen. De enige situatie die denkbaar is waar het nut heeft is als je niet op Verzenden kunt drukken, maar dan kun je ook niet dit knopje in het menu vinden en activeren..

[The Zep Man]

Het nut van realtime voor hulpdiensten kan ik begrijpen. Als iemand maar een deel van een bericht intikt en niet op verzenden tikt dan mist de persoon aan de andere kant van de lijn die boodschap. Ook zegt de manier van schrijven veel over de gemoedstoestand van de andere partij, wat ook belangrijk is als elke seconde telt.

[Reactie gewijzigd door The Zep Man op 2 juni 2025 15:59]

[Daoka]

Ook zegt de manier van schrijven veel over de gemoedstoestand van de andere partij,

Ik vind dat weleen gevaarlijke aanname. Ik ben niet snel met typen, vooral niet op een telefoon en ik maak veel fouten. Of ik verander vaak wat ik zeg. Ook andere mensen in mijn omgeving zijn niet snel. Een ander is snel met typen. Wie is meer in de stress? Natuurlijk zal ik tijdens een noodgeval minder mijn fouten verbeteren of herschrijven maar dat hoeft niet te betekenen dat ik meer stress of nood heb dan een ander.

[Finraziel]

Voor mensen die handig zijn met typen ben ik het met je eens... Maar als iemand met een snelheid van 1 karakter per 5 seconden een lang ordernummer aan het typen is terwijl je het klantnummer nodig hebt dan kan het wel handig zijn om dat al te zien en ze sneller te kunnen corrigeren...
Maar ja mijn eerste gedachte was ook dat dit in de meeste gevallen niet zo heel nuttig is. Vooral voor noodsituaties kan het wel handig zijn maar de support daarvoor moet dus nog komen.
Zelf deed het me vooral denken aan als ik iemand zie typen in een chat met mij terwijl ze hun scherm met mij gedeeld hebben, dan kun je flauw gaan zitten doen door antwoord te geven voor ze uitgetypt zijn

[AMDLegion]

Maar hoe stuur je dan een berichtje aan de klantenservice tijdens het bellen?

SMS kan niet, dus dan zou je gaan mailen? Wat heel omslachtig is omdat niet elk bedrijf een makkelijk toegankelijke inbox heeft.

Sommige bedrijven werken alleen maar met bellen en niet met mail.

[Oon]

Je mist nog steeds mijn punt. Dat het handig kan zijn om een bericht aan de klantenservice of nooddiensten of een andere gesprekspartner te sturen snap ik, daar zijn usecases voor te bedenken. Maar dat de ander realtime moet zien wat jij typt terwijl je het aan het typen bent is iets heel anders.

Het zal ook nog héél wat jaren duren voordat een willekeurige klantenservice dit gaat ondersteunen, vooralsnog is het alleen KPN, en de dialer app van je telefoon moet het ondersteunen. Zelfs als het dadelijk verplicht is voor providers om dit te ondersteunen gaat het nog wel even duren voordat de flink verouderde software waar menig callcenter op draait hier iets mee kan.

[AMDLegion]

Omdat bellen ook realtime is, in realtime iemand zien typen versneld het klantenservice proces.

Je kan het zien als een naam spellen 1 voor 1 letter, maar ipv vocaal word dit nu getypt.

[aikebah]

Wat het klantenserviceproces pas echt zou versnellen is het plaatsen van experts achter de telefoon ipv typistes die verplicht een script moeten afwerken en de antwoorden daarvan doorzetten naar een specialist op de achtergrond, ook als al duidelijk is dat er gewoon een probleem aangemeld moet worden. Zonder script-antwoorden kan er geen ticket aangemaakt worden... wie heeft die waanzin bedacht.

[AMDLegion]

Dit is een oer oude kwestie.

Al je producten worden duurder als je zulke klantenservice wilt. Je gaat dan namelijk een heel ander slag mensen moet recruiten voor je helpdesk.

Veel ( grote ) webshops werken op dit moment met absolute entry level personeel die je niet los wilt laten van een script, want dan gaat t gewoon mis.

Ben het wel met je eens dat dit soort klantenservices horror zijn om mee te werken maar het is niet zo makkelijk op te lossen als je zou denken.

[B64]

Maar moet je dat soort klantenservicepersoneel dan wel vertrouwen met een real-time chatsysteem?

Overigens moet ik nog maar zien of producten écht duurder worden hoor. Vaak zie je dat veel problemen nu naar een tweedelijns afdeling worden doorgestuurd omdat klanten niet tevreden zijn met het antwoord van de eerstelijns, klanten van kastje naar muurtje worden doorverbonden, onjuiste informatie te horen krijgen, en/of van ellende nooit meer bij het betreffende bedrijf kopen. Een goede eerstelijns klantenservice kan heel veel waarde leveren voor een bedrijf.

[Finraziel]

Daarbuiten, zelfs als je wél goed genoeg betaalt... mensen van het kaliber wat je daar zou willen hebben zitten gaan meestal niet lang tevreden blijven met zo'n baan. De meeste mensen die zo slim zijn zullen ook door willen groeien en interessantere dingen gaan doen dan een oud omaatje uitleggen hoe ze haar printerdriver moet installeren of weet ik wat.

[Daoka]

Het probleem is dat veel mensen die de kennis hebben geen zin hebben om de hele dag achter de telefoon te zitten. Of geen zin hebben om vaak dezelfde basis vragen en antwoorden te moeten herhalen. Heeft u al geprobeerd de ... uit en aan te zetten?

Daarnaast hebben expert mensen meestal een hogere salaris. Wordt een dure grap om 20 expert mensen te betalen om je modem te laten resetten. Of je opnieuw te verbinden met wifi. Of de stappenplan doorlopen van email instellen.

[lenwar]

Bekijk het is vanuit de ontvangende kant:

Wat ik me kan bedenken is voor mensen met dyslexie of zo? Allicht is het makkelijker voor die mensen om een tekst te lezen terwijl die getypt wordt? (ik heb er geen ervaring mee, dus misschien is het onzin).

Of mogelijk dat dit de interactiviteit met slechthorenden kan vergoten? Stel dat je een hele epos wil schrijven, en dat de ontvanger al na 3 woorden ziet dat het de verkeerde kant op gaat, dan kan die alvast ingrijpen.

In de wetgeving zijn ook voorbeelden van automatische transcriptie (dus dat je mee kunt lezen met hetgeen dat wordt uitgesproken), maar dat is weer wat anders dan het letter voor letter mee kunnen lezen.


Zoals in het artikel staat is dit primair bedoelt voor als toegankelijkheidsoptie. Dus misschien heeft iemand die hier persoonlijk ervaring mee heeft een goed voorbeeld van?

[ZwolschBalletje]

De enige echte usecase die ik zie (lees: verschil met een normale chat) is dat je dus een bericht kunt typen en weer wissen nadat de ander het gelezen heeft. Zeg maar de klassieke spionageroman waarin iemand in een benarde situatie contact wil opnemen met ondersteuning zonder dat de slechterik dat na afloop de hele chatgeschiedenis kan zien.

Er zal vast nog meer aan vast zitten: misschien wil KPN wel heel graag zien dat je bepaalde info uit het hoofd intypt in plaats van copyright-paste, of om te zien of er een chatbot op monotoon tempo aan het typen is of een werkelijke klant. Maar de unieke business case waarmee je deze ontwikkeling (als KPN) terugverdient, die zie ik nog even niet.

[TheMak]

Als je berichten verstuurt verslapt de aandacht van de ander. Zojuist vroeg iemand mij of de shirt mij past. Niet op geantwoord. Misschien staat die nu met jas aan te wachten op mijn antwoord. Maar ik vind tweakers belangrijker.

[Robbaman]

Er staat in het artikel:

De provider noemt het vooral een functie om de toegankelijkheid te verbeteren "Het biedt een oplossing voor mensen met spraak- of gehoorproblemen."

Dat lijkt me een duidelijk nut van deze feature toch?

[lenwar]

In het artikel wordt benoemd dat het voornamelijk bedoelt is voor mensen een spraak/gehoorprobleem. Ik kan me er iets bij bedenken dat als je bijvoorbeeld moeite hebt met spreken/horen dat het dan handig kan zijn om tussentijds wat losse woorden te kunnen typen. Of dat dan letter voor letter moet weet ik niet.

Misschien dat iemand met een dergelijke beperking (of daar heel nauw bij betrokken is,) er iets zinnigs over kan zeggen?

[Dark Angel 58]

Het is wel nuttig, als ze meelezen en proberen jou te begrijpen en ook volgen wat je probeert te zeggen als ze het door hebben dan nemen ze het over zonder dat je rest van je tekst hoeft typen.

[GeeBee]

Dat was mijn eerste gedachte ook: dat hadden we vroegâh bij MSN/ICQ toch ook?

[vrow]

ICQ wel, MSN niet.

Bij beide werden de berichtjes pas verzonden als je op 'verzenden' drukte, maar ICQ had nog een aparte chat-functie waarbij het scherm in 2en werd gedeeld (boven jij, onder de ander) en alles wel letter-voor-letter werd overgestuurd.

[Transferno]

Ik denk vooral voor hulpdiensten. Ze zien wat je typed ook al ben je niet in staat je bericht af te maken. Handig voor velen om stiekem info door te geven, en zeker voor doven.

[GurbieV]

Gaat dit dan over sms'jes?

WhatsApp had dit al lang kunnen ondersteunen als ze dat gewild hadden. Dit gaat dan over een andere app die je moet downloaden ofzo?

Meer vragen dan antwoorden na het lezen van dit artikel...

[dutchgio]

Nee, want bij SMS is dat niet real-time te zien.
RTT staat voor "Real-Time Text", een technologie die tekstberichten direct stuurt terwijl ze worden getypt, zonder een verzendknop te gebruiken
Gewoon in de telefoon app, tijdens een belgesprek. Dat zie je ook op de screenshots.

[GertMenkel]

(Video)bellen over 4G/5G gaat over SIP+RTP+wat omliggende protocollen. Die zitten dan weer in 3GPP/ETSI/ITU/etc. protocollen verwerkt die vrije velden van standaardprotocollen bepaalde waardes geven en bepaalde structuren toevoegen, zoals verplichte codecondersteuning en bepaalde berichtafhandeling.

Volgens dit document lijkt het erop dat de simpelste implementatie gewoon via SIP+RTP gaat werken. Eerdere protocollen wilden nog wel eens SIP INFO-berichten gebruiken, maar de simpelste implementatie hiervan lijkt een RTP-kanaal met tekstpayload te gebruiken (RFC 9071). Voor Europa wordt in dat document verwezen naar ETSI TS 101 470 waarin vooral over SIP wordt gesproken volgens ETSI TS 103 479 dat vooral SIP MESSAGE's lijkt te gebruiken (6.6.2.4 noemt specifiek RFC5194 + RFC 3103 + RFC 9071).

Het doel van het protocol is om te zorgen dat doven contact kunnen krijgen met nooddiensten, maar in theorie is er niks dat voorkomt dat je telefoon de optie tijdens een normaal gesprek aanzet. Mits de SIP-server+RTP-infra van je provider niet al te vervelend is, zou dit eigenlijk out of the box al moeten werken (maar telecomproviders hebben nogal wat custom implementaties nodig om dingen als billing, roaming en aftappen te kunnen doen op een gestandaardiseerde manier dus vaak vereist dit extra werk).

[GurbieV]

Dankjewel voor de uitleg. Dit scheelt al een stuk.

Dit kan dan waarschijnlijk via de telefoon app. En dus alleen berichten sturen naar degene met wie je belt op het moment dat je aan het bellen bent.

Kennelijk is dit dus een verplichting vanaf binnenkort en is kon de eerste die dit gaat ondersteunen in combinatie met Samsung.

[FrostyPeet]

Het zal zeker nut hebben voor bepaalde doelgroepen, of specifieke situaties. Denk dat deze optie wel erg laat komt. Bellen is, behalve voor de gezondheidszorg, sterk afgenomen. De meesten gebruiken Whatsapp, of werken alles af via een webportal of e-mail.

Wel benieuwd wanneer RCS zal worden uitgerold.

[FvGa]

Fantastisch kan iedereen zien dat je geen een woord zonder auto correct juist kan typen...

[Martymarty]

Ff wachten tot we de WA stickers er kunnen gebruiken, dan heb je geen woorden meer nodig

[Cid Highwind]

Voor Apple gebruikers is het wel handig. Daar kan de oplettende meelezer tenminste zien wat er oorspronkelijk getypt was voordat de telefoon het "corrigeert" naar iets waar geen kaas van te maken valt.

[DjoeC]

Is dit niet een beetje de provider versie van Whatsapp? Ik meen ooit (paar jaar geleden) eens een artikel tegengekomen te zijn dat voor US telecom providers balen van het verlies van SMS inkomsten en dat ze daar een alternatief voor zochten. Is dit dan dat alternatief?

Hmm, nu ik even goegel zie ik dat het om (o.a.) Europeese regelgeving zou gaan. Best wel vreemd met alles dat we al beschikbaar hebben. Weer een kanaal erbij.

[GertMenkel]

Nee, dat is RCS (danwel iMessage), in Nederland bekend onder namen als Joyn/Message+ toen het vijftien jaar geleden geïntroduceerd werd en vijf jaar geleden allemaal afgesloten is. Omdat het een optioneel onderdeel was van de spec had geen enkele telefoon een standaardclient voor het protocol (wat ze wel voor SMS hadden) en moest je dus apps gaan downloaden van je provider om het te gebruiken, wat het snel omgelegd heeft in Nederland.

In Amerika/India is RCS wat groter geworden omdat iedereen daar MMS/SMS gebruikte in combinatie met iMessage, en dus de standaard-berichtenapp de plaats innam van WhatsApp hier. Ook daar had eigenlijk niemand competente RCS, maar toen Google zelf een server opzette (onder andere omdat ze voor Google Fi toch zo'n server nodig hadden) hebben ze die beschikbaar gemaakt aan iedereen, en daarom kun je nu op Android ook in Nederland, waar geen enkele provider nog RCS aanbiedt, van RCS gebruik maken. Helemaal gratis, op kosten van Google, puur omdat Google graag moderne interactie met iMessage in landen als Amerika mogelijk wil maken.

Het chatprotocol waar dit over gaat is in feite niet meer dan metadata die tijdens een gesprek wordt uitgewisseld tussen telefoons en tussenliggende servers. Dit werkt dus alleen op het moment dat er een oproep geplaatst wordt (al is er niks dat verplicht dat een "oproep" via SIP+RTP beeld of geluid stuurt, je kunt ook een "oproep" starten met alleen een tekstkanaal volgens de SIP-spec). Het is dus geen vervanger van WhatsApp.

Sowieso kun je er van uit gaan dat de verbinding volledig onversleuteld is omdat dit soort dingen van de wet afgetapt moeten kunnen worden, dus tenzij je een gemodificeerde dialer gebruikt die dit soort dingen versleutelt verstuurt, is het niet bepaald een vervanger voor WhatsApp.

[The_Doman]

Leuk weer, maar mooi zou ook (weer) een directe WebChat mogelijkheid zijn zonder de noodzaak om daarvoor daarvoor een social media app/account te moeten gebruiken.

KPN community: Hoe kan ik chatten met een KPN medewerker?

[IrBaboon79]

Klinkt...onpraktisch? - typen op een telefoon is al vrij ruk en regelmatig zit de spellingscontrole ertussen die je dan weer 4x mag corrigeren omdat je toch iets anders bedoelde... of je kan de helpdesk irriteren door tikfouten te maken of nogal onbeleefde woorden in te tikken en te 'corrigeren'...

[jongetje]

Als ze echt gaan handhaven dat elke provider dit einde van deze maand actief moet hebben gaan we nogal wat boetes vallen. Denk aan een 50+ mobiel waarbij telefoongesprekken zelfs nog alleen maar over 2G gaan.