BLF über SIP

Aktuelle TK-Anlagen COMpact 5010/5020 VoIP
1

[FONT=Verdana][COLOR=#000000]Hallo!

Ich habe hier eine 5020 VoIP installiert.[/COLOR][color=#000000] Neuste Firmware: 4.2C[/color]

[color=#000000]Neben den normalen Systemtelefonen (2500AB) ist auch ein Snom760 per SIP (als “Standard-VoIP-Telefon”) angeschlossen. Telefonieren funktioniert.[/color]
[color=#000000]Das Snom soll aber auch den Zustand der Nebenstellen von der 5020 als BLF auf seinen F-Tasten anzeigen. Das klappt nicht.[/color]

[color=#000000]Der SIP Trace zeigt:[/color]

[color=#000000]Sent to udp:192.168.1.10:5060 at 8/11/2012 18:34:32:329 (448 bytes):[/color]
[color=#000000]SUBSCRIBE [/color][color=#0000FF]sip:**201@192.168.1.10[/color][color=#000000];user=phone SIP/2.0[/color]
[color=#000000]Via: SIP/2.0/UDP 192.168.1.150:58928;branch=z9hG4bK-19ht8ox8l9vy;rport[/color]
[color=#000000]From: <[/color][color=#0000FF]sip:206@192.168.1.10[/color][color=#000000]>;tag=mvn92x35t7[/color]
[color=#000000]To: <[/color][color=#0000FF]sip:**201@192.168.1.10[/color][color=#000000];user=phone>[/color]
[color=#000000]Call-ID: 28ed9b50c14c-s2tv40hyd8b5[/color]
[color=#000000]CSeq: 3 SUBSCRIBE[/color]
[color=#000000]Max-Forwards: 70[/color]
[color=#000000]Contact: <[/color][color=#0000FF]sip:206@192.168.1.150:58928[/color][color=#000000]>;reg-id=1[/color]
[color=#000000]Event: dialog[/color]
[color=#000000]Accept: application/dialog-info+xml[/color]
[color=#000000]User-Agent: snom760/8.7.3.15[/color]
[color=#000000]Expires: 0[/color]
[color=#000000]Content-Length: 0[/color]

[color=#000000]Received from udp:192.168.1.10:5060 at 8/11/2012 18:34:32:577 (509 bytes):[/color]
[color=#000000]SIP/2.0 489 Bad Event[/color]
[color=#000000]Via: SIP/2.0/UDP 192.168.1.150:58928;branch=z9hG4bK-19ht8ox8l9vy;rport=58928[/color]
[color=#000000]From: <[/color][color=#0000FF]sip:206@192.168.1.10[/color][color=#000000]>;tag=mvn92x35t7[/color]
[color=#000000]To: <[/color][color=#0000FF]sip:**201@192.168.1.10[/color][color=#000000];user=phone>;tag=BtQrKcSevFNgj[/color]
[color=#000000]Call-ID: 28ed9b50c14c-s2tv40hyd8b5[/color]
[color=#000000]CSeq: 3 SUBSCRIBE[/color]
[color=#000000]User-Agent: Auerswald COMpact VoIP sofia-sip/1.12.11[/color]
[color=#000000]Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, REGISTER, SUBSCRIBE, INFO, REFER[/color]
[color=#000000]Supported: 100rel, timer, replaces[/color]
[color=#000000]Allow-Events: auerswald-systel-config, refer[/color]
[color=#000000]Content-Length: 0[/color]

[COLOR=#000000]Das Standard SUBSCRIBE dialog Event wird mit “Bad Event” abgelehnt (obwohl der sofia-sip Stack das ja ansich kann) - und ist auch kein Allow-Event.

Kann die 5020 das trotz “neuem” SIP-Stack immer noch nicht? Oder von Auerswald absichtlich nicht umgesetzt - oder mache ich was falsch?

[/COLOR][/FONT]Danke für etwas Klarheit!
Marco

2

[quote=Mar_o][FONT=Verdana]
[COLOR=#000000]Neben den normalen Systemtelefonen (2500AB) ist auch ein Snom760 per SIP (als “Standard-VoIP-Telefon”) angeschlossen.
[…][/COLOR][COLOR=#000000]
Kann die 5020 das trotz “neuem” SIP-Stack immer noch nicht? Oder von Auerswald absichtlich nicht umgesetzt - oder mache ich was falsch?
[/COLOR][/FONT][/quote]

Also, nach meinem letzten Kenntnisstand werden “Fremdgeräte” nach wie vor nicht vollständig unterstützt. Daher auch “Standard-VoIP-Telefon” :wink:

Genaueres kann ich Dir am Mittwoch kommender Woche dazu sagen.

vG,
Michael

3

Hallo,

ich denke du machst nichts falsch. Die Besetzlampen sollen nur beim Systemtelefon funktionieren.

Gruß

Uwe

4

[quote=noses]Genaueres kann ich Dir am Mittwoch kommender Woche dazu sagen.[/quote]Na, da bin ich mal gespannt…

Selbst von einem “Standard” VoIP Telefonanschluss in der 5020 erwarte ich das eigentlich, zumal solche Dinge wie Pickup dann leider auch nicht funktionieren.
Wäre aber keine gute Politik von Auerswald, da es aus verschiedensten Gründen immer wieder Fälle gibt, wo ein Fremd-SIP-Phone verwendet werden muss.

5

Also, hier wie die zugesagte Antwort:

BLF auf Standard-SIP-Telefonen sind nicht implementiert und es ist derzeit auch nicht vorgesehen, daran was zu ändern.

Die Auerswald-Systemtelefone sind so konzipiert, dass solche Funktionen über die Firmware des Systemtelefones zur Verfügung gestellt werden und nicht über den Sip-Stack in der Anlage. Das betrifft dann auch so Dinge wie eine Wähl- oder Besetztton, der ja naturgemäß nicht von der TK-Anlage kommt sondern im Endgerät signalisiert wird.

vG,
Michael

6

Michael, vielen Dank für Deine Recherche!
Eine ähnliche Antwort habe ich gestern auch vom Auerswald-Service bekommen. Leider.
Das ist natürlich sehr ärgerlich, da der Kunde das so nicht akzeptieren wird und nun die Auerswald-Anlage wohl komplett gegen eine Askozia o.ä. ausgetauscht wird. :-/

Gruss,
Marco

7

[quote=Mar_o]Michael, vielen Dank für Deine Recherche!
Eine ähnliche Antwort habe ich gestern auch vom Auerswald-Service bekommen. Leider.
Das ist natürlich sehr ärgerlich, da der Kunde das so nicht akzeptieren wird und nun die Auerswald-Anlage wohl komplett gegen eine Askozia o.ä. ausgetauscht wird. :-/

Gruss,
Marco[/quote]

Ich kann Auerswald (und andere Hersteller) durchaus verstehen, dass diese Ihre Systeme nicht für solche Fremd-Telefone öffnen wollen.

Auch zu verstehen ist, dass Kunden immer mehr gerne selbst entscheiden möchten, welche Telefone sie einsetzen.

Das wird in Zukunft zu mehr und mehr generellen Problemen führen und Kunden dazu veranlassen zu softwarebasierten Systemen zu wechseln.

Die Tk-Anlagen-Hersteller täten denke ich gut daran den Kunden sowie den Fachhändlern begründete Wünsche zum Funktionsumfang von den Augen abzulesen, damit Kunden davon überzeugt sind mit dem Kauf einer Tk-Anlage mit entsprechenden Systemtelefonen die richtige Wahl zu treffen.

8

[quote=PABX-Alex]Ich kann Auerswald (und andere Hersteller) durchaus verstehen, dass diese Ihre Systeme nicht für solche Fremd-Telefone öffnen wollen.

Auch zu verstehen ist, dass Kunden immer mehr gerne selbst entscheiden möchten, welche Telefone sie einsetzen.

Das wird in Zukunft zu mehr und mehr generellen Problemen führen und Kunden dazu veranlassen zu softwarebasierten Systemen zu wechseln.

Die Tk-Anlagen-Hersteller täten denke ich gut daran den Kunden sowie den Fachhändlern begründete Wünsche zum Funktionsumfang von den Augen abzulesen, damit Kunden davon überzeugt sind mit dem Kauf einer Tk-Anlage mit entsprechenden Systemtelefonen die richtige Wahl zu treffen.[/quote]

Sehe ich auch so. Ich, als Kunde, werde in Zukunft noch mehr darauf achten das meine Geräte Standards unterstützen.
Und ich hoffe doch sehr das Auerswald das möglichst bald einsieht und sich vermehrt an Standards hält.
Das betrifft übrigends nicht nur die Anlagen sondern auch Telefone.

Christian

9

[quote=baltic]Sehe ich auch so. Ich, als Kunde, werde in Zukunft noch mehr darauf achten das meine Geräte Standards unterstützen.
Und ich hoffe doch sehr das Auerswald das möglichst bald einsieht und sich vermehrt an Standards hält.
Das betrifft übrigends nicht nur die Anlagen sondern auch Telefone.

Christian[/quote]

Nur um Missverständnissen vorzubeugen :

Ich kann verstehen, dass Tk-Anlagen-Hersteller nicht alle “Komfortfunktionen” allgemein sondern nur mit zu den Anlagen passenden, eigenen Endgeräten zugänglich machen möchten, doch sollten diese auch dann noch supportet werden wenn bereits Nachfolgergeräte am Start stehen und man sollte auf Kundenwünsche für diese Tk-Anlagen mehr eingehen um zu vermeiden, dass Kunden softwarebasierten Systemen den Vorzug geben.

10

Ich will ja nun kein Faß aufmachen, aber alleine schon das Wort Standard und die Definition dessen wäre vermutlich abendfüllend.

Verbunden mit dem Umstand, dass

  1. viele Fachhändler ja schon mit den wenigen hersteller-eigenen Endgeräten und deren Konfiguration schnell überfordert sind

  2. der nahzu jeder Hersteller schon genug Aufwand mit dem Testen und Anpassen der eigenen Geräte hat, die er ja dann auch supporten muss

dürfte wohl dazu führen, dass die meisten Hersteller sich da vermutlich nicht besonders bewegen werden.

Kommt nämlich das nächste Update des Endgeräte-Herstellers und der “Standard” wird plötzlich erweitert, funktioniert möglicherweise etwas nicht mehr, was vorher prima geklappt hat. Den Support dafür muss dann der Anlagenhersteller leisten - und sei es in der Form, die zahlreichen Anfragen damit zu beantworten, dass es keine Unterstüng gibt und man sich doch an den Hersteller des Endgerätes wenden soll.

Und alle berufen sich auf den Standard, nur dass der eine lediglich alle “Pflicht-Optionen” implementiert (Minimalstandard) und ein anderer auch alle “Kann-Optionen” des Standards unterstützt. Und beide haben recht, wenn sie sagen “Wir halten uns an den Standard”.

Fazit: Für mich bleibt das ein verständlicher Wunsch aus Kundensicht, aus Hersteller- und Techniker-Sicht kann ich aber auch verstehen, wenn man sich der Sache verschließt.

11

Hallo noses,

Endlich mal jemand, der „Standard“ und „Feature“ auseinanderhält. Gerade was die bei Auerswald implementierten SIP-Features angeht, muss ich sagen, dass die sich da recht genau an den Standard-RFC halten. Zumindest habe ich damit bei den von mir verwalteten Gerätezoos auf SIP-Ebene recht wenig Probleme.

Gruß Dauerbesetzt

12

[quote=Dauerbesetzt]Hallo noses,

Endlich mal jemand, der “Standard” und “Feature” auseinanderhält. Gerade was die bei Auerswald implementierten SIP-Features angeht, muss ich sagen, dass die sich da recht genau an den Standard-RFC halten. Zumindest habe ich damit bei den von mir verwalteten Gerätezoos auf SIP-Ebene recht wenig Probleme.

Gruß Dauerbesetzt[/quote]
An sich kann ich das bestätigen, bis jetzt habe ich noch nicht wirklich SIP Geräte (Hard- und Software) gefunden die mit unserer Auerswald Anlage nicht kommunizieren wollte. Nummern wählen, und sprechen geht eigentlich immer.

Nur obwohl wir BLF nicht wirklich viel einsetzen, warum benutzt Auerswald hier etwas eigenes und nicht SIP?

Oder noch besser, warum redet ein COMfortel 3500 mit Auerswald Anlagen nicht per SIP sondern per was auch immer?
Man muß dazu sagen auch bei den richtig großen hat es gedauert bis sie eingesehen haben das offene Standards gut sind. Früher haben die Cisco VoIP telefone z.B. auch viel über irgendwelche “komischen” Protokolle geregelt, heute funktioniert SIP, und was SIP nicht kann wird öffentlich dokumentiert und als SIP Erweiterung implementiert. Die dann durchaus auch andere Hersteller verwenden können.

Gruß,

Christian

13

Sollte dem so sein, wäre es vielleicht ganz gut die Qualifikation besser zu gewährleisten, wobei es keine Schande sein dürfte, dass nicht jedem Fachhändler die Konfiguration jedes der vielen Features sofort geläufig ist, was man ja aber auch nachlesen kann :wink:

Diesbezüglich gibt es denke ich unstrittig leider doch einigen Nachholbedarf und Verbesserungspotential :rolleyes:

[quote=noses]
Kommt nämlich das nächste Update des Endgeräte-Herstellers und der „Standard“ wird plötzlich erweitert, funktioniert möglicherweise etwas nicht mehr, was vorher prima geklappt hat. Den Support dafür muss dann der Anlagenhersteller leisten - und sei es in der Form, die zahlreichen Anfragen damit zu beantworten, dass es keine Unterstüng gibt und man sich doch an den Hersteller des Endgerätes wenden soll.

Und alle berufen sich auf den Standard, nur dass der eine lediglich alle „Pflicht-Optionen“ implementiert (Minimalstandard) und ein anderer auch alle „Kann-Optionen“ des Standards unterstützt. Und beide haben recht, wenn sie sagen „Wir halten uns an den Standard“.

Fazit: Für mich bleibt das ein verständlicher Wunsch aus Kundensicht, aus Hersteller- und Techniker-Sicht kann ich aber auch verstehen, wenn man sich der Sache verschließt.[/quote]

Ja und nein - wenn ein Endgerätehersteller (Fremdmarke) etwas ändert hat das nichts mit der Änderung des Standards zu tun.
Würden sich alle tatsächlich an Standards halten und auch den Ausgabestand des Standards mit aufführen dürfte es keine Probleme geben und natürlich ist ein Tk-Anlagen-Hersteller in der Pflicht sich an den in der Produktbeschreibung aufgeführten Standard zu halten und dessen Funktionalität auch zu supporten.
Will man das nicht, werden sich Hersteller anderer Technologien freuen.

Wird ganz offiziell ein Standard geändert oder erweitert kann und sollte ein Tk-Anlagen-Hersteller mitziehen muss das aber zumindest bei älteren Produkten nicht.
Wenn er es tut, muss er sein Produkt wie auch immer auch supporten.

So wie es aussieht wird sehr wohl „Standard“ und „Features“ vermischt.

14

[quote=baltic]An sich kann ich das bestätigen, bis jetzt habe ich noch nicht wirklich SIP Geräte (Hard- und Software) gefunden die mit unserer Auerswald Anlage nicht kommunizieren wollte. Nummern wählen, und sprechen geht eigentlich immer.

Nur obwohl wir BLF nicht wirklich viel einsetzen, warum benutzt Auerswald hier etwas eigenes und nicht SIP?

Oder noch besser, warum redet ein COMfortel 3500 mit Auerswald Anlagen nicht per SIP sondern per was auch immer?
Man muß dazu sagen auch bei den richtig großen hat es gedauert bis sie eingesehen haben das offene Standards gut sind. Früher haben die Cisco VoIP telefone z.B. auch viel über irgendwelche “komischen” Protokolle geregelt, heute funktioniert SIP, und was SIP nicht kann wird öffentlich dokumentiert und als SIP Erweiterung implementiert. Die dann durchaus auch andere Hersteller verwenden können.

Gruß,

Christian[/quote]

Warum spricht Skype kein SIP :rolleyes:

Wie schon erwähnt will man sich sicher noch einige Features für die eigenen Systemgeräte vorbehalten, was ich nachvollziehen kann, jedoch ist das seitdem es offene Systeme gibt schon eine Gratwanderung, d.h. man sollte entsprechende Anreize schaffen, die sicher nicht aus Preiserhöhungen und Reduzierungen des Funktionsumfanges bestehen können.

15

Skype spricht durchaus SIP, kostet zwar etwas extra im Monat aber funktioniert recht gut - auch mit Auerswald Anlagen.
[SIZE=1](Skype hat aber genug andere Probleme über die wir hier lieber nicht reden)[/SIZE]

Nun, wäre zwar nicht schön, aber im Prinzip spricht ja nichts dagegen für SIP etwas mehr zu nehmen, wäre auch nicht der erste Hersteller um mal wieder Cisco zu nennen, bei denen hat zumindest früher die SIP Software für die Telefone etwas mehr gekostet als der Cisco eigene Kram.

Das mit den Features für eigene Systemgeräte ist so eine Sache, Firmen die noch aktuelle Telefone haben und nur eine neue Anlage brauchen würden dadurch z.B. eher abgeschreckt zu Auerswald zu wechseln. Kunden die noch Systemtelefone haben hingegen werden dann vielleicht nicht so schnell den Anbieter wechseln wenn sie eine neue Anlage benötigen.
Das kann man in beide Richtungen drehen.

Wie dem auch sei, ich hoffe doch sehr das Auerswald in Zukunft eher mehr als weniger Standards unterstützen wird, auch für ausgefallene Funktionen wir BFLs. (Gibt es für BFLs überhaupt einen SIP Standard?)

Christian

16

[quote=baltic]Skype spricht durchaus SIP, kostet zwar etwas extra im Monat aber funktioniert recht gut - auch mit Auerswald Anlagen.
[SIZE=1](Skype hat aber genug andere Probleme über die wir hier lieber nicht reden)[/SIZE]
[/quote]

Da sind wir doch beim Punkt, nur eben von der anderen Seite aus betrachtet.

Es handelt sich dabei nicht mehr um das eigentliche Skype sondern um Skype-Connect und ist im Prinzip eine Online-Tk-Anlage (Cloud) wie diese von vielen anderen Anbietern auch angeboten werden (z.B. SipGate).

Es handelt sich dabei nicht um die Anbindung einer Tk-Anlage an einen Provider, sondern eher um den Zugriff auf eine virtuelle Tk-Anlage über einen SIP-Client der auch eine Tk-Anlage sein kann, d.h. hier werden Anreize geschaffen ganz zu einer virtuellen Tk-Anlage zu wechseln.
Wenn so etwas, dann aber z.B. besser SipGate-Team, denn dort gibt es weniger Tarif-Fußangeln und es können z.B. auch Handies als Nebenstelle integriert werden.

Außerdem sind bei SipGate-Team anders als bei Skype-Connect netzinterne Telefonate kostenfrei.
Bei Skype-Connect sind nur ankommende Anrufe frei.

Solche Lösungen kosten meiner Ansicht nach nicht “etwas extra” sondern im Vergleich zu einem Festnetzanschluß mit Festnetzflat richtig Geld, hinzu kommt, dass man zuzätzlich einen Internetzugang benötigt, dessen Kosten umzulegen wären.

Vergleicht man nun Skype-Connect mit SipGate-Team liegen die mtl. Grundgebühren in etwa gleich, wobei man bei Skype-Connect je Kanal zu bezahlen hat und bei SipGate-Team je Client in Paketen (min. 3 Clients).

Bei Skype-Connect sollte man zumindest bei Telefonaten in die USA darauf achten, dass Anrufe an Teilnehmer einer ganzen Reihe von Providern nicht in den Minutenpaketen enthalten sind.

Auffällig ist bei Skype-Connect und bei SipGate-Team, dass Auerswald (die Nr. 1 in DE) nicht auf deren Listen mit SIP-fähigen, getesteten Tk-Anlagen auftaucht, was wohl daran liegen könnte, dass man dafür Geld haben möchte, womit wir wieder bei dem Punkt sind, dass kein Anbieter von welchem System auch immer kostenfrei Schnittstellen zu anderen (Konkurenz-) System öffnen möchte.

Dazu gibt es auch in der IT-Welt haufenweise Beispiele, wobei ich nur daran denke dass MicroSoft untersagt wurde den InternetExplorer gleich mit installieren zu lassen. Nun hat man zwar die Möglichkeit der Auswahl, allerdings macht man es den Usern durchaus schwer vom Suchanbieter “Bing” zu “Google” zu wechseln.

17

[quote=baltic](Gibt es für BFLs überhaupt einen SIP Standard?)[/quote]Ja, ich denke schon, das ist in u.a. in RFC 3265 und 4235 spezifiziert.

18

Wenn du es sagst, wobei wir Skype nur für eine Festnetz Nummer in Schweden benutzen, kriegen wir haben durchaus auch schon andere Provider Versucht, aber die Sprachqualität ist bei der Skypenummer doch um einiges besser als wir es in der Vergangenheit hatten.
Ich schau mir nächste Woche mal SipGate an, wenn die auch Festnetznummern in Schweden anbieten könnte man sich einen Wechsel durchaus überlegen.

Christian

19

[quote=baltic]Wenn du es sagst, wobei wir Skype nur für eine Festnetz Nummer in Schweden benutzen, kriegen wir haben durchaus auch schon andere Provider Versucht, aber die Sprachqualität ist bei der Skypenummer doch um einiges besser als wir es in der Vergangenheit hatten.
Ich schau mir nächste Woche mal SipGate an, wenn die auch Festnetznummern in Schweden anbieten könnte man sich einen Wechsel durchaus überlegen.

Christian[/quote]

Schwedische Festnetznummern von SipGate gibts, kosten allerdings je Nummer einmalig + monatlich € 12,90.

Die Sprachqualität empfinde ich deutlich besser als mit Skype, wobei ich das “normale” Skype und SipGate Basic vergleiche und ich es mit 2 SipGate-Accounts für Verbindungen zwischen Deutschland und Asien verwende.

20

Ja, das stimmt, allerdings ist RFC 4235 eine SIP-Erweiterung genannt „Dialog Event Package“.

Weder steht in der Spezifikation der Auerswald VoIP-Schnittstellen etwas von RFC 3265 noch von RFC 4235 sondern RFC 3261.

Was es mit RFC 3261 auf sich hat, kann man z.B. hier http://tools.ietf.org/html/rfc3261 lesen.

Infos über Spezifikationen zum BLF gibts u.a. hier http://track.sipfoundry.org/secure/attachment/17474/BW-BusyLampFieldInterfaceSpec-R150.pdf

Sollte RFC 3261 das BLF nicht explizit unterstützen, hat ein Produkt, welches sich gemäß Gerätespezifikation an RFC 3261 hält dieses BLF auch nicht zu unterstützen.
Sollte die RFC 3261 jedoch das BLF unterstützen und in der Gerätespezifikation kein Ausschluß des BLF dokumentiert sein, hat das Endgerät BLF nach RFC 3261 zu unterstützen. Sollte dem nicht so sein würde das einen Mangel darstellen.

Bei der Auerswald-VoIP-Schnittstelle ist RFC 3261 ohne Ausschlüsse aufgeführt und genau das gilt es somit einzuhalten - nicht mehr und nicht weniger.

In o.g. Abhandlung über RFC 3261 konnte ich zum BLF das hier finden :

„[SIZE=2]The ability to support Busy Lamp Field (BLF) is one of the building blocks for the Attendant Console application. Although SIP ([/SIZE][FONT=Arial,Arial][SIZE=2][FONT=Arial,Arial][SIZE=2]RFC 3261[/SIZE][/FONT][/SIZE][/FONT][SIZE=2]) by itself offers no inherent semantics for supporting Busy Lamp Field, when coupled with the appropriate instantiation and the appropriate extension of the „SIP Specific Event Notification“ framework ([/SIZE][FONT=Arial,Arial][SIZE=2][FONT=Arial,Arial][SIZE=2]RFC 3265[/SIZE][/FONT][/SIZE][/FONT][SIZE=2]), the Busy Lamp Field feature can be deployed quite easily in a distributed network.“[/SIZE]

[SIZE=2]Demnach [/SIZE]unterstützt RFC 3261 selbst BLF also gar nicht, sondern nur mit der Erweiterung nach
RFC 3265, womit es von z.B. Auerswald auch nicht geschuldet wäre und man das BLF bereitstellen kann wie man möchte, sofern es mit den zugehörigen Systemtelefonen bei denen BLF als Feature aufgeführt ist, funktioniert.

Verwendet man nun also ein Fremd-VoIP-Telefon das nach RFC 3265 + RFC 4235 arbeitet an einer Anlage die SIP (VoIP) nur nach RFC 3261 realisiert oder umgekehrt, dürften Grundfunktionen wahrscheinlich zwar funktionieren, alles andere steht aber in den Sternen, d.h. bei der Fremdgeräte-Auswahl wäre zunächst einmal auf übereinstimmende Standards zu achten.

Genau das ist beim oben aufgeführten „Snom 760IP“ der Fall, denn dieses Telefon arbeitet nach
RFC 3265 und bez. dem BLF nach RFC 4235, Auerswald nach laut Dokumentation nach RFC 3261 ohne jegliche Erweiterung für das BLF nach einem RFC-Standard.

Hier http://www.cisco.com/asiapac/ipc/files/22feb/joe_sip_strat.pdf eine Übersicht zu SIP-Standards von Cisco.
Hier [color=#810081]http://www.packetizer.com/ipmc/sip/standards.html[/color] eine Übersicht der SIP-Standards mit Links zu den jeweiligen Dokumenten.

Ungeschickt ist leider, dass man sich nicht auf einen Standard einigt, was mich an ISDN 1TR-6 und DSS1 denken läßt - beides war bzw. ist ISDN so wie RFC 3261 und 3265 beides SIP (VoIP) ist.

Wie ich zwischenzeitlich recherchiert habe gibt es auch mit softwarebasierten Systemen wie Asterisk durchaus Probleme mit dem BLF, d.h. es sind nicht nur hardwarebasierte Tk-Anlagen und schon gar nicht nur Auerswald davon betroffen.

Fazit :

Augen auf beim Anlagen- und Endgerätekauf, denn es geht ganz offensichtlich nicht darum dass das Objekt der Begierde nach „dem“ SIP-Standard arbeitet sondern darum nach welchem und ggf. welche Erweiterungen implementiert sind :wink: