MWI mit Sipura

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
M

Malte.

Mitglied
Mitglied seit
4 Jun 2004
Beiträge
656
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich würde ja auch gerne die MWI-Funktion von Sipgate nutzen. Wenn ich in meinem Sipura in der Configuration im Tab User 1 - Supplementary Service Settings, Message Waiting auf yes stelle, dann steht kurz darauf im Info-Tab unter Line 1 Status: Message Waiting: Yes
Am Telefon blinkt auch die Lampe, aber wenn ich die 50000 anrufe sind eben keine Anrufe vorhanden.

Wie kann ich das Feature so einstellen, dass es tatsächlich die Sipgate-Funktion abfragt und anzeigt?
 
Schau dir mal den Syslog an.
 
Danke für den Tipp.
Allerdings habe ich das bereits getan. Leider weiß ich nicht, wo nach ich da im Syslog suchen soll. Der Sipura registriert sich ganz normal und sendet dann jede Minute eine Notify-Nachricht. Das ist alles.
Ich kann nichts entdecken, das ich mit Message Waiting o.ä. in Verbindung bringen könnte.

Wenn ich den Hörer abhebe, wenn das Lämpchen blinkt, dann bekomme ich auch den Stuttered Dialtone, also 2 Sek. schnelles Tüten, danach Dauerwählton.
Der Sipura ist also offensichtlich der Meinung, dass er eine wartende Nachricht signalisieren müsste und mein Telefon versteht das auch entsprechend.

Wie kann ich ihm angewöhnen, nur dann eine wartende Nachricht zu signalisieren, wenn auch wirklich eine vorliegt?
 
Malte. schrieb:
Der Sipura registriert sich ganz normal und sendet dann jede Minute eine Notify-Nachricht.
Zum Vergrößern anklicken....

Ich glaube nicht, daß der Sipura von sich aus NOTIFY messages versendet :wink:

Wie sieht denn so eine NOTIFY message inhaltlich aus?
 
Upps, da habe ich mich wohl etwas vertan.
Es handelt sich um die NAT Keep Alive Msg. Die ist inhaltlich sogar leer, bzw. besteht laut Syslog wohl aus einem einzelnen Linefeed-Zeichen <010>.
 
Stell mal wieder das hier ein: NAT Keep Alive Msg: $NOTIFY
Dann sendet er auch wieder richtige Notifies.

Wenn ich mich richtig erinnere, müsste in der Antwort zum Notify ein Header für MWI sein. Probiers mal aus.


Update:

Ich lese gerade das hier: http://www.ip-phone-forum.de/showpost.php?p=614166&postcount=22

Danach solltest du lieber NAT Keep Alive Msg: $REGISTER einstellen.
 
Danke. Funktioniert leider nicht.

$NOTIFY liefert zunächst mal keine Informationen zu MWI - da keine Nachrichten vorhanden sind, muss das auch nicht schlimm sein. (Der Name $NOTIFY hatte wohl meine missverständliche Äußerung von oben motiviert ;-))

$REGISTER führt doch eine Registrierung durch. Für das NAT Keep-Alive halte ich das für etwas übertrieben. Außerdem funktioniert es nicht, genausowenig wie es nach einem reboot des Sipura funktioniert hat. Da fing die Lampe sofort an zu blinken, noch bevor die erste Keep Alive Msg. raus ging.

Ich halte es auch für komisch, dass der Sipura vom Fehlen einer Antwort (auf die leere Nachricht bekommt er sinnvollerweise keine) auf vorhandene Nachrichten schließen sollte.

Ich würde ja auch gerne eine SUBSCRIBE Nachricht schicken, aber da muss sicherlich noch mehr drinstehen als nur "SUBSCRIBE"?
 
Malte. schrieb:
Ich würde ja auch gerne eine SUBSCRIBE Nachricht schicken, aber da muss sicherlich noch mehr drinstehen als nur "SUBSCRIBE"?
Zum Vergrößern anklicken....

Das ist nicht zulässig. Der Sipura kennt nur $NOTIFY und $REGISTER als Makros für NOTIFY-Messages.

Irgendwo muss das ja herkommen. Zeig mal deinen Syslog-Dump :)
 
