Asterisk & NAT = Asterisk Problem ?

[ddreamer]

Hallo Leute !
Erstmal mein Lob an das Forum !! Perfekt.
Habe vor ca. einem halben Jahr mir * Angefangen und habe sehr viele Info's u.a. hierüber erhalten.
Auch Der Kurs von Betateilchen... Sehr gut gelungen...

Jedoch hier mal kurz mein Problem:

Von ca. 3 *, die ich jetzt eingerichtet habe, gibt es bei einem ein Prob.
Ich betreibe alle diese 3 * hinter nat (bei verschiedenen Leuten/Standorten, als einzelne PBX)
Die konfiguration der Hardware ist bei allen 3 Fast identisch;
die I-Net Hardwarerouter ebenfalls. (auch von der Firmware WRT54G - DD-WRT fw.)
Einziger Unterschied, die angeschlossenen Hardphones / Softphones....
Zugänge via SIP = Sparvoip & GMX (alle 3 ; halt nur unterschiedliche Usernames / passw.)

Bei 2 von denen läuft alles wie geschmiert; bis auf das man sich über SparVoip-FN Nummer nicht anrufen kann; Gespräch kommt nicht durch. (Scheint aber normal zu sein, da es auch mit der FBF nicht geht..)

Ist aber auch nicht sóoo schlimm....
Einer dieser A* geht jedoch garnicht.

cli> sip show registry = zeigt alle auf registered
cli> sip show peers = auch alles im grünen bereich.

GMX läuft (raus & rein)
SIPAGTE (zum testen = auch alles ok)
Sparvoip = raus ja, jedoch hört mich der andere nicht <-- Problem...

Jetzt kommt der Hammer (es ging ja mal... = geändert wurde nichts!)
Hänge ich jetzt aber den anderern A* dran gehts auch nit...
Erster gedanke = Router macht doof.
Kurioser weise, stelle ich die Daten von Sparvoip auf einer FBF ein, geht alles, obwohl diese keine Portforwardings oder STUN verwendet.
Softphone von sparvoip = geht auch einwandfrei...

Ein ähnliches Problem habe ich mit einem der 2 anderen *. Diese gehen auch ab & an mal nit (Gesprächspartner hören nix... / nur zeitweise)

Wie gesagt, bei Asterisk 3 geht nu ausser SIPGATE nix mehr, denn GMX hat nu das selbe problem. (Gesprächspartner hören mich nicht)

Ich habe bald arg die vermutung, dass * generell Probleme hinter NAT hat; mal ganz unabhängig von der Router Hardware o.ä.
Wenn ich nämlich sip debug peer sparvoip eingebe, dann mappt er ja auch den RTP-Port richtig auf den NAT-Port (wie damals auch) kommt aber nix durch.

Hat jemand eine Lösung oder ähnliche Probleme ?

Gruss Micha

----------
Asterisk V1.2.4 (auf allen 3en) @ P4 1800MHz; 512MB; OS: RedHat 9

 

[Thomas007]

SparVoIP und g.726

Hi,
habe ein ähnliches Problem. Wollte Bandbreite reduzieren und von ulaw auf g.726 umstellen.
Test:
VoIP-Phone -ulaw- Asterisk -g.726-SparVoIP-POTS

Bei 10 Anrufen
3 mal OK
5 mal kein Audio
2 mal kein Audio von VoIP-Phone zum POTS

Ich hatte 4 verschiedene Server bei SparVoIP, keine Abhängigkeit von der IP festzustellen.

10 mal mit T-Online g.726 getestet, keine Probleme!

ulaw zu SparVoIP ebenfalls zuverlässig!

SparVoIP hat außerdem wohl noch 729 und 723, die kann ich bloß nicht transcodieren und die LAN phones sollen auf ulaw bleiben.

Gruß

Thomas

 

[Netview]

Hi,
habe ein ähnliches Problem. Wollte Bandbreite reduzieren und von ulaw auf g.726 umstellen.
Test:
VoIP-Phone -ulaw- Asterisk -g.726-SparVoIP-POTS

Bei 10 Anrufen
3 mal OK
5 mal kein Audio
2 mal kein Audio von VoIP-Phone zum POTS

Ich hatte 4 verschiedene Server bei SparVoIP, keine Abhängigkeit von der IP festzustellen.

10 mal mit T-Online g.726 getestet, keine Probleme!

ulaw zu SparVoIP ebenfalls zuverlässig!

SparVoIP hat außerdem wohl noch 729 und 723, die kann ich bloß nicht transcodieren und die LAN phones sollen auf ulaw bleiben.

Gruß

Thomas

Die Sache ist doch relativ trivial!
Jeder Provider arbeitet mit unterschiedlichen carriern zusammen um Gespräche ins Festnetz zu bringen. Du wirst also nicht nur mit verschiedenen carriern sondern auch mit einer Vielzahl von gateways connected. Manche dieser gateways unterstützen den G.726 und andere nicht - dies ist leider bei vielen Anbietern so!
Lass einfach mal einen sip debug mitlaufen, dann siehst du, dass der sip-proxy den codec zwar akzeptiert aber das gateway des carriers nicht mitspielt.

Im Grunde kann man nur zwei Dinge tun:
a) einen codec auswählen der von allen gateways unterstützt wird (try and error)
b) dem provider das Problem erläutern, der daraufhin wahrscheinlich dann den entsprechenden codec auf dem sip-proxy ebenfalls sperrt

