[BUG] 360 schließt TCP Verbindung; eröffnet keine neu Verbindung auf dem Port

[der_Gersthofer]

Beobachte schon länger, dass das 360er Probleme mit TCP Verbindungen hat.

Der Intertex Support schrieb mir daraufhin:

This means the Snom phone closed the TCP connection. The IX68 cannot send anything as the TCP connection used for registration has become closed, and the Snom refuses to open a new connection on that port.

This is a known Snom bug. Please select UDP on the Snom or upgrade its firmware.

Weiß jemand, wann dieser Bug behoben wird? Und: Wo kann ich auf UDP umstellen am SNOM?

 

[der_Gersthofer]

zumindest auf UDP umschalten soll durch Anfügen von

;transport=udp

hinter den Registrar gehen.

 

[FonFan]

Nur mal so vom Wortlaut her gedacht:

Höre auf SIP TCP Port: auf "Aus" setzen?

Das Handbuch gibt ja leider (mal wieder typischerweise) nichts zu diesem Punkt her.

 

[der_Gersthofer]

Du meinst, dass das die Umschaltung auf UDP sein soll?

Das Log des IX sieh übrigens so aus:

Oct 14 18:07:30 thread.6 error recv(33): Connection reset by peer
Oct 14 18:07:30 thread.6 error Connection error on 33.
Oct 14 18:07:57 thread.1 error 192.168.0.32:2266 - send(33): Connection reset by peer
Oct 14 18:07:57 thread.6 error SIP send failure 2 on socket 33 cd1b70
Oct 14 18:07:57 thread.6 error recv(33): Connection reset by peer
Oct 14 18:07:57 thread.6 error Connection error on 33.
Oct 14 18:07:57 thread.1 error 192.168.0.32:2266 - send(33): Connection reset by peer
Oct 14 18:07:57 thread.6 error recv(33): Connection reset by peer
Oct 14 18:07:57 thread.6 error Connection error on 33.

 

[FonFan]

Ich habe den Eindruck (nicht das fundierte Wissen), daß eine SIP-Verbindung primär über UDP, aber alternativ auch über TCP aufgebaut werden kann. (Beim Start des IX68 ist ja auch von Port 5060 für UDP und für TCP die Rede.) Und bei dem oben angeführten Punkt vermute ich eben das Ausschließen eines Verbindungsaufbaus per TCP.

 

[Pingpong]

Ich hab grad mal das Log meines Routers befragt: mein Snom 300 registriert sich per UDP. Frag mich nicht woran das liegt, aber das sollte auch der Normalfall sein. Es wäre ja unsinnig permanent eine TCP-Verbindung aufrecht zu erhalten, das verbraucht ja nur unnötig Resourcen (Traffic für Keep-Alive, Sockets beim Server werden belegt).

 

[der_Gersthofer]

Ja, eigentlich sollte UDP der Normalfall sein. Ich weiß nur nicht, warum bei mir dann offenbar auf TCP umgeschaltet wird (Länge der Mitteilung ist dafür m. W. der Grund) - und warum das SNOM offenbar Probleme mit TCP-Verbindungen hat.

Auch wäre es natürlich schön, wenn man durch einen klar beschrifteten Schalter den Wechsel zu TCP unterbinden könnte...

 

[Pingpong]

Das muss doch rauszukriegen sein warum dein Snom TCP machen will. Liegt das vielleicht an deinem Intertex?
Lass doch mal den Intertex als Outbound-Proxy weg und schau was dann passiert. Im Log des Snom siehst du ja auch ob es UDP oder TCP sendet.
Passiert das mit jedem Provider, oder nur mit bestimmten?

 

[der_Gersthofer]

blueSIP läuft lt. SNOM Protokoll über TCP -> hier bestehen die Probleme
alle anderen über UDP

 

[Pingpong]

Seltsam. Bei mir läuft auch bluesip über udp. Das sieht dann so aus:

Sent to udp:217.74.179.29:5060 at 16/10/2006 18:51:04:400 (1049 bytes):