zoo schrieb:
Irgendwo muss das ja herkommen. Zeig mal deinen Syslog-Dump :)
Zum Vergrößern anklicken....
Okay, hier ist mein Syslog. Es beginnt mit dem Reboot nachdem ich unter User 1 Message Waiting of yes gestellt habe:
Code: 
2006-06-28 13:00:32	Local7.Debug	192.168.1.2	fu:0:4c17, 0168 0001
2006-06-28 13:00:32	Local7.Debug	192.168.1.2	SYSCFG:WARMBOOT 124 168
2006-06-28 13:00:32	Local7.Debug	192.168.1.2	fu:0:4c4d, 0038 03e4 0445 0001
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	System started: [email protected], reboot reason:W4
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	System started: [email protected], reboot reason:W4
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<009>subnet mask:<009>255.255.255.0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<009>gateway ip:<009>192.168.1.1
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<009>dns servers:<009>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	10.10.10.252
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	10.10.10.244
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[5060]STUN trying 0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[5060]STUN trying 1
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[5060]STUN trying 0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[5060]STUN trying 0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0]REG: STUN c0a80102->53a9985a, 5060->5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	RSE_DEBUG: reference domain:sipgate.de
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]->217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]->217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	REGISTER sip:sipgate.de SIP/2.0<013><010>Via: SIP/2.0/UDP 83.169.xx.xx:5060;branch=z9hxxxx-fbcxxxx;rport<013><010>From: Malte Huelder <sip:[email protected]>;tag=ff89ea5b187354xxxx<013><010>To: Malte Huelder <sip:[email protected]><013><010>Call-ID: [email protected]<013><010>CSeq: 1 REGISTER<013><010>Max-Forwards: 70<013><010>Contact: Malte Huelder <sip:[email protected]:5060>;expires=4000<013><010>Warning: 399 spa "Full Cone NAT Detected"<013><010>User-Agent: Sipura/SPA2000-3.1.5<013><010>Content-Length: 0<013><010>Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER<013><010>Supported: x-sipura
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]<<217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]<<217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	SIP/2.0 401 Unauthorized<013><010>Via: SIP/2.0/UDP 83.169.xx.xx:5060;branch=z9hxxxx-fbcxxxx;rport=5060<013><010>From: Malte Huelder <sip:[email protected]>;tag=ff89ea5b187354xxxx<013><010>To: Malte Huelder <sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c6xxxx<013><010>Call-ID: [email protected]<013><010>CSeq: 1 REGISTER<013><010>WWW-Authenticate: Digest realm="sipgate.de", nonce="44a26280905f41c4c2c1844a05c93dc16axxxxx"<013><010>Server: sipgate ser<013><010>Content-Length: 0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[5060]STUN trying 0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0]REG: STUN c0a80102->53a9985a, 5060->5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	RSE_DEBUG: reference domain:sipgate.de
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]->217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]->217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	REGISTER sip:sipgate.de SIP/2.0<013><010>Via: SIP/2.0/UDP 83.169.xx.xx:5060;branch=z9hxxxx-5ac0xxxx;rport<013><010>From: Malte Huelder <sip:[email protected]>;tag=ff89ea5b187354xxxx<013><010>To: Malte Huelder <sip:[email protected]><013><010>Call-ID: [email protected]<013><010>CSeq: 2 REGISTER<013><010>Max-Forwards: 70<013><010>Authorization: Digest username="26xxxxx",realm="sipgate.de",nonce="44a26280905f41c4c2c1844a05c93dc16xxxxx",uri="sip:sipgate.de",algorithm=MD5,response="2421982276ac656926dd38f82d26xxxx"<013><010>Contact: Malte Huelder <sip:[email protected]:5060>;expires=4000<013><010>Warning: 399 spa "Full Cone NAT Detected"<013><010>User-Agent: Sipura/SPA2000-3.1.5<013><010>Content-Length: 0<013><010>Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER<013><010>Supported: x-sipura
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]<<217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0:5060]<<217.10.79.9:5060
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	SIP/2.0 200 OK<013><010>Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hxxxx-5ac0xxxx;rport=5060<013><010>From: Malte Huelder <sip:[email protected]>;tag=ff89ea5b187354xxxx<013><010>To: Malte Huelder <sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c6xxxxxx<013><010>Call-ID: [email protected]<013><010>CSeq: 2 REGISTER<013><010>Contact: <sip:[email protected]:5060>;expires=4000<013><010>Server: sipgate ser<013><010>Content-Length: 0
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:00:35	Local7.Debug	192.168.1.2	[0]RegOK. NextReg in 3999 (1)
2006-06-28 13:00:36	Local7.Debug	192.168.1.2	IDBG: st-0
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fs:07862:07887:65536
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fbr:0:0000:0000:04c4d:000e:000d:3.1.5
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:01:0:0001:upg:app:0:2.0.10(d)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:02:0:0002:upg:app:1:2.0.10(d)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:03:0:0003:upg:app:2:2.0.10(d)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:04:0:0004:upg:app:0:2.0.10(e)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:05:0:0005:upg:app:1:2.0.10(e)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:06:0:0006:upg:app:2:2.0.10(e)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:07:0:0007:upg:app:0:2.0.11(g)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:08:0:0008:upg:app:1:2.0.11(g)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:09:0:0009:upg:app:2:2.0.11(g)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:0a:0:000a:upg:app:0:2.0.13(g)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:0b:0:000b:upg:app:1:2.0.13(g)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:0c:0:000c:upg:app:2:2.0.13(g)
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:0d:0:000d:upg:app:0:3.1.5
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:0e:0:000e:upg:app:1:3.1.5
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fhs:0f:0:000f:upg:app:2:3.1.5
2006-06-28 13:00:38	Local7.Debug	192.168.1.2	fu:0:4c6d, 0003 0001
2006-06-28 13:00:40	Local7.Debug	192.168.1.2	RSE_DEBUG: unref domain, sipgate.de
2006-06-28 13:00:40	Local7.Debug	192.168.1.2	RSE_DEBUG: unref domain, sipgate.de
2006-06-28 13:00:40	Local7.Debug	192.168.1.2	RSE_DEBUG: last unref for domain sipgate.de
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	RSE_DEBUG: reference domain:sipgate.de
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	[0:5060]->217.10.79.9:5060
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	[0:5060]->217.10.79.9:5060
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	NOTIFY sip:sipgate.de SIP/2.0<013><010>Via: SIP/2.0/UDP 83.169.xx.xx:5060;branch=z9hxxxx-7760xxxx;rport<013><010>From: Malte Huelder <sip:[email protected]>;tag=ff89ea5b187354xxxx<013><010>To: <sip:sipgate.de><013><010>Call-ID: [email protected]<013><010>CSeq: 1 NOTIFY<013><010>Max-Forwards: 70<013><010>Event: keep-alive<013><010>User-Agent: Sipura/SPA2000-3.1.5<013><010>Content-Length: 0
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	[0:5060]<<217.10.79.9:5060
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	[0:5060]<<217.10.79.9:5060
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	SIP/2.0 200 OK<013><010>Via: SIP/2.0/UDP 83.169.xx.xx:5060;branch=z9hxxxx-7760xxxx;rport=5060<013><010>From: Malte Huelder <sip:[email protected]>;tag=ff89ea5b187354xxxx<013><010>To: <sip:sipgate.de>;tag=b11cb9bb270104b49a99a995b8c685xxxxxx<013><010>Call-ID: [email protected]<013><010>CSeq: 1 NOTIFY<013><010>Server: sipgate ser<013><010>Content-Length: 0
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	<010>
2006-06-28 13:01:35	Local7.Debug	192.168.1.2	[0]ExtSipPortChanged:0
2006-06-28 13:01:40	Local7.Debug	192.168.1.2	RSE_DEBUG: unref domain, sipgate.de
2006-06-28 13:01:40	Local7.Debug	192.168.1.2	RSE_DEBUG: last unref for domain sipgate.de
Um 13:00:38 begann das Telefon bereits zu blinken.
 
