[TEILW. GELÖST] Abbruch bei Nikotel eingehend nach 1:58

[der_Gersthofer]

Ich habe leider doch noch größere Probleme mit einzelnen Providern.

Im Linksys WRT54G Router ist uPnP standardmäßig aktiviert.
Im SNOM 190 wurde vor jedem Test ein facory reset und nur in Line 1 die Daten: Accountname, Passwort und Registrar eingegeben (dabei ist NAT Erkennung standardmäßig auf "automatisch"):


Web.de: Ankommende und abgehende Gespräche klappen reibungslos.

Nikotel: Abgehende Gespräche klappen reibungslos. Ankommende brechen bei mir nach 1:53 Min - 1:57 Min ab.


Hier das LOG bei Anruf auf SNOM nur mit Nikotel konfiguriert (Abbruch nach ca. 1:54 Min):

[5]24/12/2001 00:00:09: Starting UPnP search
[2]24/12/2001 01:00:09: start_dst(986086800) end_dst(1004230800) offset_dst(3600) offset_utc(3600)
[2]24/12/2001 01:00:09: start DST: 04/01/2001 01:00:00 (986086800)
[2]24/12/2001 01:00:09: end DST: 10/28/2001 01:00:00 (1004230800)
[2]20/10/2004 13:36:11: start_dst(1080435600) end_dst(1099184400) offset_dst(3600) offset_utc(3600)
[2]20/10/2004 13:36:11: start DST: 03/28/2004 01:00:00 (1080435600)
[2]20/10/2004 13:36:11: end DST: 10/31/2004 01:00:00 (1099184400)
[4]20/10/2004 13:36:11: UPnP: Get description
[4]20/10/2004 13:36:11: UPnP: Get WANDevice description
[4]20/10/2004 13:36:11: UPnP: retrieved Control URL /uuid:0006-25ff-98490200badc/WANIPConnection:1
[5]20/10/2004 13:36:11: UPnP: Found mapped address 195.158.17#.###
[5]20/10/2004 13:36:11: UPnP: Mapped external SIP port 62351 to internal port
[1]20/10/2004 13:36:12: UPnP: SIP port mapped to 195.158.17#.###:62351
[1]20/10/2004 13:36:12: UPnP: RTP/RTCP ports 0 port mapped to 195.158.17#.###:54950/54951 (local 10000/10001)
[1]20/10/2004 13:36:12: UPnP: RTP/RTCP ports 1 port mapped to 195.158.17#.###:36530/36531 (local 10002/10003)
[2]20/10/2004 13:36:12: UPnP Setup done.
[5]20/10/2004 13:36:12: Match challenge for user=ID, realm=nikotel.com
[2]20/10/2004 13:36:13: Registered at registrar as [email][email protected][/email]
[5]20/10/2004 13:38:20: Dialog -2/1 going to early
[2]20/10/2004 13:38:20: gui_object::synthesizer: Alert Info not set
[5]20/10/2004 13:38:20: Dialogs: Searching open call
[5]20/10/2004 13:38:20: Dialog instance -2/1 (tz0r0xabn4/3FAD1F94-2067) early
[5]20/10/2004 13:38:25: Dialog -2/1 going to confirmed
[5]20/10/2004 13:38:25: Dialogs: Searching open call
[5]20/10/2004 13:38:25: Dialog instance -2/1 (tz0r0xabn4/3FAD1F94-2067) confirmed
[5]20/10/2004 13:40:20: Dialog -2/1 going to terminated
[5]20/10/2004 13:40:20: timeout::callback: Registering with timeout of 0 ms

 

[sip]

Koehler schrieb mir zudem - wenn NAT Erkennung auf "automatisch" steht und ein Anruf auf Nikotel-Account hereinkommt - dass folgendes passiert: "Bei Anruf von PSTN macht das SNOM nicht das was es sagt. Es signalisiert einen Session Timer und die Verantwortung fuer diesen, aber ausfuehren tut das SNOM das nicht. [...].

Schau mal ob du einen Session Timer ausschalten kannst. Das ist jedenfalls das Problem. [...]."

Ich denke schon, daß Snom das getestet hat. Denn wenn sich Koehler die Traces mal genauer angesehen hätte, dann hätte er sehen müssen, daß das snom Telefon die Last des Refresh des Session Timers an den UAC abgiebt (im Session-Expires Header ist das Attribut auf refresher=uac gesetzt). Da das Gespräch aber von Nikotels Cisco Gateway gestartet wurde, ist das Cisco Gateway der UAC und müsste daher das re-INVITE (den Refresh) senden. Da das Gespräch nicht re-freshed wird, wird es wie vom Cisco Gateway initial verlangt, nach 120 Sekunden (was den beschriebenen 1:58 ja recht nahe kommt) beendet. D.h. hier liegt wohl viel mehr ein Bug auf seiten von Cisco oder eine Fehlkonfiguration bei Nikotel vor.

 

[der_Gersthofer]

Da das Gespräch aber von Nikotels Cisco Gateway gestartet wurde, ist das Cisco Gateway der UAC und müsste daher das re-INVITE (den Refresh) senden. Da das Gespräch nicht re-freshed wird, wird es wie vom Cisco Gateway initial verlangt, nach 120 Sekunden (was den beschriebenen 1:58 ja recht nahe kommt) beendet. D.h. hier liegt wohl viel mehr ein Bug auf seiten von Cisco oder eine Fehlkonfiguration bei Nikotel vor.

Nur damit kein Missverständnis entsteht: Das Testgespräch wurde von mir von einem normalen Festznetzanschluss aus gestartet und es wurde das SNOM (u. a. auf Nikotel konfiguriert) angerufen; also PSTN -> SNOM (Nikotel) und nicht SNOM (Nikotel) -> PSTN.

 

[koehler]

Stimmt, steht auf uac und nicht uas. Sorry, war in Eile.

 

[hertfelderu]

Hallo,

habe heute das Snom 190 bekommen und gleich getestet. Ist um längen besser (in jeder Hinsicht) als die Giptel Pendanten.

Aber nun zum Thema:

Habe gleich nach Erhalt die aktuelle Firmware v. 3.56 auf das Telefon geladen und gerade in Hinsicht Gesprächsabbrüche Nikotel nach 1:58 Minuten getestet.

Meine Erfahrung zeigen, dass mit dieser Firmwareversion unter -> Erweitert -> NAT Erkennung: AUS stehen sollte.

Die ausgehenden Verbindungen klappen uneingeschränkt, aber mit der Einstellung -> Erweitert -> NAT Erkennung: STUN brachen 2 Gespräche bei ca. 3 Minuten ab und 3 Gepsräche bei 1:58 Minuten ab (eingehende Verbindungen von VoiP und Festnetz).

Habe dann die Einstellung auf -> Erweitert -> NAT Erkennung: AUS gestellt und hatte anschließend 2 eingehende Gespräche vom Festnetz von über 5 Minuten.

Kann jemand diese Erfahrungen bestätigen.

Danke.

Mfg. Uwe

 

[der_Gersthofer]

Factory reset - bis auf feste IP und deutsche Sprache alles so gelassen; Line 1 mit Nikotel konfiguriert (Registrar: nikotel.com)

Bei NAT Erkennung auf "aus":

Auf SNOM eingehende Anrufe vom Handy:
Nikotel: Gespräche klappen (getestet an einem 3:49 Min Gespräch)


Bei NAT Erkennung auf "STUN":

Auf SNOM eingehende Anrufe vom Handy:
Nikotel: Gespräche klappen (getestet an einem 3:52 Min Gespräch)

