[Gelöst] NAT Problem bei Asterisk und Sipdroid (one way audio)

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
Hallo,
ich habe seit vier Tagen ein NAT(?) Problem. Mein Client sendet keine Audio-Pakete mehr an den Asterisk.
Zuvor hat alles funktioniert. An der Konfiguration habe ich zumindest bewusst nichts geändert und das Problem ist abhängig vom Provider (es tritt nur bei Betamax auf). Im eigenen Lan funktioniert alles wie gewohnt.

Der Asterisk befindet sich hinter einem Router, RTP-Ports (10000-10500) und 5060 sind jedoch an den Server weitergegeben.

Asterisk IP-Adressen (anonymisiert):
LAN: 10.10.0.102
Öffentlich: 111.111.111.11​

Meine Konfiguration (sip.conf):
Code:
[general]
bindport=5060
bindaddr=0.0.0.0
context=sonstige
srvlookup=yes
language=de
qualify=yes
nat=yes
directmedia=no
localnet=10.10.0.0/255.255.255.0
allow=all
tos_sip=cs3
tos_audio=ef
tos_video=af41
maxexpiry=3600
minexpiry=60
defaultexpiry=600
registertimeout=30
registerattempts=0
externhost=asterisk.dyndns.org
externrefresh=600
fromdomain=asterisk.dyndns.org

[den-sipdroid]
type=friend
context=tel-dennis
secret=********
host=dynamic
[email protected]
disallow=all
allow=alaw,ulaw,g722,gsm,speex
nat=yes

[powervoip]
type=peer
secret=********
username={powervoipuser}
authuser={powervoipuser}
fromuser={phonenumber}
host=sip.powervoip.com
fromdomain=powervoip.com
canreinvite=no
insecure=port,invite
qualify=yes
dtmfmode=rfc2833
disallow=all
allow=alaw,ulaw
Als Client verwende ich ein Android Smartphone mit dem Client Sipdroid. Der Client kann zum Asterisk verbinden und innerhalb des eigenen LANs funktioniert das Telefonieren auch super.

Wenn ich an der Uni bin, logge ich mich ins dortige WLAN ein. Das Telefon erhält die IP 222.222.222.222. Diese IP ist die IP des WLAN-Adapters und zugleich die öffentliche IP. Nun ist heraustelefonieren nur über bestimmte Anbieter möglich. Eingehende Anrufe können entgegengenommen werden. Wenn das ausgehende Telefonat über einen Betamax-Provider heraus geht, scheint Sipdroid einfach keinen Audio-Stream zu senden.

Ich habe auf dem Handy ein tcpdump ausgeführt und die IP-Adressen und host-namen an obige Daten angepasst. Im ZIP-Archiv gibt es ein tcpdump zu einem funktionierenden Telefonat im eigenen Lan und eins zu einem Telefonat ohne ausgehendem Sound hinter dem Uni-NAT.

in beiden Logfiles finden sich auch ICMP-Pakete wieder. Leider erkenne ich den Zusammenhang nicht. Zur besseren übersicht liegen den kompletten Files auch übersichten im CSV-Format bei.

Würde mich über ideen für die Ursache freuen :)
Viele Grüße
 
Zuletzt bearbeitet:

ilmtuelp0815

Aktives Mitglied
Mitglied seit
4 Sep 2005
Beiträge
1,295
Punkte für Reaktionen
0
Punkte
0
Hi kokoloris!
Bist du sicher, das so die Syntax stimmt?
allow=alaw,ulaw,g722,gsm,speex
Das habe ich so noch nicht gesehen. Auch auf voip-info.org nicht. Da werden die einzelnen Codecs immer separat freigegeben. Nicht das nur alaw freigegeben ist und ein anderer Codec benutzt werden soll.
 

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
uhh ... habe es nur in ein paar Beispielen so gelesen .... ich werd's am Montag an der Uni testen... vielleicht löst das das Problem. Danke dir!
 

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
Leider hat die Codec-Syntax mein Problem nicht gelöst ...
hat vielleicht noch jemand eine Idee woran es liegen könnte?

Mein Asterisk sendet SIP-Pakete offensichtlich von Port 60005 anstatt von Port 5060. Ist das normal? Zumindest macht er das im eigenen LAN nicht. Einmal antwortet der Client auch auf diesen Port...

Hier ein Ausschnitt aus dem TCP dump:
tcpdump.jpg

Asterisk=134.102.133.xx
Client=134.102.147.xxx
 