da kann ich auch nichts erkennen :(

Zur MWI gibt es diese RFCs:
http://www.ietf.org/rfc/rfc3842.txt
http://www.ietf.org/rfc/rfc3265.txt

Bei DUS.net sieht so ein NOTIFY z.B. so aus:

Code: 
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 83.125.xx.xx:5060;branch=z9hG4bK0b76fbe7;rport
From: "Anonymous" <sip:[email protected]>;tag=as40756be1
To: <sip:[email protected]:5061>
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 NOTIFY
User-Agent: dus.net GmbH
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 84

Messages-Waiting: no
Message-Account: sip:[email protected]
Voice-Message: 0/0 (0/0)
 
Funktioniert damit denn MWI bei Dir mit dus.net?
Das Verwunderliche ist ja, dass der Sipura meint, es wären Voicemails da, obwohl ich im Log keinen Hinweis darauf in den ausgetauschten Nachrichten finden kann.
 
Hier laeuft Sipura SPA2k und dus.net 100%ig. Hatte aber interessanterweise zwischenzeitlich das selbe Problem wie Du (erst funktionierte es, dann kurzfristig nicht, dann klappte es wieder). Habe mir damals einen Syslog-Mitschnitt der SIP Nachrichten angeschaut, und keine Spur von MWI darin gefunden.

Wilde Spekulation: evt verlangt der Sipura für MWI Nachrichten in der Form der bereits zitierten SIP Notify Nachrichten, und interpretiert ein Ausbleiben einer solchen Nachricht als Message Waiting. Und sendet keine Subscribe Messages fuer die Aktivierung von MWI Nachrichten. Das koennte das von Dir beobachtete Verhalten auftreten.

Meine Probleme traten naemlich damals auf, als dus.net an der MWI Unterstuetzung fuer die Fritzboxen arbeitete, in Verbindung mit ihrem Sponsoring des "MWI Subscription Support" bei Asterisk. Frueher hat Asterisk einfach MWI drauflos gesendet... Siehe Diskussion unter http://bugs.digium.com/view.php?id=6390
 
Hi,
ich habe einen SPA1001 am sipgate Account und die gleichen Probleme: Ist MWI mal an, geht es nie weider aus. Auch nach Neustart der Box nicht wenn keine Voicemail anliegt.

Mit STUN oder NAT keepalive hat es hoffentlich nichts zu tu, da ich das nicht verwende / brauche.

Gibt es denn keinen SPA Guru, der da helfen kann?
 
schufti schrieb:
Gibt es denn keinen SPA Guru, der da helfen kann?
Zum Vergrößern anklicken....
alternative Lösungsvorschläge:
1. MWI abstellen
2. Sipura Support nerven, dass sie ihre Firmware anpassen
3. Sipgate Support nerven, dass sie die Sipuras bei MWI unterstützen

Viel Erfolg,
TSCoreNinja
 
das sagt wohl alles ....

Thank you for contacting Linksys Technical Support.

I appreciate the information you sent me. When the WMI is activated, regardless if there is a registered VoIP or is there is a message waiting, it will really be immediately activated. This simply denotes that this service is “on” but it doesn’t really indicate that there is an actual message waiting in the VoIP line.

You can email our sales department for future enhancement of our products and maybe your problem will be included in the next updated firmware release.

We appreciate your continued patience.
Zum Vergrößern anklicken....

Auch mein Problem mit der Verwendung von 'URI (IP) dialing' (siehe anderswo in diesem Bereich) wurde nach 4 Monaten ähnlich beendet; in aktueller Beta FW ist es sogar noch übler geworden. Auch wenn es unlogisch ist, es bei anderen Produkten funktioniert und manche Aspekte davon dem Handbuch widersprechen.

... use of URI in speed dial is not possible if registered with a proxy ...
Zum Vergrößern anklicken....

schön langsam habe ich den Eindruck, dass die 'vielen tollen' Einstellmöglichkeiten in den SPA Geräten nur da sind, um dem Endandwender die Möglichkeit zu geben, Fehler in der FW selbst auszubügeln.

schufti
 
also, mein Gespräch mit dem 2nd level technician hat Licht in die Sache gebracht:

Die Option 'Message Waiting' On/Off hat nichts mit den sonst in ATAs zu findenden 'subscribe to MWI' zu tun. Diese Menüoption schaltet wirklich nur den MWI am Telefon ein (angeblich hat ein Hottentotten Provider so MWI über das Provisioning File gelöst, anstatt über den RFC)

dass MWI trotzdem nicht funktioniert liegt angeblich an sipgate....
zumindest in dem Punkt scheint der SPA entschuldigt.

Gruß,
Schufti
 
Zuletzt bearbeitet:
schufti schrieb:
schön langsam habe ich den Eindruck, dass die 'vielen tollen' Einstellmöglichkeiten in den SPA Geräten nur da sind, um dem Endandwender die Möglichkeit zu geben, Fehler in der FW selbst auszubügeln.
Zum Vergrößern anklicken....

Die Sipura-Geräte sind nicht auf die Zielgruppe "Consumer" ausgerichtet, sondern an Großkunden, die gleich palettenweise SPAs kaufen und verteilen. Da machen die mehreren Hundert Schalter und Einstellungen durchaus Sinn. Dadurch sind die Geräte sehr flexibel. So muss der Hersteller nicht für jeden Großkunden eine eigene Firmware bereitstellen.

Für uns VoIP-Freaks, die sich ein SPA zugelegt haben, bringen viele der Einstellungen gar nichts. Oder man stellt es einmal ein und gut ist es.

Man sollte sich IMHO nicht wegen der vielen Einstellmöglichkeiten für einen SPA entscheiden, sonder wegen der guten Sprachqualität und der Erfahrung des Herstellers und/oder wegen des guten Supports (ab 2nd level :) )
 
