Hallo,
Hab hier einen 1711 mit Advanced VOIP Option. Ein SIP Provider ist eingetragen, Call-Routen hab ich für mich angepasst, Verbindungen ein und ausgehend kommen grundsätzlich mal zustande.
Es existiert momentan nur ein Client der sich am Lancom anmeldet - ein Siemens Schnurlostelefon hinter einem Sipura ATA (aktuelle Firmware). Gleich vorweg: Wenn ich mich mit dem Sipura DIREKT am SIP-Provider anmelde, habe ich nachfolgende Probleme nicht.
Bin heute erstmals dazugekommen, dieses Setup ein wenig durchzutesten. Was mir dabei auffällt: Wenn ich mit meinem Sip-Telefon mein Handy anrufe und dort nicht rangehe sondern nach ein paar mal läuten wieder auflege, läutet mein Handy dennoch weiter. und zwar endlos. Ich bemerke im Lanmonitor zwar die Nachricht "Normaler Verbindungsabbau", es klingelt aber dennoch weiter. Hebe ich ab, bin ich in einer 'toten' Leitung. Mit eingehenden Gesprächen ist es nicht unähnlich. Wenn die Gegenseite auflegt, ist mein Telefon dennoch der Meinung, dass die Leitung weiterhin steht. Erst wenn ich dann auflege, wird die Leitung offenbar wirklich dicht gemacht.
Kennt jemand dieses Problem?
Lancom 1711 führt Verbindungsabbau nicht durch
Moderator: Lancom-Systems Moderatoren
Lancom 1711 führt Verbindungsabbau nicht durch
Liebe Grüße,
michael
michael
.
-
Aeroschmelz
- Beiträge: 138
- Registriert: 01 Feb 2006, 16:53
Es handelt sich immer noch um eine 6.00. Alles was danach released wurde sind Release Updates, mit Bugfixes. Also ist es immer noch der erste Entwicklungs Stand. Der naechste Schritt kommt dann mit 6.10. Also hat Backslash hier recht.Wir sind mittlerweile bei 6.06 ?
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Naja ich bin da durchaus geduldig 
Bleibt halt in der Firma das "Fritzbox" gebastel (welches ich gern loshaben wollte und nicht zuletzt ist der 821 dort schon etwas "alt" *g*)
Bisher hat Lancom immer alles über kurz oder lang zuverlässig zum laufen gebracht, und man darf nicht vergessen, dass z.B. die FritzBox 7050 odre 5050 bei der Auslieferung perfekt war (die war eher ne schreckliche Katastrophe).
Bleibt halt in der Firma das "Fritzbox" gebastel (welches ich gern loshaben wollte und nicht zuletzt ist der 821 dort schon etwas "alt" *g*)
Bisher hat Lancom immer alles über kurz oder lang zuverlässig zum laufen gebracht, und man darf nicht vergessen, dass z.B. die FritzBox 7050 odre 5050 bei der Auslieferung perfekt war (die war eher ne schreckliche Katastrophe).
1x 1724, 1x 1722 , 1x 1511, 3x L54g, 1x L54ag Firmware auf allen Geräten 7.22
Hallo zusammen,
das mit den möglichen Fehlern bei der 1. Release ist ja OK. Für mich stellt sich einfach die Frage, wie ich verhindern kann, dass mir das LANCOM den SIP-Account leersaugt. In meinen eigenen beschriebenen Fall (http://www.lancom-forum.de/topic,2856,- ... t+auf.html) kann ich ja damit umgehen, nur muss ich dies demnächst aufgrund meiner Angebote auch bei Kunden realisieren. Und dann kriegen wir ein Problem. Daher die Frage, wie ich dieses unbeabsichtigte leersaugen abstellen kann - ggf. in Form eines Release-Updates. So ist mir die Kiste jedenfalls zu heiß![/url]
das mit den möglichen Fehlern bei der 1. Release ist ja OK. Für mich stellt sich einfach die Frage, wie ich verhindern kann, dass mir das LANCOM den SIP-Account leersaugt. In meinen eigenen beschriebenen Fall (http://www.lancom-forum.de/topic,2856,- ... t+auf.html) kann ich ja damit umgehen, nur muss ich dies demnächst aufgrund meiner Angebote auch bei Kunden realisieren. Und dann kriegen wir ein Problem. Daher die Frage, wie ich dieses unbeabsichtigte leersaugen abstellen kann - ggf. in Form eines Release-Updates. So ist mir die Kiste jedenfalls zu heiß![/url]
Gruß
SIN
______________________________________________________________________
Unterwegs mit LANCOM 1722 VoIP - LCOS 8.5 (Annex B)
SIN
______________________________________________________________________
Unterwegs mit LANCOM 1722 VoIP - LCOS 8.5 (Annex B)
Das Problem ist, dass dieses Verhalten nicht reproduzierbar ist.
Im Moment schaffe ich es z.B. nicht das weiterklingeln des Handys nach Auflegen vom Festnetz zu provozieren.
Im Moment schaffe ich es z.B. nicht das weiterklingeln des Handys nach Auflegen vom Festnetz zu provozieren.
Gruß
SIN
______________________________________________________________________
Unterwegs mit LANCOM 1722 VoIP - LCOS 8.5 (Annex B)
SIN
______________________________________________________________________
Unterwegs mit LANCOM 1722 VoIP - LCOS 8.5 (Annex B)
Also ich hab dieses Verhalten nachvollziehbar jedes Mal. Bei mir ist wie gesagt kein ISDN involviert, nur ein ausgehender SIP Account. Ich hab jetzt meine Versuche wieder aufgegeben. Da mein SIP Account post-paid ist, könnte das ganze Gebührenmäßig ein Fass ohne Boden werden und ich würde es erst bei der nächsten Abrechnung merken
Liebe Grüße,
michael
michael
Moin!
Ich habe mal ein bischen mit Sipgate herumprobiert. Ich konnte das Verhalten nicht reproduzieren. Dabei ist mir aber folgendes aufgefallen:
Der Verbindungsabbau läuft bei Sipgate nicht richtig durch. Normal wäre:
Lancom <--> Sipgate
INVITE -->
100 Trying <--
180 Ringing <--
CANCEL -->
200 Ok (CANCEL) <--
487 Req. cancelled (INVITE) <--
ACK -->
Aus irgendwelchen Gründen erkennt der Sipgate Server das letzte ACK nicht und sendet immer wieder 487 (req. cancelled). Warum das so ist, kann ich nicht sagen. Andere Provider "kapieren" das. Wie verläuft denn der Verbindungsabbau bei direkt angemeldeten SIP-Telefon. Vielleicht kann man Unterschiede im letzten ACK-Paket sehen!? Gibt es überhaupt eine Antwort auf das CANCEL?
Gruß,
SEB
Ich habe mal ein bischen mit Sipgate herumprobiert. Ich konnte das Verhalten nicht reproduzieren. Dabei ist mir aber folgendes aufgefallen:
Der Verbindungsabbau läuft bei Sipgate nicht richtig durch. Normal wäre:
Lancom <--> Sipgate
INVITE -->
100 Trying <--
180 Ringing <--
CANCEL -->
200 Ok (CANCEL) <--
487 Req. cancelled (INVITE) <--
ACK -->
Aus irgendwelchen Gründen erkennt der Sipgate Server das letzte ACK nicht und sendet immer wieder 487 (req. cancelled). Warum das so ist, kann ich nicht sagen. Andere Provider "kapieren" das. Wie verläuft denn der Verbindungsabbau bei direkt angemeldeten SIP-Telefon. Vielleicht kann man Unterschiede im letzten ACK-Paket sehen!? Gibt es überhaupt eine Antwort auf das CANCEL?
Gruß,
SEB
Hallo,
[Problem besteht nach wie vor]
Ich hab mir das gerade angesehen und dabei festgestellt, dass mein Telefon offenbar in so einer Situation kein CANCEL schickt, sondern ein BYE. Könnte es damit was zu tun haben?
Zudem fallen mir immer wieder Meldungen wie folgt vom SIP-Proxy meines Providers auf:
Warning: 392 IP-ADRESSE-SIP-PROXY:5060 "Noisy feedback tells: pid=18088 req_src_ip=MEINE_IP_ADRESSE req_src_port=45121 in_uri=sip:SIP_SERVER_HOSTNAME out_uri=SIP_SERVER_HOSTNAME via_cnt==1"
[Problem besteht nach wie vor]
Ich hab mir das gerade angesehen und dabei festgestellt, dass mein Telefon offenbar in so einer Situation kein CANCEL schickt, sondern ein BYE. Könnte es damit was zu tun haben?
Zudem fallen mir immer wieder Meldungen wie folgt vom SIP-Proxy meines Providers auf:
Warning: 392 IP-ADRESSE-SIP-PROXY:5060 "Noisy feedback tells: pid=18088 req_src_ip=MEINE_IP_ADRESSE req_src_port=45121 in_uri=sip:SIP_SERVER_HOSTNAME out_uri=SIP_SERVER_HOSTNAME via_cnt==1"
Liebe Grüße,
michael
michael
nachdem ich nun einige gespräche per trace und im Monitor beobachtet habe, glaube ich auf der richtige Spur zu sein. Der Lancom zeigt mir ein 'Verbunden' an, obwohl es noch immer klingelt. Darum schickt er auch ein BYE und kein CANCEL beim auflegen - weil er der Meinung ist, ja bereits verbunden zu sein - ein folgenschwerer Umstand...
Bei internen Gesprächen (Linksys Telefon auf Snome) habe ich dieses Problem nicht. Hier steht der Status schön brav auf "Klingeln".
Hat jemand eine Idee, wie es zu diesem Effekt kommen könnte (ich meine, bevor ich meine Provider anhuste)?
Bei internen Gesprächen (Linksys Telefon auf Snome) habe ich dieses Problem nicht. Hier steht der Status schön brav auf "Klingeln".
Hat jemand eine Idee, wie es zu diesem Effekt kommen könnte (ich meine, bevor ich meine Provider anhuste)?
Liebe Grüße,
michael
michael
so - nun hab ich mir einen account von einem anderen VOIP anbieter ausgeborgt und mit diesem tritt das Verhalten nicht auf. Hier bleibt der Status auf "Klingeln", wie es sich gehört. Werde das mal mit meinem Provier klären müssen.
bei genauerer Betrachtung meines eben angefertigten trace fällt mir auf, dass mein VOIP-Anbieter überhaupt *nie* ein 'RINGING' sendet... Er sendet aber sehr wohl ein "TRYING...".
Auch wenn dieses Verhalten wohl nicht Standardkonform ist und die Schuld hier wohl nicht bei Lancom liegt, würde es mich dennoch interessieren, warum dieses Verhalten nicht auftritt, wenn ich mich mit diesem Account DIREKT beim SIP-Proxy des Providers anmelde (also selbe Hardware - ohne Lancom dazwischen). Weil wenn ich dann mein Handy anrufen, noch abhebe und auflege, dann läutet es eben nicht weiter...
Nachtrag 15:55 Uhr:
Habe mich eben mal testweise mit dem Snom-Softphone DIREKT bei dem problematischen VOIP-Provider angemeldet (weil man hier ebenfalls das SIP-Protokoll so schön einsehen kann). Hier tritt das Problem ebenfalls nicht auf... Wenn ich hier mein Handy anrufe und auflege, bevor jemand abhebt, dann schickt das Snom genauso ein BYE (wo ich ursprünglich dachte, hier muss der Fehler liegen), aber mit dem Unterschied, dass es eine Erfolgsmeldung (200 OK) zurückbekommt und mein Handy zu klingeln aufhört. Im Gegensatz zum Lancom, der in dieser Situation sein "BYE" immer und immer wieder schickt, ohne eine Erfolgsmeldung zu bekommen, sodass mein Handy eben nicht aufhört zu klingeln.
Kann mir das absolut nicht erklären. Ich hab aber sowohl den SIP-Trace vom Lancom als auch das Protokoll vom Snom jeweils mitgeschnitten und abgespeichert, falls es jemanden interessiert, kann ich diese per PM zukommen lassen.
bei genauerer Betrachtung meines eben angefertigten trace fällt mir auf, dass mein VOIP-Anbieter überhaupt *nie* ein 'RINGING' sendet... Er sendet aber sehr wohl ein "TRYING...".
Auch wenn dieses Verhalten wohl nicht Standardkonform ist und die Schuld hier wohl nicht bei Lancom liegt, würde es mich dennoch interessieren, warum dieses Verhalten nicht auftritt, wenn ich mich mit diesem Account DIREKT beim SIP-Proxy des Providers anmelde (also selbe Hardware - ohne Lancom dazwischen). Weil wenn ich dann mein Handy anrufen, noch abhebe und auflege, dann läutet es eben nicht weiter...
Nachtrag 15:55 Uhr:
Habe mich eben mal testweise mit dem Snom-Softphone DIREKT bei dem problematischen VOIP-Provider angemeldet (weil man hier ebenfalls das SIP-Protokoll so schön einsehen kann). Hier tritt das Problem ebenfalls nicht auf... Wenn ich hier mein Handy anrufe und auflege, bevor jemand abhebt, dann schickt das Snom genauso ein BYE (wo ich ursprünglich dachte, hier muss der Fehler liegen), aber mit dem Unterschied, dass es eine Erfolgsmeldung (200 OK) zurückbekommt und mein Handy zu klingeln aufhört. Im Gegensatz zum Lancom, der in dieser Situation sein "BYE" immer und immer wieder schickt, ohne eine Erfolgsmeldung zu bekommen, sodass mein Handy eben nicht aufhört zu klingeln.
Kann mir das absolut nicht erklären. Ich hab aber sowohl den SIP-Trace vom Lancom als auch das Protokoll vom Snom jeweils mitgeschnitten und abgespeichert, falls es jemanden interessiert, kann ich diese per PM zukommen lassen.
Liebe Grüße,
michael
michael
Meine erste Vermutung bezüglich RINGING oder nicht RINGING war eher nicht daran schuld.
Nach vielen Versuchen (Danke Andi) glaube ich nun, ganz dicht an dem Problem dran zu sein:
Mein VOIP Provider (dieser setzt übrigens SER ein) schickt auf die BYE Meldung beim auflegen ein "SIP/2.0 401 Unauthorized" zurück - mit der Aufforderung die Authorisierung nachzureichen:
Beispiel:
"WWW-Authenticate: Digest realm="sipgate.de", nonce="401d60594be4a3a78821bb0221e690abbafb2979"
Jetzt wär eigentlich der Client am Zug, eine Autorisierung nachzuliefern. Dies macht er in der Regel, in dem er das Bye nochmal schickt mit einer Auth-Zeile.
Beispiel:
Authorization: Digest username="BENUTZERNAME",realm="sip.sipgate.de", nonce="4475b782732294de42e7296a1eeff0da37254b21",uri="sip:NUMMER@SIP-PROXY",response="72dff830f3a9b3de0a6293621d8800c3",algorithm=md5
So läuft es auch mit allen SIP Clients, die ich bisher getestet habe (Sipura ATA, Snom-Softphone, Linksys Telefon) - darum funktioniert es auch, wenn mein Telefon direkt registriert ist (ohne Lancom als Proxy dazwischen). Der Lancom jedoch tut das nicht - stattdessen schickt er ganz panisch immer wieder eine BYE Nachricht, ohne der Auforderung sich zu authorisieren nachzukommen.
Das ganze lässt sich mittlerweile zu 100% so reproduzieren, weswegen ich sicher bin, dass dies die Ursache ist. Hier wäre (soweit ich dies im Moment beurteilen kann) eine Nachbesserung seitens Lancom sehr wünschenswert, weil einerseits viele andere Provider ebenfalls SER einsetzen und es hier tatsächlich zu unerwünschten Kosten kommen kann (und in meinem Fall auch gekommen ist). An dieser Stelle Danke an die österr. Telekom, die die Verbindung zu der Zeitansage (meine Lieblings-Testnummer) automatisch nach 30 Minuten trennt. Wäre das nicht so, wär ich jetzt vermutlich pleite
Nach vielen Versuchen (Danke Andi) glaube ich nun, ganz dicht an dem Problem dran zu sein:
Mein VOIP Provider (dieser setzt übrigens SER ein) schickt auf die BYE Meldung beim auflegen ein "SIP/2.0 401 Unauthorized" zurück - mit der Aufforderung die Authorisierung nachzureichen:
Beispiel:
"WWW-Authenticate: Digest realm="sipgate.de", nonce="401d60594be4a3a78821bb0221e690abbafb2979"
Jetzt wär eigentlich der Client am Zug, eine Autorisierung nachzuliefern. Dies macht er in der Regel, in dem er das Bye nochmal schickt mit einer Auth-Zeile.
Beispiel:
Authorization: Digest username="BENUTZERNAME",realm="sip.sipgate.de", nonce="4475b782732294de42e7296a1eeff0da37254b21",uri="sip:NUMMER@SIP-PROXY",response="72dff830f3a9b3de0a6293621d8800c3",algorithm=md5
So läuft es auch mit allen SIP Clients, die ich bisher getestet habe (Sipura ATA, Snom-Softphone, Linksys Telefon) - darum funktioniert es auch, wenn mein Telefon direkt registriert ist (ohne Lancom als Proxy dazwischen). Der Lancom jedoch tut das nicht - stattdessen schickt er ganz panisch immer wieder eine BYE Nachricht, ohne der Auforderung sich zu authorisieren nachzukommen.
Das ganze lässt sich mittlerweile zu 100% so reproduzieren, weswegen ich sicher bin, dass dies die Ursache ist. Hier wäre (soweit ich dies im Moment beurteilen kann) eine Nachbesserung seitens Lancom sehr wünschenswert, weil einerseits viele andere Provider ebenfalls SER einsetzen und es hier tatsächlich zu unerwünschten Kosten kommen kann (und in meinem Fall auch gekommen ist). An dieser Stelle Danke an die österr. Telekom, die die Verbindung zu der Zeitansage (meine Lieblings-Testnummer) automatisch nach 30 Minuten trennt. Wäre das nicht so, wär ich jetzt vermutlich pleite
Liebe Grüße,
michael
michael