Zuletzt bearbeitet:

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
Ich vermute das Problem liegt an SIPDROID. Wenn ich den SIP-Client von Android 2.3 verwende funktioniert alles. Dieser unterstüzt aber leider nur GSM. Hat sonst niemand das Problem?
 

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
Ich habe meine Datenstreams weiter analysiert. Durch eine Aufnahme der Daten auf dem Client und zeitglich am Server komme ich zu folgender Erkenntnis:

Der Client iniziert das Telefonat und verlangt einen Audiostrem auf Port 21000
Asterisk antwortet und verlangt einen Audiostream auf Port 10426
Asterisk startet den Stream von Port 10426 auf Port 21000
Am Client steht in den ankommenden Paketen jedoch der Absenderport 63988 anstatt 10426. Dies veranlasst SIPDROID offenbar, nicht auf den Stream zu anworten...

Also ist irgendwo ein NAT-Device, welches unerwartet den Absender-Port verändert. Kann ausgeschlossen werden, dass es sich um den NAT-Router des Clients handelt? Ist es zwingend der NAT-Router am Server?
Kann ich in diesem Fall Asterisk zwingen den ausgehenden Port per STUN zu ermitteln? Welche anderen Möglichkeiten habe ich?

Viele Grüße
Dennis
 

henry90

Aktives Mitglied
Mitglied seit
13 Feb 2007
Beiträge
822
Punkte für Reaktionen
5
Punkte
18
Kann ich in diesem Fall Asterisk zwingen den ausgehenden Port per STUN zu ermitteln?
Probier's doch einfach mal mit z.B:
stunaddr=stun.sipgate.net
in sip.conf, general

Hab ich bei mir drin statt externhost= (asterisk 1.6)
 
Zuletzt bearbeitet:

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
Das scheint nichts zu ändern. Allerdings ist die Option "stunaddr" auch auf keiner der folgenden Seiten dokumentiert. Oder fehlt noch ein STUN-Port?

http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf
http://svn.digium.com/svn/asterisk/branches/1.8/configs/sip.conf.sample

EDIT 1 schrieb:
Ah, das scheint sich in Asterisk 1.8 in einem einzelnen Modul zu befinden. Aber auch nach konfiguration von res_stun_monitor bleibt das Problem bestehen :(
http://svn.digium.com/svn/asterisk/branches/1.8/configs/res_stun_monitor.conf.sample

Komischerweise wird Port 5060 durch mein NAT ja auch nicht immer geremapped .... vielleicht wird nur dieser Port überprüft ...
EDIT 2 schrieb:
Das STUN-Modul gibt mir folgende DEBUG-Meldungen. Allerdings scheint es beim einleiten eines Telefongesprächs nicht zu arbeiten.
Code:
alix*CLI> stun set debug on
STUN Debugging Enabled
STUN Packet, msg Binding Response (0101), length: 68
Found STUN Attribute Mapped Address (0001), length 8
Ignoring STUN attribute Mapped Address (0001), length 8
Found STUN Attribute Source Address (0004), length 8
Ignoring STUN attribute Source Address (0004), length 8
Found STUN Attribute Changed Address (0005), length 8
Ignoring STUN attribute Changed Address (0005), length 8
Found STUN Attribute Non-RFC3489 Attribute (8020), length 8
Ignoring STUN attribute Non-RFC3489 Attribute (8020), length 8
Found STUN Attribute Non-RFC3489 Attribute (8022), length 16
Ignoring STUN attribute Non-RFC3489 Attribute (8022), length 16
Dunno what to do with STUN message 0101 (Binding Response)
[Sep 26 14:53:37] NOTICE[5409]: res_stun_monitor.c:111 stun_monitor_request: STUN MONITOR: Old external address/port 0.0.0.0:0 now seen as 134.102.133.xx:62281
Vermutlich werde ich den Router mal austauschen müssen um zu testen, ob er schuld ist ...
 
Zuletzt bearbeitet:

kokoloris

Neuer User
Mitglied seit
1 Mrz 2006
Beiträge
38
Punkte für Reaktionen
0
Punkte
0
Das Problem hat sich erledigt. Ich habe den alten Router ausgetauscht und mit dem neuen Router läuft alles :)

Der alte Router hat offenbar die Port-Freigaben nicht auf ausgehende Verbindungen angewendet. So hatte jeder ausgehende Audio-Stream einen zufälligen Port über 60000 anstatt der definierten RTP-Ports....

Also: Probem durch Routerkauf gelöst :D