REGISTER sip:bluesip.net SIP/2.0
Via: SIP/2.0/UDP 88.134.234.xx:5062;branch=z9hG4bK-c55j6ojxxxxx;rport
From: "Pingpong" <sip:bluesip/[email protected]>;tag=wgfja2xxxx
To: "Pingpong" <sip:bluesip/[email protected]>
Call-ID: 3c26bd3d7ef4-a4haawmoxxxx@snom300-00041325xxxx
CSeq: 26 REGISTER
Max-Forwards: 70
Contact: <sip:bluesip/[email protected]:5062;line=s0mql4mh>;flow-id=1;q=1.0;+sip.instance="<urn:uuid:56278dfc-8a8c-4b81-90c7-4d724e96b8ab>";audio;mobility="fixed";duplex="full";description="snom300";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom300/6.3
Supported: gruu
Allow-Events: dialog
X-Real-IP: 192.168.1.4
WWW-Contact: <http://192.168.1.4:80>
WWW-Contact: <https://192.168.1.4:443>
Authorization: Digest username="bluesip/pingpong",realm="bluesip.net",nonce="4533b9a40157fde80b40f43f91ea4d707a82xxxx",uri="sip:bluesip.net",response="957cb1cb52df83a6ce932889ee62xxxx",algorithm=md5
Expires: 3600
Content-Length: 0

Received from udp:217.74.179.29:5060 at 16/10/2006 18:51:04:490 (711 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.134.234.xx:5062;branch=z9hG4bK-c55j6oj7xxxx;rport=5062
From: "Pingpong" <sip:bluesip/[email protected]>;tag=wgfja2xxxx
To: "Pingpong" <sip:bluesip/[email protected]>;tag=0354a2e1b960c9cc2279eca4e5f8xxxx.cebc
Call-ID: 3c26bd3d7ef4-a4haawmoxxxx@snom300-00041325xxxx
CSeq: 26 REGISTER
Contact: <sip:bluesip/[email protected]:5062;line=s0mql4mh>;q=1;expires=3600, <sip:[email protected]:5061>;q=0.5;expires=1941
Server: Sip EXpress router (0.9.4 (i386/linux))
Content-Length: 0
Warning: 392 217.74.179.29:5060 "Noisy feedback tells: pid=26686 req_src_ip=88.134.234.xx req_src_port=5062 in_uri=sip:bluesip.net out_uri=sip:bluesip.net via_cnt==1"

 

[der_Gersthofer]

Hm, ich habe keine Ahnung, warum blueSIP auf TCP läuft, alle anderen Provider laufen auf UDP.

Gleichwohl sollte es ja auch mit TCP nicht zu Problemen kommen.

 

[Pingpong]

Gleichwohl sollte es ja auch mit TCP nicht zu Problemen kommen.

Bei TCP-Verbindungen gibt es an etlichen Stellen Timeouts wenn kein Traffic stattfindet. Die sollte man nicht stundenlang ohne Traffic geöffnet halten.
Versuche es doch mal mit dem kleinsten Registrierungsintervall im Snom (z.B. 10 Minuten)

 

[der_Gersthofer]

Geändert und werde es beobachten, obwohl

and the Snom refuses to open a new connection on that port.

könnte dem hier entgegenstehen.

 

[Pingpong]

Was heisst "Snom refuses to open a new connection"?
Heisst das, der SIP-Server will eine neue Verbindung öffnen und das Snom weigert sich? Könnte bedeuten daß irgendwer anderer aufgrund von Timeouts die Verbindung beendet hat (Router oder Server), das Snom glaubt die sei noch offen und lässt keine neue Verbindung zu (was ja nur konsequent wäre). TCP ist einfach ungeeignet für diese Art der Kommunikation.
Ich würde an deiner Stelle mal forschen warum mit Bluesip kein UDP gemacht wird. Hast du schonmal versucht ohne Intertex als Proxy zu registrieren?

 

[blueSIP Support]

blueSIP und TCP

Hallo,

blueSIP unterstützt SIP sowohl via UDP als auch TCP.

Wie es scheint nimmt SNOM per default TCP, sofern verfügbar. Die Verfügbarkeit ergibt sich aus entsprechenden SRV Records zu bluesip.net (_sip._tcp.bluesip.net).

Die Unterstützung von TCP ist im übrigen keine Option, sondern gem. RFC 3261/18 ein "MUST". D.h. jeder der kein TCP unterstützt ist nicht RFC 3261 konform...

@Pingpong: TCP ist durchaus zur Signalisierung geeignet und bietet sogar diverse Vorteile. H.323 Signalisierungen laufen im übrigen auch über TCP und das funktioniert bestens.

Wie bereits von der_Gersthofer erwähnt kann man das SNOM durch folgenden Eintrag beim Feld Registrar per udp registrieren lassen: bluesip.net:5060;transport=udp.

Besser wäre es natürlich das Problem bzw. den Bug zu identifizieren und zu beseitigen...

Grüße aus München

blueSIP Support

 

[Pingpong]

Wie es scheint nimmt SNOM per default TCP, sofern verfügbar. Die Verfügbarkeit ergibt sich aus entsprechenden SRV Records zu bluesip.net (_sip._tcp.bluesip.net).

Dann frage ich mich warum es das bei mir nicht tut? Die Firmware der 3x0 Reihe ist weitestgehend identisch.

TCP ist durchaus zur Signalisierung geeignet und bietet sogar diverse Vorteile. H.323 Signalisierungen laufen im übrigen auch über TCP und das funktioniert bestens.

Das hängt davon ab ob man versucht die Verbindung permanent aufrecht zu erhalten, oder ob man sie bei Bedarf aufbaut. Ich weiss nicht was das SIP-Protokoll in diesem Fall vorsieht. Eine ständig offene Verbindung die nur einmal pro Stunde 2 Datenpakete überträgt ist auf jeden Fall nicht sinnvoll.

Bei Mailservern mit IMAP Idle Protokoll wird das so gemacht um eingehende Mails zum Client zu pushen. Hier gibt es aber auch erhebliche Probleme die Verbindung stabil aufrecht zu erhalten. Ein Nokia E61 schafft es z.B. nicht zuverlässig. Die Software muss immer damit rechnen daß die Verbindung unterbrochen wird, dies erkennen und sich automatisch reconnecten. Der Aufwand und die Fehleranfälligkeit sind enorm. Bei Mail macht das noch eher Sinn, aber beim SIP-Protokoll mit seinen paar Paketen zur Signalisierung sehe ich echt keinen Vorteil das so zu machen.

Wie bereits von der_Gersthofer erwähnt kann man das SNOM durch folgenden Eintrag beim Feld Registrar per udp registrieren lassen: bluesip.net:5060;transport=udp.

Damit sollte sein Problem dann ja gelöst sein.

Besser wäre es natürlich das Problem bzw. den Bug zu identifizieren und zu beseitigen...

Hierzu wüsste ich gerne mal ob der Fehler auch auftritt wenn er nicht den Intertex als Outbound Proxy verwendet. Solange würde ich nämlich einen Fehler beim Intertex nicht ausschliessen.

 

[blueSIP Support]

@Pingpong,

die SIP Signalisierung via TCP läuft nicht über persistente TCP Verbindungen sondern für jede SIP Message wird eine neue Verbindung aufgebaut.

Das Problem - so wie wir es verstehen - ist, dass auf dem Snom der Listener auf dem bei der Registrierung bekanntgegebenen Port zu sterben scheint und damit der TCP Port auf dem Snom vom SIP Proxy (z.B. Intertex) nicht mehr erreichbar ist.

Grüße

blueSIP Support

 

[der_Gersthofer]

Besser wäre es natürlich das Problem bzw. den Bug zu identifizieren und zu beseitigen...

Das finde ich auch, denn das Problem zu umgehen ist natürlich ein möglicher Workaround. Bedeutet aber im Ergebnis, dass irgendein Fehler in der Firmware bei TCP vorhanden ist, den man besser beseitigen sollte.
Support-Ticket wurde bei SNOM eröffnet, aber nach einer Kurzantwort, dass es an die Technik weitergegeben wurde, habe ich nichts mehr gehört...

 

[der_Gersthofer]

Das teilte mir der Support gerade mit, werde es entsprechend versuchen und beobachten:

Erweitert Seite:

Höre auf SIP TCP Port: An
Netzwerkidentität (Port): 5060 (wird eventuell nicht gebraucht)

Danach Neustart des Gerätes um sicherzugehen...