MWI funktioniert nicht trotz FW 9.24 ...!?!

[cpuprofi]

Hallo an Alle,

MWI funktioniert trotz FW 9.24.0099 nicht. Getestet mit SNOM 370, M700, M300 und Gigaset N510IP Pro.

Wo könnte da was falsch sein? Einstellen für MWI kann ich ja nichts...

Grüße
Cpuprofi

[Koppelfeld]

MWI funktioniert trotz FW 9.24.0099 nicht. Getestet mit SNOM 370, M700, M300 und Gigaset N510IP Pro.
Wo könnte da was falsch sein?

Mailbox-Server nicht eingestellt?
Und laß' mich raten: Telekom-Plattform?
Du glaubst doch nicht, daß da ein standardisiertes Verfahren implementiert ist?
Aber dann glaubst Du sicher auch, daß es dieses Jahr noch ein Geschäftskunden-Telekomprodukt gibt...

[cpuprofi]

Hallo Koppelfeld,

...Mailbox-Server nicht eingestellt?...

MWI wird doch über ein OPTIONS Paket übermittelt...

...Und laß' mich raten: Telekom-Plattform?...

Nöö... Dus.net

Grüße
Cpuprofi

[Koppelfeld]

MWI wird doch über ein OPTIONS Paket übermittelt...

Subscription wie bei BLF.
Macht das Telephon standardmäßig gegen den 1. registrierten SIP - Server.

Nun funktioniert der Lancom ein bißchen wie ein SBC, er müßte sich wohl seinerseits gegen den SIP - Provider registrieren.

[MoinMoin]

Moin, moin!

Dus.Net sollte funktionieren. Mit unserem Account zumindest hat es funktioniert. Siehst du im SIP-Packet-Trace die Subscribe-Pakete des Telefons?

Ciao, Georg

[cpuprofi]

Hallo Georg,

Siehst du im SIP-Packet-Trace die Subscribe-Pakete des Telefons?

ja die sind da, siehe:

Code: Alles auswählen

[SIP-Packet] 2016/09/15 23:44:19,965  Devicetime: 2016/09/15 23:44:20,250 [PACKET] : 
Receiving datagram with length 686 from 192.168.100.32:5064 to 192.168.100.1:5060 using UDP
SUBSCRIBE sip:00038711111@intern;user=phone SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.100.32:5064;branch=z9hG4bK25vs7yp4nyn7.p.8l3kvjtq8bv7\r\n
Max-Forwards: 70\r\n
From: <sip:11@intern>;tag=.1d3n.kz6\r\n
To: <sip:00038711111@intern;user=phone>\r\n
Call-ID: ib7jls9d191szrtw1ff@intern\r\n
CSeq: 222 SUBSCRIBE\r\n
Contact: <sip:11@192.168.100.32:5064;line=16020>\r\n
Accept: application/simple-message-summary\r\n
Allow: INVITE, CANCEL, BYE, ACK, REGISTER, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO, PRACK, UPDATE\r\n
Allow-Events: dialog,message-summary\r\n
Event: message-summary\r\n
Expires: 240\r\n
Supported: replaces,100rel\r\n
User-Agent: snomM700/03.55.0019 (MAC=000413610458; SER= 00000; HW=255)\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2016/09/15 23:44:20,168  Devicetime: 2016/09/15 23:44:20,251 [PACKET] : 
Sending datagram with length 453 from 192.168.100.1:5060 to 192.168.100.32:5064 using UDP
SIP/2.0 404 Not Found\r\n
Via: SIP/2.0/UDP 192.168.100.32:5064;branch=z9hG4bK25vs7yp4nyn7.p.8l3kvjtq8bv7\r\n
From: <sip:11@intern>;tag=.1d3n.kz6\r\n
To: <sip:00038711111@intern;user=phone>\r\n
Call-ID: ib7jls9d191szrtw1ff@intern\r\n
CSeq: 222 SUBSCRIBE\r\n
Expires: 240\r\n
User-Agent: LANCOM 1781VA (over ISDN) / 9.24.0099 / 05.09.2016\r\n
Server: Lancom1781VA\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Content-Length: 0\r\n
\r\n