[2]24/12/2001 01:00:09: start_dst(986086800) end_dst(1004230800) offset_dst(3600) offset_utc(3600)
[2]24/12/2001 01:00:09: start DST: 04/01/2001 01:00:00 (986086800)
[2]24/12/2001 01:00:09: end DST: 10/28/2001 01:00:00 (1004230800)
[5]24/12/2001 01:00:09: Starting STUN determination from reregister_all:
[5]24/12/2001 01:00:09: Starting STUN determination from reregister_all:
[2]4/11/2004 12:16:57: start_dst(1080435600) end_dst(1099184400) offset_dst(3600) offset_utc(3600)
[2]4/11/2004 12:16:57: start DST: 03/28/2004 01:00:00 (1080435600)
[2]4/11/2004 12:16:57: end DST: 10/31/2004 01:00:00 (1099184400)
[4]4/11/2004 12:16:57: Found STUN server 63.214.186.12:3478
[4]4/11/2004 12:16:57: Found STUN server 63.214.186.12:3478
[5]4/11/2004 12:16:57: Starting STUN determination
[4]4/11/2004 12:16:57: Found STUN server 63.214.186.12:3478
[5]4/11/2004 12:16:57: Starting STUN determination
[5]4/11/2004 12:16:57: Match challenge for user=ID, realm=nikotel.com
[2]4/11/2004 12:16:57: Registered at registrar as [email][email protected][/email]
[5]4/11/2004 12:16:58: STUN: Found mapped addr 195.158.17#.###:5060
[0]4/11/2004 12:16:58: Automatic NAT detection: Found full cone NAT (195.158.17#.###:5060)
[5]4/11/2004 12:16:58: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:16:58: Match challenge for user=ID, realm=nikotel.com
[4]4/11/2004 12:16:58: Answering Challenge for REGISTER
[5]4/11/2004 12:16:58: Match challenge for user=ID, realm=nikotel.com
[2]4/11/2004 12:16:59: Registered at registrar as [email][email protected][/email]
[5]4/11/2004 12:17:13: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:17:16: Dialog -2/1 going to early
[2]4/11/2004 12:17:16: gui_object::synthesizer: Alert Info not set
[5]4/11/2004 12:17:23: timeout::callback: Registering with timeout of 0 ms
[5]4/11/2004 12:17:24: Dialog -2/1 going to confirmed
[5]4/11/2004 12:17:24: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:17:24: STUN: increase binding time to 16 seconds
[5]4/11/2004 12:17:24: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:17:28: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:17:44: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:17:52: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:17:52: STUN: increase binding time to 18 seconds
[5]4/11/2004 12:17:53: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:18:01: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:18:19: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:18:23: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:18:23: STUN: increase binding time to 20 seconds
[5]4/11/2004 12:18:23: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:18:37: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:18:55: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:18:55: STUN: increase binding time to 22 seconds
[5]4/11/2004 12:18:55: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:18:57: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:19:19: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:19:29: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:19:29: STUN: increase binding time to 24 seconds
[5]4/11/2004 12:19:29: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:19:52: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:20:06: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:20:06: STUN: increase binding time to 27 seconds
[5]4/11/2004 12:20:06: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:20:16: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:20:43: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:20:46: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:20:46: STUN: increase binding time to 30 seconds
[5]4/11/2004 12:20:46: Received STUN measure pdu from 63.214.186.12:3478
[5]4/11/2004 12:21:10: STUN: Found mapped addr 195.158.17#.###:5060
[5]4/11/2004 12:21:15: Dialog -2/1 going to terminated
[5]4/11/2004 12:21:15: timeout::callback: Registering with timeout of 0 ms

Das Problem scheint also behoben zu sein.

 

[haeberlein]

Eingeh. Nikotel Gespr. brechen ab - Session Timer abschalten

Hallo!

Weiss jemand wie man den Session Timer beim SNOM 190 abschalten kann? Es geht immer noch darum ,das eingehende Nikotel Gespräche nach 2 Minuten beendet werden. Laut SNOM liegt es an Nikotel und laut Nikotel liegt es an SNOM. Und der Kunde bleibt der Dumme. Nikotel sagt man soll am SNOM den Session Timer ausschalten ,und SNOM sagt Nikotel hält sich nicht an den Standard.

 

[dt]

Also bei mir funktionieren Nikotel Gespräche einwandfrei! Aber ich kann dir dabei nicht helfen. Wobei ich persönlich immer erst den Finger auf die Provider richten würde!

 

[haeberlein]

Es geht um ankommende Gespräche ,nicht um abgehende Gespräche.

 

[der_Gersthofer]

Habe beide Threads mal zusammengeführt


Hm, wird dir nicht viel helfen, aber: bei mir gehts einwandfrei.

Hast du NAT Erkennung auf uPnP oder STUN?
Hat dein Linksys Router Firmware HyperWRT 1.4 (aus deiner Sig nicht zu erkennen). Welche Firmware hat den SNOM (auch nicht zu erkennen).

Ansonsten hilft allenfalls noch Session Refresher: Server

 

[haeberlein]

Hallo!
Mein SNOM 190 hat die Firmware 3.56m und ist vor dem Linksys (Firmware Version: v2.04.4 - HyperWRT v1.4 ) geschaltet (aber nach der Fritz Box Fon). Beim SNOM steht NAT auf automatisch.

 

[der_Gersthofer]

Dann mach es doch einmal bitte so wie ich es beschrieben habe: NAT Erkennung auf uPnP oder STUN und wenn das auch noch nichts hilft, dann schließ den Router direkt an das DSL-Modem an und daran dann das SNOM.

Nachdem es bei mehreren Leuten geht muss es wohl an deiner Hardwarekonfiguration liegen.

 

[haeberlein]

Meine Fritz Box ist DSL Modem in Router in einem. Da geht nix zu trennen. NAT auf upnp oder STUN hat auch nichts geholfen. Ich vermute mal stark es liegt an der neuen Fritz Box Firmware. Naja alles Mist wenn sich keiner richtig an den Standard hält.

 

[der_Gersthofer]

Hast du registrar auch auf "nikotel.com"?

 

[haeberlein]

Nein auf calamar0.nikotel.com. Ist nikotel.com besser?

Edit: Hat auch nix gebracht. Dieser Müll von Nikotel ist doch zum Kotxxen. Immer ist nach 1: 58 Min Schluss. Snom ist das Problem bekannt hat aber keine Lösung und Nikotel stellt sich bock sturr. Bei allen andern 12 Providern klappt es ja auch.

 

[nitana]

wieso steht:
"[GELÖST] SNOM 190 Abbruch bei Nikotel eingehend nach 1:58", wenn das Problem immer noch besteht???

nitana

 

[haeberlein]

Genau. Ich habe mittlerweile alle Varianten durch. Sogar von Web.de auf Nikotel bricht ab.

 

[der_Gersthofer]

@Haeberlein
Es liegt an deiner Fritz! Box Fon. Nimm doch einfach mal ein normales DSL-Modem, den Linksys Router dahinter und dann das SNOM (bei dem du vorher ein factory reset gemacht hast und dann nur mit Nikotel-Daten gefüttert hast) und du wirst sehen es geht.

@nitana
Besteht das Problem bei dir auch? Wenn ja, nimm mal nicht die buggy Firmwae Sveasoft 5.1 sondern HyperWRT 1.4

 

[nitana]

ok dann gebe ich auch mal meinen senf jetzt dazu..., Modem > LinksysWRT54(HyperWRT v1.4) > Snom190(3.56m) alle ports sauber zum Snom geleitet und es gehen alle Provider außer nikotel bricht nach 2min ab, und jetzt?????

nitana

 

[der_Gersthofer]

Man braucht beim Linksys mit HyperWRT 1.4 (! - keine höhere) überhaupt kein Portforwarding. Also mach dort mal ein Factory reset (wirklich auch machen, insbes. wenn vorher eine andere Firmware wie Sveasoft drauf war! uPnP ist am Router (standardmäßig) aktiviert! Du gibst dort nur deine Provider-Zugangsdaten ein).

Selbiges am SNOM (factory reset) und dann mal nur die Zugangsdaten von Nikotel eingeben und NAT Erkennung auf uPnP (oder NAT).