Ein gutes Beispiel ist hier 1&1 in meiner Gegend. Der sip-proxy akzeptiert den G.726 abgehend und das gateway (Festnetz) von telefonica rejected diesen!
Ergebnis: Stille und ensprechende Fehlermeldungen im asterisk!

 

[Thomas007]

Ergebnis: Stille und ensprechende Fehlermeldungen im asterisk!

Hi, genau diese oder eine andere Fehlermeldung habe ich nicht.

LAN phone - Asterisk - Sparvoip - POTS phone
Für den Fall POTS hört LAN phone NICHT.
LAN phone hört aber POTS.

A - Asterisk
B - Sparvoip
C- Gateway

B an A: Session Progress SDP mit Mediadescription G.721 und IP und Port von C
Dann passiert der Fehler
A an C : RTP Paket mit Payload Typ g.721

Obwohl 721 überall disallow ist sendet Asterisk mit 721. Da Asterisk nicht ulaw auf 721 transcodieren kann wird in dem Datenstrom Müll stehen. Trotzdem bleibt die Verbindung stehen.

Asterisk hätte die Verbindung an dieser Stelle beenden müssen, da der Codec 721 nicht erlaubt ist.

Komischerweise sendet C an A mit g.726, deswegen kann man den Teilnehmer am POTS phone auch hören.

 

[ddreamer]

Hi, genau diese oder eine andere Fehlermeldung habe ich nicht.

LAN phone - Asterisk - Sparvoip - POTS phone
Für den Fall POTS hört LAN phone NICHT.
LAN phone hört aber POTS.

A - Asterisk
B - Sparvoip
C- Gateway

B an A: Session Progress SDP mit Mediadescription G.721 und IP und Port von C
Dann passiert der Fehler
A an C : RTP Paket mit Payload Typ g.721

Obwohl 721 überall disallow ist sendet Asterisk mit 721. Da Asterisk nicht ulaw auf 721 transcodieren kann wird in dem Datenstrom Müll stehen. Trotzdem bleibt die Verbindung stehen.

Asterisk hätte die Verbindung an dieser Stelle beenden müssen, da der Codec 721 nicht erlaubt ist.

Komischerweise sendet C an A mit g.726, deswegen kann man den Teilnehmer am POTS phone auch hören.

Genau dieses ist bei mir auch der Fall.
Kurioserweise gehts aber bei Asterisk 2 bei meinem bekannten.
Dort wird von A - B - C mit g.726 gehandelt.
Liegt scheinbar auch daran, wie man gerade geroutet wird.

Dann kann man eigentlich nicht NAT die schuld geben, sondern eher den Providern. Ich Frage mich nur, warum dies mit der FBF ATA funzt. Diese verwendet ulaw.&acute;
Stelle ich in SIp.CONF entsprechend auf:

disallow = all
allow = ulaw
allow = alaw

gehts aber auch nit..., da von A -> B wird dann uLaw gefahren, jedoch A -> C g721 ??? - Fazit: LAN -> POTS nee POTS -> LAN jeep !

WARUM ABER ZUM TEUFEL GEHTS MIT DER FBF ????!?!!?
*verzweifel* *tastaturaufess*

----
Edit:
Habe gerade mal folgendes gemacht:

Habe mal disallow = all auskommentiert und nochmals eine Verbindung nach POTS aufgebaut. ---> und geht doch (er fährt GSM ?? *confused*)

Erstaunlich: Er mapped uLaw, aLaw, gsm... (fährt aber gsm, laut sip show codecs)

Meine internen Phones gehen (bis auf eines) alle mit uLaw an den Asterisk (mein LAN iss nicht so "heavy loaded" also geht dass )
Das "Eine" Phone hängt an einer FBF ATA per WLAN (8km Richtfunkstrecke) per g726 an dem Asterisk
Getestet habe ich nur meine Phones, die also per ulaw dran sind.

Setzte ich nun wieder:

disallow = all
allow = gsm

und baue eine Verbindung auf ... juup, jeeht (Fragt sich nur wie lange...)

 

[Thomas007]

Hi,

Du hast Recht, SparVoiceIP läuft mit GSM!! Das war vor einigen Wochen noch nicht der Fall. Ist mir auch viel lieber als 726.

Zu G.726 das hier auch interessant zu lesen:
http://www.ip-phone-forum.de/archive/index.php/t-83751.html
http://www.faqs.org/rfcs/rfc3551.html

Offenbar gibt es da speziell bei 726 diverse eigenwillige und damit inkompatible Implementierungen.

Ich werde jetzt GSM benutzen mit fallback auf ulaw und evtl. G.729 Lizenzen erwerben. Von G.726 lasse ich erst mal die Finger.

Die Fritzbox wird mit G.726 laufen, weil die eine saubere Implementierung hat und/oder die Fehler der anderen einfach ausbügelt.

PS: 721 ist übrigens der Vorläufer von 726-32


Viele Grüße

Thomas

 

[ddreamer]

Hi,

Du hast Recht, SparVoiceIP läuft mit GSM!! Das war vor einigen Wochen noch nicht der Fall. Ist mir auch viel lieber als 726.

Stimmt. Ganz zu anfang hatte ich bereits mal GSM probiert. Ging auch nicht (ist jetzt schon ca. 6 Wo. her) hatte dann allerdings Erfolg mit G726-32.

Ich denke mal, dass man mit Fallback auf uLaw arbeiten muss, denn wer weiss wie lange das mit GSM funzt

GSM ist schon ok.
Weiss jedoch jemand, wieviele Gleichzeitige Verbindungen SparVoip zulässt ?

Gruss Micha