Nur, dass der Lancom damit anscheinend nichts anfangen kann (404 Not Found)...

Grüße
Cpuprofi

[MoinMoin]

Moin Cpuprofi!

Wenn ich das richtig lese, kommt das Paket vom Snom und geht an das LANCOM. Das LANCOM lehnt das Subsribe ab.

Welche Nummer hat der SIP-User, hinter dem das Snom steckt? 11 oder 00038711111? Ich hätte erwartet, daß das Snom im Request sowie From und To dieselbe Nummer einträgt.

Ciao, Georg

[cpuprofi]

Hallo Georg,

Welche Nummer hat der SIP-User, hinter dem das Snom steckt? 11 oder 00038711111?

der SIP-User hat die Lancom interne Nummer 11.

00038711111 ist die Dus.net interne Mailbox-Nummer.

Grüße
Cpuprofi

[Koppelfeld]

Moinsen !

der SIP-User hat die Lancom interne Nummer 11.
00038711111 ist die Dus.net interne Mailbox-Nummer.

Was mich da interessieren würde:
Wie will der Lancom eigentlich die interne Nummer mit dem SIP-Account korrelieren ?

Ich wäre ja normalerweise einer Meinung mit Georg, beim 'subscribe' from=to=11@intern.
Aber an wen soll der LANCOM weitergeben ? Er könnte jetzt Heuristiken aus der Routing-Tabelle ableiten, das wäre aber schon sehr Äppel-like.
Also: Du mußt wohl oder übel im "Snom" eine abweichende Subscription-Adresse für die Mailbox einrichten, und die kann der LANCOM auch weiterleiten.
EDIT:
Bullshit. Ich war zu blöd, die richtige Firmware auf dem Proberouter zu installieren.
Mit der 9.24 kann, für jeden SIP-Client, ein Mailbox-URI für die weiterzuleitende Subscription eingegeben werden.

Jetzt muß das SNOM des SUBSCRIBE nur noch gegen den LANCOM vornehmen - and you're covered.

Wenn es mit dem "Snom" nicht geht, nimm' halt ein ordentliches Telephon.

[cpuprofi]

Hallo Georg,

ich habe jetzt mit Koppelfeld die MWI Problematik durchdiskutiert und kam dann auf den Trichter, dass man bei dem SNOM Telefon als "Mailboxnummer" die interne Nummer des SIP-Users setzen muss, damit MWI auf dem Telefon signalisiert wird.

Soweit so gut, nur dass das SNOM Telefon dann keine Mailboxabfragen mehr durch drücken der "Mailbox-Taste macht...

Auch vom "MWI Mailbox Info Menü" war die Abfrage nicht möglich, aber egal, ich habe weiter herumexperimentiert und festgestellt, dass wenn man einen Eintrag in der Call-Routen-Tabelle erstellt, der die Wahl von "*01" dann der entsprechenden externen Mailboxnummer und der entsprechenden ausgehenden Leitung zuordnet, es geht (aber nur wenn neue Nachrichten auf der Mailbox sind, ansonsten wird nur die interne SIP-User Nummer gewählt, was logischerweise dann einen Fehler hervorruft).

Es kann auch möglich sein, dass diese Problematik vielleicht mit meiner "nicht ganz einfachen Call-Routen-Tabelle" und "*#" für interne Anrufe zusammen hängt...


Auch ist mir noch aufgefallen, dass bei "LINK"-Leitungen die MWI Anzeige nicht funktioniert.

Der VCM sendet dazu folgende Email:

Source IP : 83.125.8.68
Expected Source IP : 83.125.8.71
Line Name : DUSNET
Port : 14700


