Lijbrandt telefoon menu's

[MCP cloud]

Dit topic is bedoeld om alle Lijbrandt telefoon menu klachten m.b.t. de glasvezeldiensten van Lijbrandt te bundelen.

Graag hier vermelden welke telefoon toestellen WEL en NIET werken met de menu's
Menu > 4500 meerdere cijfers

Werkende telefoon toestellen:
Siemens Gigaset C450
Siemens Gigaset SL400
Panasonic KX-TCA121ex
Topcom Butler E2100

NIET werkende telefoon toestellen:
Siemens Gigaset AL180 Duo
Panasonic KX-TCD220(NL)
NRX EVO 450
KPN Arizona 910
Motorola D1014.



Lijbrandt quote:

Lijbrandt_Desk schreef op donderdag 29 december 2011 @ 11:27:
Er zijn een flink aantal verschillende types telefoontoestellen in omloop die ook op een "eigen" manier omgaan met de telefonische doorkies menu's. Op dit goed te laten werken op alle toestellen moet er een generieke oplossing worden gevonden en daar zit op dit moment het probleem: fixen we dit voor toestel type A dan gaat het fout op toestel type B, fixen we het daarna voor toestel type B dan doet type X het niet meer. Lijbrandt beseft dat het erg lastig is voor onze klanten en er wordt ook samen met onze leverancier druk gezocht naar een permanente oplossing. - Ruben

Lijbrandt_Desk schreef op donderdag 29 december 2011 @ 12:29:
Ik heb contact gehad met het Special Services Team wat binnen Lijbrandt bezig is met o.a. dit probleem, er is op een mogelijke fix ontwikkeld die in de loop van januari 2012 zal worden uitgerold. Ik heb gevraagd of een lijst zoals hierboven aangegeven handig is; indien de fix van januari niet het gewenste resultaat heeft dan ontvangen mijn collega's deze lijst graag via Webcare. - Ruben

[ Voor 12% gewijzigd door MCP cloud op 16-02-2012 13:01 ]

[Anoniem: 438147]

Ik heb op dit moment Motorola D1014.
Daarmee kan ik sommige menu's niet bedienen.

[DJSmiley]

Ik ben erg benieuwd of dit daadwerkelijk aan de toestellen ligt. Persoonlijk denk ik van niet ( DJSmiley in "Lijbrandt: vragen en klachten" )

Als er een aantal proefpersonen zijn ben ik heel benieuwd wat er gebeurd als een (gerapporteerd) werkend toestel aangesloten wordt bij iemand die problemen heeft en of het dan nog steeds werkt.

Ik denk nl dat model/type/revisie/firmware CPE het issue veroorzaakt en niet het (analoge) toestel wat eropaangesloten zit.

[.NCK]

Hier ook een variant gigaset c450 IP basis in gebruik met diverse typen handsets.
I.c.m. een genexis cpe.

Tot noch toe geen problemen. Komen jullie wel door het keuzemenu (en postcodecheck) van de support desk van Lijbrandt heen?

[Anoniem: 438147]

.NCK schreef op donderdag 29 december 2011 @ 22:32:

Tot noch toe geen problemen. Komen jullie wel door het keuzemenu (en postcodecheck) van de support desk van Lijbrandt heen?

Dat wel.
Bij mij ligt het probleem voornamelijk bij het gebruik van goedkopere telefonie aanbieders (Belpiraat bijvoorbeeld). Daar moet ik naar een optie in het keuzemenu een telefoon nummer intoetsen.

[MikeT80]

Ik gebruik hier (Houten):

Siemens Gigaset SL400
Nog nooit problemen gehad met de menu's

[diver99]

werk met 2 verschillende sets van Panasonic w.o de KX-TCA121ex en heb totaal geen problemen met welk keuzesysteem dan ook. Lijbrandt werkt goed, bellen via goedkope telefoondiensten of andere menu's werkt prima

[Willem2]

Heb een Topcom Butler E2100 (eco telefoon :-) ), werkt prima

[Anoniem: 438894]

Onze menu-ervaring vandaag met twee antieke telefoons : T88 NLNR (21-0210) en Malmö 4 (21-1190).

Test toetsen 1,2,.....9,0.

