[VoIP, PHP] Linebreak toevoegen

[Verwijderd]

Dames en heren,

In het kort:
Bij inkomende gesprekken query ik de database op gegevens van de beller. De resultaten passen niet volledig in het scherm en ik wil graag een linebreak toevoegen. De resultaten worden gegenereerd doormiddel van PHP maar gedisplayed op een telefoon.

Ietsjes langer:
Momenteel beschikken wij hier over een FreePBX server waarin ik sinds gisteren een name lookup source heb toegevoegd.
Deze instelling doet heel simpel maar 1 ding: een postback naar een .php bestand en daar de callback van doorvoeren naar het scherm van de telefoons.
De actie wordt goed uitgevoerd en het werkt. Ik vraag om een minimaal een bedrijfsnaam en wanneer mogelijk ook nog de persoonsnaam van de beller.
De volgorde van de output is "bedrijfsnaam / achternaam, voornaam". Echter past het 8/10 de tekst niet op het scherm en valt de helft weg, dus zie je nog niet WIE er nou belt...

Er wordt gebruik gemaakt van:
FreePBX VoIP
Polycom Soundpoint 650


Mijn vraag:
-Hoe kan ik een witregel plaatsen wat wordt herkend door de telefoon?

*Ik heb de logische akties zoals het toevoegen van een <br/>, <br>, \n al toegepast. Niet het gewenste resultaat.*

[supakeen]

Heb je ook \r\n al geprobeerd? Is de data die terug komt een string of binaire data? Heb je de documentatie van de server opgezocht of ze misschien een speciaal karakter verwachten? Heeft het scherm ook echt 2 regels?

[MueR]

Het is misschien handig als je ook het merk en type telefoon vermeldt. Om daar even bij te bleven, is er van de telefoon danwel server technische documentatie beschikbaar bij de fabrikant en zo ja, leveren die geen uitkomst?

[ Voor 4% gewijzigd door MueR op 17-02-2010 11:27 . Reden: le-zen ]

[RobIII]

Zover ik weet is dat afhankelijk van het type telefoon. Zo werken wij met Cisco toestellen en die begrijpen volgens mij gewoon een \r\n (maar dat zal ik even nakijken voor de zekerheid). Maar ik meen me te herinneren dat een aantal toestellen niet aan 'multiline' doet.

MueR schreef op woensdag 17 februari 2010 @ 11:24:
Het is misschien handig als je ook het merk en type telefoon vermeldt.

Staat er bij Deze dus.
Qua documentatie weet ik dat die vaak 0 of erg gebrekkig is.

Ik ben verder niet zo heel erg bekend met FreePBX (wij werken 'rechstreeks' met Asterisk) maar als er gebruik gemaakt wordt van AGI dan kan ik me sowieso voorstellen dat een newline niet geaccepteerd wordt; dat zou namelijk als een nieuwe command sequence gezien worden.

Ik ben even onze code ingedoken maar zover ik kan zien sturen wij geen newlines (dat zou betekenen dat de Cisco's het zelf regelen). Nu is er nogal wat code om door te spitten dus 't kan zijn dat ik iets over het hoofd zie.

Misschien het proberen waard om een escaped versie van \n of \r\n te sturen (dus \\n of \\r\\n)

offtopic:
Overigens lossen wij 't display probleem (if any) ook anders op: we draaien een client-applicatie op de (vaak toch al aanwezige) PC naast het toestel en tonen daar op een MSN-popup-achtige manier de incoming caller. Ons .Net component dat we ontwikkeld hebben als onderliggende laag voor die applicatie (en voor vele andere zaken) genaamd "Castman" gaan we later dit jaar zeer waarschijnlijk als open source vrijgeven.

[ Voor 89% gewijzigd door RobIII op 17-02-2010 11:52 ]

[Verwijderd]

ikanobori schreef op woensdag 17 februari 2010 @ 11:24:
Heb je ook \r\n al geprobeerd? Is de data die terug komt een string of binaire data? Heb je de documentatie van de server opgezocht of ze misschien een speciaal karakter verwachten? Heeft het scherm ook echt 2 regels?

Het scherm heeft 2 regels ja, dat is duidelijk zichtbaar na het toevoegen van een \n. De output hiervan is dat ALLE tekst op de 2de regel komt te staan....

Ik heb met \r\n geen succes, alles wordt normaal gedisplayed.
Heb wel een ontdekt dat wanneer je een spatie tussen de \r en de \n plaatst dat de telefooncentrale dat niet leuk vindt en de inkomende beller in de wachtruimte pleurt....vaag!

De terugkomende data is een String, ik roep het op uit de odbc object en print het naar het scherm.Geen enkele vorm van html komt aan te pas.

Documentatie van de server niet aan gedacht...:$ (schaamt zich heeeel erg momenteel...grootste aanhanger van RTFM)

RobIII schreef op woensdag 17 februari 2010 @ 11:24:
Zover ik weet is dat afhankelijk van het type telefoon. Zo werken wij met Cisco toestellen en die begrijpen volgens mij gewoon een \r\n (maar dat zal ik even nakijken voor de zekerheid). Maar ik meen me te herinneren dat een aantal toestellen niet aan 'multiline' doet.

[...]

Staat er bij Deze dus.
Qua documentatie weet ik dat die vaak 0 of erg gebrekkig is.

Ik ben verder niet zo heel erg bekend met FreePBX (wij werken 'rechstreeks' met Asterisk) maar als er gebruik gemaakt wordt van AGI dan kan ik me sowieso voorstellen dat een newline niet geaccepteerd wordt; dat zou namelijk als een nieuwe command sequence gezien worden.

Ik ben even onze code ingedoken maar zover ik kan zien sturen wij geen newlines (dat zou betekenen dat de Cisco's het zelf regelen). Nu is er nogal wat code om door te spitten dus 't kan zijn dat ik iets over het hoofd zie.

Misschien het proberen waard om een escaped versie van \n of \r\n te sturen (dus \\n of \\r\\n)

Bedankt voor je moeite! Ik zal even kijken of dat werkt!


EDIT:
Castman...klinkt goed! Ik snap niet dat wij dat hier nog niet hebben eigenlijk, een soortgelijk programma. We hebben een rijk gevulde database waar ik nu de informatie uit query en we hebben zeer goede .NET ontwikkelaars hier! ... Nou wellicht nog een project voor mij dan.


Overigens probeer ik nu hetvolgende: print("Bedrijfsnaam -". chr(hexdec('0D'))." achternaam, voornaam");
Wellicht dat dit wordt opgepakt door de machine
Geen resultaat....Overigens werkt het escapen ook niet...

---

Nou ik kom er echt niet uit, heb veel geprobeerd maar zonder resultaat...er is amper tot geen documentatie te vinden voor dit toestel wat uberhaupt in de buurt komt van het geen ik mij mee bezig hou... Dan zou het wellicht niet eens kunnen denk ik dan. Anyways, allemaal bedankt voor jullie input!

[ Voor 15% gewijzigd door Verwijderd op 17-02-2010 13:42 ]