Weiter kann man unter -> VCM -> Benutzer -> DECT-Handsets -> Voice-Mailbox kein "*" eintragen, z.B. für "*01"...


Nun gehe ich ins Bett, gute Nacht.

Grüße
Cpuprofi

[Koppelfeld]

Moin!

Hallo Georg,
ich habe jetzt mit Koppelfeld die MWI Problematik durchdiskutiert

Was heißt hier "durchdiskutiert"?
Wir sind doch nicht bei den Grünen oder im Feministenclub.
Wir haben das gelöst.
MWI klappt hervorragend, der VCM arbeitet quasi als Relay.
Telephon macht den MWI-Subscribe gegen den VCM, dieser wiederum gegen den Provideraccount, welcher beim SIP - User auf dem Lancom hinterlegt ist.

Soweit so gut, nur dass das SNOM Telefon dann keine Mailboxabfragen mehr durch drücken der "Mailbox-Taste macht...

MWI-Subscription und Mailboxabfrage haben nix miteinander zu tun. Mailboxabfrage heißt: "Wähle eine ganz bestimmte Nummer, typischerweise irgendein Präfix, gefolgt von der internen Teilnehmerrufnummer".
Diese Sequenz sollte man in jedem vernünftigen Telephon hinterlegen können. Aber Du hast ja "Snom" genommen.
Und in der Tat, es sieht so aus, als hätten die zwei völlig unterschiedliche Dinge miteinander verknüpft.

Es sollte aber gelingen, in der schimmeligen "XML" - Konfig einen entsprechenden Parameter zu finden und dann das Telephon passend zu konfigurieren, sodaß es bei Drücken der Mailbox-Taste (bei NSt 11) zum Beispiel die *9911 wählt.
Die fischst Du im Call-Router ab und lenkst sie auf die "echte" Mailboxnummer.

Umständlich, zugegeben.
Aber Du hast die Chance, die Snom - Havaristen vom öffentlichen Netz fernzuhalten. Wenn man das unterläßt, dann erlebt man lustige Sachen, sieh' 'mal bei User "John Lose" nach.
Was habe ich gelacht.

Außerdem bekommst Du es mit einer einzigen Zeile hin, wenn:
Ja, wenn der VCM mit einem SIP - Trunk kann, beispielsweise mit SIPConnect 1.1.
Das Fummeln mit Einzelaccounts bei mehr als 5 Teilnehmern ist lästig.

Ceterum Censeo:
VCM, Starface, Telekom-SIP und Snom versprechen schnelle Lösungen, die jeder beherrscht. Erst nach der Grundeinrichtung fällt dann auf, was alles nicht geht.
Dummerweise fällt es dem Endkunden auf.
Wobei der VCM noch ehrlich ist und sagt, "ich bin keine TK-Anlage".

Ich finde den VCM toll für einen Privathaushalt oder zum "Umformen" eines verquasten "All-IP-Accounts", aber schon in einer kleinen Steuerberatungskanzlei reicht es nicht.

Schöne Grüße aus dem Zug nach Berlin *würg*

[cpuprofi]

Hallo an Alle,

...Wir haben das gelöst...

na ja, als "gelöst" würde ich die Problematik mit dem MWI nicht sehen, denn dann sollten ja alle "am Markt erhältlichen SIP-Telefone" und alle "auf dem Markt befindlichen SIP-Anbieter" damit abzuarbeiten sein...

Wir hatten mit viel gefummel einen Workaround gebastelt der jetzt zumindest für das SNOM 370 (teilweise) funktioniert.