T88 : toetsen 1, 6 en 7 worden niet gedetecteerd,
keer daarna : 2,3,4,7 en 9 niet.

Malmö 4 : toetsen 4 en 7 niet ,
keer daarna : 6,7 en 9 niet.

Detectieprobleem treedt zowel op met beide toestellen parallel als individueel (aansluitwaarde T88 = 1,5, Malmö = 1).
Locatie : Enschede.

Trieste constatering.

[Anoniem: 376876]

Alvorens je een vinger kan wijzen naar je provider in casu de Noorse partner die VoIP aanlevert, moet je wel even duidelijk zijn te krijgen waar het probleem nu ligt, want er zijn minimaal drie partijen in deze verbinding die op de een of andere manier problemen kunnen hebben.

1. Jij als bellende partij en jouw telefoontoestel
2. Lijbrandt (in casu de VoIP leverancier)
3. De telefooncomputer waarmee je tracht te communiceren.

Voordat je dus voor 100% de vinger naar partij 2 kan wijzen dien je eerst te verifieren of je vanaf een andere verbinding wel met je eigen toestel, of een ander toestel door zo'n menu heenkomt.

Als ik dan de test van Bliksemflits eens kritisch lees dan lijkt het erop dat er tussen toestellen nogal wat verschillen zitten, en wat hij helaas niet schrijft maar wellicht wel weet is of dezelfde toestellen op de oude koperverbinding van KPN wel goed deden in de test?
Ook de modems die sommige computermenudozen hebben zijn vaak van abominabele kwaliteit, waarmee ik alleen maar wil zeggen dat er meerdere oorzaken kunnen zijn voor het probleem, die niet per saldo altijd voor rekening van de provider zijn.

Als gezegd heb ik hier inmiddels met een Philips en een Siemens DECT setje door de nodige menu's heengefietst zonder problemen (niet als test, maar als je een zoon in het buitenland hebt zitten die om medische redenen dient te worden gerepatrieerd dan heb je alle verzekeraars en hulpdienstcomputerdozen al aan de lijn gehad )

[ Voor 8% gewijzigd door Anoniem: 376876 op 05-01-2012 00:33 ]

[Anoniem: 438894]

spikecity,
Neem me niet kwalijk, maar uit mijn test leid ik af dat het niet-detecteren tekenonafhankelijk is.
Het verschilt van keer tot keer welke tekens gemist worden.
In zoverre gedragen beide toestellen zich hetzelfde.
Via het koper/KPN werken ze vlekkeloos.

[DJSmiley]

Anoniem: 438894 schreef op vrijdag 06 januari 2012 @ 19:24:
spikecity,
Neem me niet kwalijk, maar uit mijn test leid ik af dat het niet-detecteren tekenonafhankelijk is.
Het verschilt van keer tot keer welke tekens gemist worden.
In zoverre gedragen beide toestellen zich hetzelfde.
Via het koper/KPN werken ze vlekkeloos.

Alle symtonen lijken erop dat DTMF in (sommige?) gevallen inband verstuurd worden, dus IN de audiostream, en dus zwaar afhankelijk zijn van de gebruikte codec, waardoor er geen goede werking te garanderen is.

Of dat nu icm een specifieke CPE is.. geen idee. Het DTMF volume van het betreffende toestel kan hier enige invloed op hebben, waardoor het soms betrouwbaarder kan werken, maar in de basis is de ATA in de CPE hier schuldig aan.

Ik ben erg benieuwd of iemand een wireshark capture kan maken van een gesprek. Dan zie je snel genoeg of dat idd het issue, een betrouwbaar DTMF transport gebeurt meestal out-band (RFC2833) en dat zie je dan netjes in een wireshark trace.

Inband DTMF icm G711 gaat op zich redelijk, maar voor een betrouwbaar DTMF transport is out-hand RFC2833 in mijn ervaring een stuk betrouwbaarder.Bij G729 zelfs een must.. Die codec comprimeerd nog meer waardoor er niets herkenbaars meer overblijft van een DTMF toon.

[ Voor 11% gewijzigd door DJSmiley op 06-01-2012 20:19 ]

[Anoniem: 376876]

Anoniem: 438894 schreef op vrijdag 06 januari 2012 @ 19:24:
spikecity,
Neem me niet kwalijk, maar uit mijn test leid ik af dat het niet-detecteren tekenonafhankelijk is.
Het verschilt van keer tot keer welke tekens gemist worden.
In zoverre gedragen beide toestellen zich hetzelfde.
Via het koper/KPN werken ze vlekkeloos.

Dat ze via koper goed werken is uiteraard goed, want dat zou de manier waarop DTFM tonen worden verzonden vanuit beide toestellen goed werkt en het probleem verderop ligt.
Misschien dat ik mezelf wat ongelukkig uit heb gedrukt in mijn analyse, maar ik bedoel eigenlijk te zeggen dat het vreemd is dat twee verschillende toestellen op dezelfde lijn niet dezelfde cijfers "missen" maar het random lijkt, want als het bijv aan flitering of interferentie ligt zou je verwachten dat beide toestellen dezelfde cijfers consequent niet zouden kunnen versturen.
Het lijkt er dus op dat er ergens tussen jouw toestellen en de ontvangende menucomputer iets verloren gaat of verminkt wordt.

Vreemd blijft dan wel dat ik via een Lijbrandt telefonieverbinding met twee verschillende merken DECT toestellen gewoon zonder problemen die menu's kan doorfietsen, wat weer zou kunnen aangeven dat het geen generiek probleem is maar meer specifiek op het deel waarvan jouw verbinding gebruik maakt.

Leuke uitdaging voor de Noren dus

[Anoniem: 438894]

Als ik met het Malmö toestel via de lijbrandt glasvezel naar mijn oude isdn toestel via de Cu-lijn bel en dan daarna op de Malmö menutoetsen druk, hoor ik aan de ISDN kant het volgende.
Per rij toetsen hoor ik dan steeds dezelfde toonhoogte.
Om preciezer te zijn : noem voor toetsen 1, 2 en 3 de toonhoogte A, dan hoor ik voor
4, 5 en 6 hoogte B
7, 8 en 9 hoogte C
*, 0 en # hoogte D.
Daarbij gaat het van A naar D steeds een stapje hoger.
Ik hoor dus absoluut geen verschil tussen de toetsen in één rij.
Wat ook opvalt is dat de tijdsduur van iedere toon onafhankelijk is van hoe lang ik op de toets druk, naar schatting slechts enkele tienden van een seconde.

[Anoniem: 376876]

Anoniem: 438894 schreef op zondag 08 januari 2012 @ 14:44:
Als ik met het Malmö toestel via de lijbrandt glasvezel naar mijn oude isdn toestel via de Cu-lijn bel en dan daarna op de Malmö menutoetsen druk, hoor ik aan de ISDN kant het volgende.
Per rij toetsen hoor ik dan steeds dezelfde toonhoogte.
Om preciezer te zijn : noem voor toetsen 1, 2 en 3 de toonhoogte A, dan hoor ik voor
4, 5 en 6 hoogte B
7, 8 en 9 hoogte C
*, 0 en # hoogte D.
Daarbij gaat het van A naar D steeds een stapje hoger.
Ik hoor dus absoluut geen verschil tussen de toetsen in één rij.
Wat ook opvalt is dat de tijdsduur van iedere toon onafhankelijk is van hoe lang ik op de toets druk, naar schatting slechts enkele tienden van een seconde.

Als ik me mijn telecomlessen goed herinner dan zijn DTFM tonen steeds twee tonen per toets die door elkaar klinken.
Volgens mij is dat één toon per rij en één per kolom op het toetsenbord, dus kan het kloppen dat je per rij de meest dominante toon hoort, en per rij een toon die steeds hoger wordt...
Pfff... ben een beetje roestig op dat gebied geworden vrees ik.

Wikipedia: DTMF

[telocho]

De situatie is anders. Ligt volgens mij niet aan CPE en thuis-toestel.

Ten eerste gebruikt de Lijbrandt CPE geen SIP, dat is te complex voor zo'n poortje. Dit is gewoon Megaco of MGCP of zo. Dus de communicatie is daarmee inderdaad inband.

Dan kom je signaal uit op een media gateway. Deze, normaliter, heeft een dtmf decoder en herkent je dtmf inband, voor verdere verwerking.

