Sipgate Problem

Ältere Auerswald TK-Anlagen und Archiv COMmander Basic.2
1

Hallo zusammen,
ich habe bei mir sipgate in einer COMmander Basic.2 mit 3.2E-000 konfiguriert. Ein VoIP-Kanal der Anlage ist intern (für ein/zwei snom 300), einer extern (jetzt sipgate).

Die Liste der Anbieter ist auf der Default-Konfiguration mit folgenden Einstellungen für sipgate:

[quote]
Domain: sipgate.de
Registrar: sipgate.de
STUN-Server: keiner
NAT-Keepalive: ja, 60 sec
Outbound-Proxy: deaktiviert
Registrierungsintervall: 5 min
SIP-UDP-Port: 5063
SIP-Session-Timer: 10 min
Jitter-Buffer: 50
SIPS/SRTP: ohne
Echo Cancellation: nein

Format der gewählten Rufnummer: Landesvorwahl mit führenden Nullen
Rufnummerübermittlung: im Displaytext
Format der übermittelten Rufnummer: Landesvorwahl mit führenden Nullen
Displaytext bei Rufnummerunterdrückung: Anonymous
Rufnummerunterdrückung durch den Anbieter: nein

Regeln: Lösche @ und Zeichen rechts davon; Lösche nichtnumerische Zeichen
[/quote]Damit habe ich einen Account “VoIP sipgate” als Mehrgeräteanschluss eingerichtet.

[quote]
Amtszugangsziffer: 70
Benutzername:
Passwort:
Authentifizierungs-ID:

MSN: 3099039 “Home sipgate”
[/quote]In der Rufverteilung wird ein Telefon eingehend angesprochen.

Rufe ich nun die Nummer von extern an, so klingelt das Telefon und ich kann am Telefon sprechen. Dies hört die (entfernte) Gegenstelle. Was dort gesprochen wird, kann jedoch nicht intern gehört werden. Rufe ich die sipgate 10000 zum Test an, so höre ich nichts.

Abgehend scheint Audio korrekt übertragen zu werden, während eingehend Audio überhaupt nicht ankommt. Also vermutete ich ein Routerproblem… weit gefehlt. An der Anlage kommen jedoch RTP-Pakete mit G.711 PCMA Codec an und verlassen diese auch.

[quote]
No. Time Source Destination Protocol Info
7 0.159323 217.10.79.9 10.0.0.9 SIP/SDP Status: 200 OK, with session description

Frame 7 (852 bytes on wire, 852 bytes captured)
Ethernet II, Src: Netgear_fa:4a:f9 (00:0f:b5:fa:4a:f9), Dst: Auerswal_00:d9:27 (00:09:52:00:d9:27)
Internet Protocol, Src: 217.10.79.9 (217.10.79.9), Dst: 10.0.0.9 (10.0.0.9)
User Datagram Protocol, Src Port: sip (5060), Dst Port: 5063 (5063)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): root 14076 14076 IN IP4 217.10.79.30
Session Name (s): session
Connection Information ©: IN IP4 217.10.79.30
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 12310 RTP/AVP 8 0 111
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:111 telephone-event/8000
Media Attribute (a): fmtp:111 0-16
Media Attribute (a): silenceSupp:off - - - -
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv
[/quote][quote]No. Time Source Destination Protocol Info
6 0.158514 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34049, Time=160
7 0.159323 217.10.79.9 10.0.0.9 SIP/SDP Status: 200 OK, with session description
8 0.178111 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34050, Time=320
9 0.199140 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34051, Time=480
10 0.206503 10.0.0.9 217.10.79.9 SIP Request: ACK sip:10000@217.10.79.30
11 0.219457 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34052, Time=640
12 0.239129 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34053, Time=800
13 0.244703 10.0.0.9 217.10.79.30 RTP PT=ITU-T G.711 PCMA, SSRC=0x2244F4B8, Seq=57572, Time=3506080
14 0.259680 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34054, Time=960
15 0.264566 10.0.0.9 217.10.79.30 RTP PT=ITU-T G.711 PCMA, SSRC=0x2244F4B8, Seq=57573, Time=3506240
16 0.280680 78.43.105.201 10.0.0.9 RTP PT=ITU-T G.711 PCMA, SSRC=0x6DE3C9CC, Seq=34055, Time=1120
[/quote]Das sieht mir eher wie ein Codec-Problem der Auerswald-Anlage aus.

Es ist mir ein Rätsel, was hier noch konfiguriert werden könnte. Hinweise, Tips, Ideen sind willkommen! :slight_smile:

–gandalf.

2

Hallo Gandalf.

Wieso hast Du keinen Stun-Server eingetragen? Ohne den können solche Probleme natürlich auftreten.

z. B. stun.sipgate.net

Port 10000

Der STUN-Server (Spiegel-Server) ist ja notwenig, damit die Anlage selber weiss, unter welcher IP-Adresse und welchem Port Sie aktuell aus dem Internet erreichbar ist und dies dem Gesprächspartner beim Gesprächsaufbau mitteilen kann.

3

Da ich einen Netgear FVX538 mit symmetrischem NAT verwende, darf ich keinen STUN-Server einsetzen… hmm… ich kann mir nicht vorstellen, daß es damit geht, aber werde es dennoch mal versuchen.

–gandalf.

EDIT 19:11 Uhr: Keine Änderung… das gleiche Verhalten weiterhin, wobei ich nicht weiß, was passiert, wenn das NAT-Mapping abläuft… daher: ohne STUN-Server wie gedacht. Wäre mein STUN-Eintrag (bzw. das Fehlen eines solchen) das Problem, dann würden die Pakete nicht durch den Router zurück zur Anlage kommen. Das ist jedoch (wie man in meinem Pcap-Auszug klar sieht) der Fall. Für mich sieht das eher so aus, als würde der Codec doch nicht unterstützt oder ein Feature von sipgate wird nicht unterstützt, so daß eingehend der Datenstrom nicht korrekt decodiert werden kann. Ausgehend ist das kein Problem.

Ich werde nun mal versuchen, per IP-to-IP-Call von einem snom300 die Anlage direkt ohne Router anzurufen… Wenn das klappt, jedoch der externe Weg über den Provider nicht geht, dann liegt das an sipgate und ich muss tatsächlich die Sessiondaten mal genauer inspizieren.

EDIT 20:15 Uhr: Ein Anruf von einem snom300 auf nnnn@10.0.0.9:5063 (nnnn ist meine sipgate UserId) funktioniert in beide Richtungen. Es gibt also nicht prinzipiell ein Problem. Ich werde wohl die SIP und RTP Traces mal komplett in aller Pracht analysieren müssen… puh Es liegt entweder am Router oder an sipgate. Den Router kann ich testen, indem ich am zweiten WAN-Interface ein snom300 dranhänge. Mal sehen.

4

Das Problem liegt im Router. Der Netgear FVX538v2 mit Firmware 3.0.5-24 enthält nun im Gegensatz zur vorigen Version mal wieder einen irrwitzigen SIP ALG. Den hatte ich in der Version 2.x schon immer abgeschaltet :slight_smile: Ein Downgrade auf die Version 3.0.4-19 hilft. Alles funktioniert.

Der SIP ALG führte dazu, daß der eingehende Teil des RTP-Stroms umgeschrieben wurde, so daß er als von der Public-IP-Addr. des Routers zu kommen schien. Das passte natürlich nicht zur anderen Seite und die COMmander Basic.2 hat daher die Daten wohl geflissentlich ignoriert.

Nun ist nach Downgrade kein SIP ALG mehr vorhanden und alles klappt… ohne STUN übrigens :wink: wie auch zu erwarten bei Netgear.

–gandalf.

5

Sachen gibts :slight_smile:

6

Netgear hatte schon immer Probleme mit ALGs, jedoch war dies hier eingeführt worden ohne Option, den ALG abzuschalten… Die Nutzung von SIP durch den Router hindurch führte somit zu einseitigen Gesprächen und Abstürzen des Routers. Die nächste Firmware soll es lt. Netgear-Support dann optional abschaltbar machen.

–gandalf.

7

Ich habe nun die Beta 3.0.5-27 Firmware installiert und dort kann man den SIP-ALG per GUI abschalten. Funktioniert auch… Vorteil der 3.0.5 ist gegenüber 3.0.4, daß Bandbreitenprofile eingerichtet werden können, daher nutze ich lieber diese :wink:

–gandalf.

8

Mit ein Grund mehr, dass ich weiterhin LinksSys verwende - SipGate übrigens ohne STUN-Server und läuft einwandfrei.

Alex