Schöner wäre es aber, wenn man im Lancom VCM die Mailbox-Nummer des SIP-Providers hinterlegen könnte und darauf dann MWI gemacht würde, ok ist wahrscheinlich schwer zu programmieren. Im SIP-Telefon würde man dann auch die Mailbox-Nummer des SIP-Providers hinterlegen (der Lancom benutzt ja die gleiche), damit wären dann auch die Probleme wie mit dem SNOM 370 (wobei ich mir immer noch nicht sicher bin, dass da SNOM etwas falsch macht) gelöst. Der Lancom VCM müsste dann nur (wenn die Mailbox-Nummer des SIP-Providers gerufen wird) selbständig erkennen, von welchem SIP-User dieses erfolgt und dann die "richtige" SIP-Leitung für diesen Ruf wählen (habe ich i.M. ja über die Call-Routen-Tabelle gelöst). Aber der "Ansatz" dazu ist ja schon im VCM ab FW 9.24 enthalten.

Problematisch kann jetzt aber dabei sein, dass manche SIP-Providers eine Sequenz wie "*01" oder eine "SIP-URI" zur Mailbox-Abfrage nutzen...

Grüße
Cpuprofi

[Koppelfeld]

na ja, als "gelöst" würde ich die Problematik mit dem MWI nicht sehen,

Du wolltest MWI, Du hast MWI.
Anything wrong with the service?

denn dann sollten ja alle "am Markt erhältlichen SIP-Telefone" und alle "auf dem Markt befindlichen SIP-Anbieter" damit abzuarbeiten sein...

Nein, das genaue Gegenteil ist der Fall.
"Wenn zwei Größen einer dritten gleich sind, dann sind sie auch untereinander gleich". Das ist der jedem Standard zugrundeliegende Gedanke. Jeder hält sich an Standards und alles paßt.
Es ist ausgesprochen kontraproduktiv, Schwachsinn wie Telekom-Sonder-SIP oder ähnliches Geäffe zu unterstützen:
Die Produkte werden komplizierter und teurer, die Auswahl für den Endverbraucher sinkt, die Abhängigkeit steigt.

Der nächste kommt und will das verschwiemelte "OpenStage" unterstützt sehen, natürlich mit HFA, und der übernächste will womöglich sein scheußliches "Gigaset" mit Wetter- "Facebook"- und "Whatsapp" - Proxy implementiert sehen.
Ich habe ja einmal den Herrn Ohn erleben dürfen, ich dachte so bei mir, ich wäre bei "Thomas Gottschalk", aber einen klaren, wahren Satz hat er 'rüberbringen können: "Wer für alles offen ist, kann nicht ganz dicht sein".

Schöner wäre es aber, wenn man im Lancom VCM die Mailbox-Nummer des SIP-Providers hinterlegen könnte und darauf dann MWI gemacht würde, ok ist wahrscheinlich schwer zu programmieren.

Nein, wäre nicht schöner, weil Sonderlösung und damit nicht deduktiv erarbeitbar.

Die ganzen neuen Features haben uns einen Riesenwust an Ärger und Reputationsverlust beim Kunden eingebracht, wir sind ja beide gleichermaßen Leidtragende.
Was bin ich froh, daß mit der 9.24 Routing UND QoS funktionieren.

Und jetzt kommen alle möglichen Power-Luser aus ihren Ecken gekrochen und wollen IPhone - Design. Bin ich hier auf der "Gay Pride" oder was?

Für Dich nochmal extra Ockham's Razor:

Entia non sunt multiplicanda praeter necessitate.


Gruß Hans

[cpuprofi]

Hallo Hans,

Es ist ausgesprochen kontraproduktiv, Schwachsinn wie Telekom-Sonder-SIP oder ähnliches Geäffe zu unterstützen: Die Produkte werden komplizierter und teurer, die Auswahl für den Endverbraucher sinkt, die Abhängigkeit steigt.

die Telekom (auch wenn Du das nicht hören möchtest), ist nun mal in Deutschland "Marktbeherrschend" und somit "der Standart"...