Afhankelijk of je nu uitrouteert naar norrmaal vastnet (via oude E1 verbindingen en C7 signalling, zal wel niet want te duur) wordt de DTMF weer her-gegenereerd.
Routeren ze uit naar een ip-voip wholesale provider, wordt je dtmf opnieuw inband gegenereerd door de media gateway, of wordt je out-of-band doorgegeven. Alles is mogelijk. Pas dan kom je na lang zwerven op de uiteindelijke aansluiting. Dat is dan wel via flinke omleidingen.

Door al die onzichtbare voip routeringen heb je natuurlijk wel last van jitter en delay.
Wat Lijbrandt doet of kan doen, is per bestemming klagen bij hun wholesale provider en die routeren dan om naar een hogere kwaliteit dienstverlener.

Het ligt per definitie niet aan eindtoestellen, die hebben een keurmerk en er is ook zoiets als marge in de normering. De telefoniedienst hoort gewoon redelijk robuust te zijn tegen wat klanten er op gooien.

[Anoniem: 376876]

Zo dan telocho... ik was je na twee alinea's al een beetje kwijt, wat een technische uitleg zeg

Maar even heel kort door de bocht is DTFM toch gewoon twee-tonig audio wat via dezelfde spraakband (was dat niet 300 tot 3400 Hz?) wordt verstuurd (in het geval van VoIP uiteraard gedigitaliseerd audio)?
Het lijkt mij (maar ik geef toe dat ik er al eeuwen uit ben) dat indien je een werkende audioverbinding (via VoIP) met de ontvanger hebt je dus zowel spraak als DTFM tonen gewoon aan de ontvangstzijde moet kunnen opvangen en decoderen.
Hooguit dat de digitalisering of de echo- en ruisonderdrukking die toontjes vernachelt waardoor ze niet goed genoeg meer aankomen?

Ik kan mij van jaren geleden nog herinneren dat ik problemen had met een 56K6 modem en dat achteraf bleek dat KPN ruisfilters over de aansluitingen had zitten waardoor een deel van de modulatie niet doorkwam.
Fysiek het filter verwijderen was toen de oplossing, maar ok, dat was nog wel in het goeie ouwe kopertijdperk.

[ Voor 19% gewijzigd door Anoniem: 376876 op 09-01-2012 14:48 ]

[telocho]

Kort door de bocht: analoge telefonie heeft de volgende filters: laagfliter op 300 Hz en hoog filter op 3400 Hz. DTMF is moduleren op 2 frequenties die in dat gebied liggen (4 hoge en 4 lage, waarvan dus 2 tegelijk, geeft 16 mogelijkheden.) Er zijn er 12 van de 16 nodig voor 0-9 en * en #, en er blijven dus 4 ongebruikt of voor speciale toepassingen.

Meestal gaat het mis door codec, dit is het digitaliseren bij voip. Die tonen zijn exactie frequenties opgewekt met een kristal. Een codec, met name die gericht op zo min mogelijk bits per seconde, hebben een algoritme die frequenties snijdt net als een kamfilter (en mp3 ook). Dat gaat met kwaliteitsverlies, ohoorbaar voor het menselijk oor, maar computers en dtmf kunnen er niet tegen.

Er is ook een codec die heet g.711, dat is in feite de ISDN B-kanaal, die is gewoon lineair PCM gecodeerd 8 bits samples, 64 kbit per seconde. Die kan DTMF storingsvrij overdragen (als de jitter beperkt blijft. Alle andere codecs hebben voorzieningen nodig.

Mijn vermoeden is dat de CPE Genexis gewoon G.711 is, zou niet weten waarom niet. Dat is hardware matig het goedkoopst, en dat telt het meest bij afname van +1000 stuks.

[DJSmiley]

telocho schreef op maandag 09 januari 2012 @ 13:58:
De situatie is anders. Ligt volgens mij niet aan CPE en thuis-toestel.

Ten eerste gebruikt de Lijbrandt CPE geen SIP, dat is te complex voor zo'n poortje. Dit is gewoon Megaco of MGCP of zo. Dus de communicatie is daarmee inderdaad inband.

Ik weet niet wat voor CPE's het dan zijn, maar afaik doen de Genexis dingen gewoon SIP.
(Zie hun datasheets,bv http://www.genexis.eu/downloads/datasheet-ocg-118m.pdf )

Ik zie hier niets over andere protocollen staan. Vandaar dat mijn vermoeden is dat de afhandeling van DTMF binnen de RTP stream gaat (inband dus) en onderhevig is aan compressie/gebruikte codecs, itt RFC2833 signalling.

Maar het is gissen, omdat we natuurlijk niet de werkelijke manier van implementatie weten. En dat zou af te vangen zijn door te wiresharken aan de fiber-kant, maar ik heb geen idee of je daar als 'user' bij mag/kan, en je moet ook maar net de betreffende hardware hebben liggen

Ondanks dat G7.11 idd DTMF zou moeten kunnen transporteren is mijn ervaring hier toch mee dat dit niet echt superstabiel werkt. Ik heb hetzelfde issue gehad icm Arris Docsis modems, daar was het implementeren van RFC2833 de oplossing. Je ziet dan de DTMF toetsen ook netjes doorkomen in een wireshark.

Voor andere codecs zie ik ook geen nut, G.729 heeft licentiekosten, en bandbreedteissues lijken me ook niet echt relevant op glas

[ Voor 16% gewijzigd door DJSmiley op 09-01-2012 15:11 ]

[Anoniem: 376876]

Voice ports Genexis:

• 2 RJ-11 connectors
• 2 separate phone lines
• SIP-based
• 5 REN support
• G.711 A-law and μ-law codec
• G.729 codec (optional)
• DTMF signalling in-band / RFC 2833 / SIP-info
• Line Echo Cancellation (LEC)
• Adaptive jitter buffer
• Packet Loss Concealment
• Caller ID support (DTMF / FSK)
• Support for CLIR
• Class 5 services:
- Call forward unconditional
- Call forward on busy
- Call forward on no answer
- Call hold / release
- Call waiting
• Modem / fax support
• Automatic provisioning via APS

[telocho]

Als het SIP is, wil ik het wachtwoord, voor in mijn Fritzbox... steekwoord: meerder lijnen, tegelijk in-en uit bellen, en mijn Fritzbox is wel erg goed in DTMF herkenning: RFC2833/ of SIP info out-of-band/wat dan ook.

Als referentie: Kabelaars UPC/Ziggo doen geen SIP op het docsis modem. De Megaco RTP stream is verder gewoon hetzelfde als bij SIP, het protocol is alleen vele malen simpeler (commando's als haak-van-de-hoorn, kanaal open, opgelegd, etc) Niets met invite/registrar en zo.

PS2. Bij inband DTMF kun je denken aan echte inband (dus DTMF ongecodeerd in de audiostream), RFC2833 is DTMF via aparte RTP pakketjes (waarbij je de detectie dus in de Genexis ata doet en de RTP stream onderbreekt en die DTMF pakketjes er apart tussen zet met een andere payload header). Net zoals de RTP pakketjes voor je comfort noise.
Als RFC2833 wordt gebruikt, dan is de firmware/hardware implementatie op de CPE eerste verdachte?
Ik had toen ik de eerste Fritzbox kocht jaren geleden ook nog wel eens dubbele digits of gemiste digits bij de herkenning en zo. Dat kregen ze na verloop van tijd wel onder de knie.
RFC2833 betekent wel dat je een soort mid-call-trigger in het voicekanaal moet hebben. En mensen zetten er, omdat het maar 1 poortje is, vast telefoonsplitters tussen en zo.

[Politoer]

Ik maak gebruik van 2 Panasonic KX-TCD220(NL) DECT telefoons met antwoord apparaat (functioneren beiden als basisstation, waarbij de 4 telefoons automatisch verbinding leggen met het meest dichtbijzijnde basisstation) en 2 losse handsets van Panasonic model KX-TCA122EX. Deze 4 toestellen zijn allemaal op de twee basisstations aangemeld.

Zolang ik deze via een ISDN-centrale (Hormann) gebruikte werkte het intoetsen van menukeuzes zonder problemen.
Sinds ik via Lijbrandt bel (halverwege dec. 2011) werkt dit niet meer. Althans ik heb nu enkele malen naar een organisatie gebeld waarbij je een spraakcomputer aan de lijn krijgt en je vervolgens keuzes uit een menu moet maken en de keuze intoetsen (al dan niet te bevestigen door op # te drukken).

Bij nader inzien is het probleem gedifferentieerder. De 4 handsets hebben als model typenr. : KX-TCA122EX.
Gisteren bleek een een daarvan wel in staat een spraakgestuurde computer te kunnen bedienen met de menukeuzes, terwijl dat met een andere handset dat niet lukte. Dit bleek reproduceerbaar bij 2 verschillende organisaties waarmee ik gebeld heb om uit te testen.Het toestel dat altijd in een basisstation staat leverde geen problemen op bij de menukeuzes, terwijl het toestel dat alleen in een laadstation staat dat wel vertoond. Nogmaals beide toestellen hebben exact hetzelfde modelnr.
Uiterst merkwaardig dus.

Vandaag ontdekte ik dit forumtopic en moet ik constateren dat Lijbrandt kennelijk in het duister tast over de oorzaken en een oplossing nog niet in zicht is.
Ik hoop wel dat men echt energie steekt in het zoeken naar een oplossing, want dit is toch echt een forse handicap.

[ Voor 29% gewijzigd door Politoer op 22-01-2012 15:15 . Reden: aanpoassing typenr handsets en probleembeschrijving ]

[rondebru]

Sinds ik bij telefonie "naar mobiel bellen niet toestaan" heb afgevinkt, zijn lokale nummers beginnend met een 6 niet meer te bellen!
Mobiel begint toch met 06....

Heb de mogelijkheid maar weer uitgeschakeld

[Anoniem: 376876]

rondebru schreef op woensdag 18 januari 2012 @ 15:36:
Sinds ik bij telefonie "naar mobiel bellen niet toestaan" heb afgevinkt, zijn lokale nummers beginnend met een 6 niet meer te bellen!
Mobiel begint toch met 06....

Heb de mogelijkheid maar weer uitgeschakeld

Ik vrees dat ze de nationale 0 (nul) eraf slopen, want een 06 nummer wordt in nummermelding getoond als 00316xxxxxx, ofwel landnummer ervoor en dus begint het telefoonnummer met een 6 en niet met een 0....gok ik.

[rondebru]

Telefoon werkt nu helemaal niet meer, kan niet bellen of gebeld worden. Tot voor kort geen probleem. Na gebruik van de instellingen voor voicemail en mobiel bellen dus niets meer.

Update:
Naar mobiel bellen blijkt wel te kunnen

Update 2:
Na tussenkomst van het Webcare team is op 25 januari de boel hersteld. Alles functioneert zoals het hoort.
De gewenste instellingen voor de telefoon worden nu handmatig door de technische dienst ingesteld.
Het telefonieplatform via Mijn Lijbrandt werkt (nog) niet goed, dus maar niet gebruiken vooralsnog.

Update 3:

De technische dienst heeft via Webcare de gewenste instellingen doorgevoerd. Alles werkt nu naar behoren.
De eerste voicemail is via email ontvangen!

[ Voor 66% gewijzigd door rondebru op 28-01-2012 16:42 ]

[Politoer]

@fiberdordrecht

Mijn post hierboven spoort niet helemaal met de gegevens in je topicstart.

[MCP cloud]

Ze weten nog niks zinnig te vertellen over het probleem en als je ze op belt weten ze van niks.
"een mogelijke fix ontwikkeld die in de loop van januari 2012 zal worden uitgerold""

Krijg je het standaard praatje....... erg vervelend enz.....
Inmiddels al 5 maanden aan de gang dit probleem

Het is zelfs zo erg dat hier in Dordrecht in de reggefiber glasvezel winkel wordt geadviseerd niet Lijbrandt te kiezen.

[Anoniem: 438894]

Nog even een aanvulling op mijn al eerder genoemde menuklachten bij Lijbrandt telefonie.
Nieuwe analoge telefoon aangeschaft, type NRX EVO 450.
Ook hiermee menutoetsen getest.
Helaas, meerdere pogingen met bankrekeningnummers levert op dat 2 of 3 cijfers van de 9 niet gedetecteerd worden.
Idem bij het bellen met de klantenservice kpn, keuze ingeven werkt niet.
Wat een basic getob !