hi zoo!

Da machen die mehreren Hundert Schalter und Einstellungen durchaus Sinn. Dadurch sind die Geräte sehr flexibel.
Zum Vergrößern anklicken....

Ja, das mag schon stimmen; aber eben nur bedingt. Gerade die großen Provider brauchen die Flexibilität nicht wirkich. Die geben ja die Bedingungen für die Kunden vor. Aber der kleine engagierte User, der vielleicht mehr als einen Provider haben will, möchte wohl, dass Standards auf beiden Seiten korrekt umgesetzt werden. (Ja,ja, ich weiß schon: das ist alles noch im werden und muß sich erst entwickeln und stabilisieren....)


Da stimmt es eben traurig, dass auch der 2nd level support scheinbar kein Einsehen haben will,

[offtopic]
dass es durchaus Sinn macht, eine Einstellung zu haben, wo sip-uri's aus dem Speeddial an den Proxy des Providers geschickt werden oder es auch eine bessere Methode als das Löschen aller *xx Servicecodes unter dem Regional Tab geben muß, um Steuersequenzen an den Asterisk zu kriegen oder dass eine dausgeschaltete 1.Leitung nicht einfach zur Funktionslosigkeit des gesammten Adapters führen sollte.
[/offtopic]

Generell hat man eher das Gefühl, dass sie Bugreports von engagierten Usern eigentlich überhaupt nicht wünschen, wenn man über 2 Monate einen offensichtlichen FW Bug beschreiben läßt (der in der Auswirkung sogar entgegen dem Handbuch steht), um dann einfach zu sagen, das ist einfach so. Man könnte ja auch sagen: ok, wir können das nachvollziehen, sehen aber keine Notwendigkeit das zu ändern. Kurz, Ehrlich, Einfach.

in diesem Sinne,
schufti
 
Zuletzt bearbeitet:
Ja, es gibt an jedem ATA noch zu meckern. Und leider muss man beim Support stur bleiben. Ich schreibe da immer "Das ist ein Bug! Bitte melden Sie das an Ihren Vorgesetzten und an die FW-Entwickler." Ich verlange auch die kompetenten Mitarbeiter, die ich schon kenne. Leider kostet das trotz alledem viel Energie, da gebe ich dir Recht. Da fragt die 1st-Level-Trulla nach Einstellungen und Syslogs, die ich schon längst gemailt hatte. Dass man dabei dann noch ruhig bleiben kann... geht nur auf Droge.......
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 340 (Mitglieder: 32, Gäste: 308)

Neueste Beiträge

Statistik des Forums

Themen
245,883
Beiträge
2,241,859
Mitglieder
373,188
Neuestes Mitglied
Hagen67k
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück