COMmander Basic.2 und sipgate: einseitige Audioverbindung

[gandalf94305]

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:

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

Damit habe ich einen Account "VoIP sipgate" als Mehrgeräteanschluss eingerichtet.

Amtszugangsziffer: 70
Benutzername: <meine sipgate user id>
Passwort: <mein sipgate user passwort>
Authentifizierungs-ID: <meine sipgate user id>

MSN: 3099039 "Home sipgate"

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.

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 (c): 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): silenceSuppff - - - -
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv

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:[email protected]
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

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!

--gandalf.

 

[gandalf94305]

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 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 ;-) wie auch zu erwarten bei Netgear.

--gandalf.

 

[gandalf94305]

Noch ein Update dazu: der Netgear-Support hat mir nun die 3.0.5-27 Betaversion der Firmware zur Verfügung gestellt. Diese ist nur über den Support zu erhalten.

Diese Firmware enthält eine zusätzliche Option unter Security -> Firewall -> Advanced, mit der der SIP-ALG abgeschaltet werden kann (Default ist kein Haken, d.h. abgeschaltet). Der SIP-ALG ist laut Hilfetext wohl gedacht, hinter einem NAT-Router mehrere SIP-Endgeräte unter dem gleichen externen Port zu betreiben. Das funktioniert jedoch so nicht. Ich bekomme dann an allen anderen Geräten auch einseitige Datenströme für Audio.

--gandalf.