Und auch an SIP-Telefon Anbietern gibt es nicht so viele die flächendeckend eingesetzt werden: GIGASET (Bgl. Bintec-Elmeg) , GRANDSTREAM, Mitel (AASTRA), POLYCOM, SNOM und YEALINK.

Im SIP-DECT Bereich: GIGASET (Bgl. Bintec-Elmeg, Lancom) , KIRK (Bgl: Auerswald, Bintec-Elmeg), Mitel (AASTRA), RTX (Bgl: AGFEO, SNOM) und YEALINK.

Das sind die großen Marktanbieter, die Anzahl ist sehr überschaubar. Deine "Panik" vor "ausufernden" Ergänzungswünschen ist somit nicht begründet.

Mit der jetzigen Implementierung von MWI funktioniert entweder MWI oder Mailboxabfrage, beides zugleich nur eingeschränkt und mit "Workaround" und dann auch nicht bei allen Geräten...

Ich denke, dass dieses auch besser zu lösen geht, einen Vorschlag dazu (indem der VCM dann einen Proxy/ALG für MWI und Mailboxabfragen darstellt) habe ich ja schon genannt.

Edit: Ich werde mir mal die Tage die verschiedenen Firmwaren für Gigaset, SNOM und YEALINK anschauen und dort überprüfen, wie weit MWI mit der Mailbox-Abfrage bei den unterschiedlichen Geräten und Firmwaren "verknüpft" ist, vielleicht kann man die Problematik auch durch Firmware-Updates bei den SIP-Telefonen "entschärfen". Ich werde dann darüber hier berichten.

Bedenke: "Simplex est non semper bonum!"

Grüße
Cpuprofi

[Koppelfeld]

die Telekom (auch wenn Du das nicht hören möchtest), ist nun mal in Deutschland "Marktbeherrschend" und somit "der Standart"...

So, so -- die Telekom ist bei SIP-Geschäftskunden marktbeherrschend ?

Und auch an SIP-Telefon Anbietern gibt es nicht so viele die flächendeckend eingesetzt werden: GIGASET (Bgl. Bintec-Elmeg) , GRANDSTREAM, Mitel (AASTRA), POLYCOM, SNOM und YEALINK.

Öh -- Nortel (Natürlich muß der VCM auch UNIstim können, unbedingt), Cisco, Avaya, Digium (IAX2 wäre auch schön). Siemens - wer will schon auf die chice "Optipoints" verzichten ?
Und die SOFTPHONES erst: Allein für Äppel gibt es 200 Stück, jedes mit anderen "Features", eins schräger als das andere ! NEC und Panasonic sollte man ergänzen.

Im SIP-DECT Bereich: GIGASET (Bgl. Bintec-Elmeg, Lancom) , KIRK (Bgl: Auerswald, Bintec-Elmeg), Mitel (AASTRA), RTX (Bgl: AGFEO, SNOM) und YEALINK.

Wenn Du mit "SIP-DECT" DECT-Systeme mit SIP-Interface meinst: Spectralink (in 3 Ausführungen), SIEMENS (in 3 Ausführungen), Avaya, Panasonic ...

Das sind die großen Marktanbieter, die Anzahl ist sehr überschaubar. Deine "Panik" vor "ausufernden" Ergänzungswünschen ist somit nicht begründet.

Ich habe keine Panik vor den Ergänzungswünschen, ich habe Panik angesichts der möglichen Folgen.

Ich denke, dass dieses auch besser zu lösen geht, einen Vorschlag dazu (indem der VCM dann einen Proxy/ALG für MWI und Mailboxabfragen darstellt) habe ich ja schon genannt.

Redest Du vom gleichen ALG, mit dem Du immer wieder ins Klo faßt ?
Wobei das Problem prinzipbedingt existiert und wenig mit der konkreten Implementierung zusammehängt: You beg for a miracle man, you get rotten miracles.

Bedenke: "Simplex est non semper bonum!"

Deshalb haben wir ja unser Steuersystem -- gerecht und einfach.