Asterisk: Probleme mit GMX

[tulip]

Hallo

seit der Registrierung bei GMX habe Probleme mit Verbindungsabbrüchen.
Das beenden der Verbindung erfolgt nach ca. 30 Sekunden. Manchmal auch erst nach 50 Sekunden. Die Gesprächche die ich über GMX durchgehend führen konnte sind an der Hand abzuzählen.

Mein Sipgate-Account funktioniert ohne Probleme.

sip.conf

[general]
port = 5060 
bindaddr = 0.0.0.0 
context = default
disallow = all 
allow = g729
allow = alaw
allow = ulaw
allow = ilbc
allow = gsm 
register => XXXX:[email protected]/gmxXXXX
echocancel=yes 
tos=0x18 
dtmfmode=info
maxexpirey=3600  
defaultexpirey=600

[gmx]
type=friend
username=XXXX
secret=XXXXX
host=sip-gmx.net 
fromuser=XXXX
fromdomain=sip-gmx.net
nat=no
;nat=yes
context=sip-in
canreinvite=no
insecure=very  
;qualify=36000 
;maxexpirey=1801 
;defaultexpirey=180
;qualify=yes
qualify=no
disallow = all
language=de
allow = g729
;allow = alaw
;allow = ulaw
;allow = ilbc
;allow = gsm
insecure=very
dtmfmode=info
tos=0x18

Ich habe schon alles mögliche probiert , qualify, nat, codec, timerwerte. Gebracht hat es nichts. Eventuell hat hier noch jemand einen Tipp.

Gruß

Tulip

 

[Netview]

Du erlaubst abgehend nur den G.729 codec. Dieser ist jedoch nicht standardmässig bei asterisk dabei da dieser Lizenzpflichtig ist!
Wenn du einen codec angibst der nicht dabei ist, nimmt * einen der nicht aufgeführt wurde z.B. G.726 bzw. G.723. Falls G.723 gewählt wurde ist die Qualität wahrscheinlich deswegen grottenschlecht!
Lösung: den G.729a lizenzieren oder noch ulaw und alaw zulassen!
http://www.digium.com/index.php?menu=asterisk_g729
Welcher codec ausgewählt wurde sieht man in der Konsole mit 'sip debug peer gmx' bei einem abgehenden Ruf.

Abbrüche können auch wegen eines fehlerhaften port-forwardings der rtp-ports entstehen (wurden alle ports in der rtp.conf an * geforwarded?)!

 

[tulip]

hi,

der G.729 sollte eigentlich funktionieren, mit sipgate läuft es ja auch.
das Gespräch via GMX kommt ja auch mit G.729 zustande, nur bricht es halt nach 30-50 Sekunden ab.
Am Codec sollte es nicht liegen, ich hatte das ganze ja wie schon beschrieben auch mit anderen Codecs getestet (G.711) mit dem gleichen Ergebniss.

Die Ports werden korrekt geforwarded. Wie gesagt mit Sipgate funktioniert das ganze.

Gruß

Tulip

 

[Netview]

hi,

der G.729 sollte eigentlich funktionieren, mit sipgate läuft es ja auch.
das Gespräch via GMX kommt ja auch mit G.729 zustande, nur bricht es halt nach 30-50 Sekunden ab.
Am Codec sollte es nicht liegen, ich hatte das ganze ja wie schon beschrieben auch mit anderen Codecs getestet (G.711) mit dem gleichen Ergebniss.

Die Ports werden korrekt geforwarded. Wie gesagt mit Sipgate funktioniert das ganze.

Gruß

Tulip

Hast du überprüft ob der codec auch verwendet wurde mit 'sip show channels'?
Nur ein allow=G729 heisst noch lange nicht, dass dieser codec verwendet bzw. auch verfügbar ist!

Wieviele ports sind in der rtp.conf für * freigegeben?

 

[tulip]

Hi,

ja der Codec wird defintiv verwendet. Ich habe dies (mehrfach) mit über prüft.
Für den RTP-Stream sind zurzeit die Ports 10000-20000 freigegeben.
Diese Ports sind wie auch die/der Port(s) für die Signalisierung mit 100Kbit auf dem Gateway priorisiert.


Gruß

Tulip

 

[Netview]

Setze mal unter [general] noch ein:
insecure=very

 

[tulip]

Hi,

werde es mal testen. Leider kenne ich niemanden der zu dieser Zeit nicht angehalst ist wenn ich anrufe. Also wird es erst morgen etwas mit dem Ergebniss.
Eigentlich dachte ich auch das die Teile innerhalb des General-Parts von den Hostspezifischen überschrieben werden. Ist dem nicht so ?

Gruß

Tulip

 

[Netview]

Hi,

werde es mal testen. Leider kenne ich niemanden der zu dieser Zeit nicht angehalst ist wenn ich anrufe. Also wird es erst morgen etwas mit dem Ergebniss.
Eigentlich dachte ich auch das die Teile innerhalb des General-Parts von den Hostspezifischen überschrieben werden. Ist dem nicht so ?

Gruß

Tulip

Im Prinzip ja -aber welcher Wert für 'insecure' gilt für das 'register' in der general-section? :wink:

 

[tulip]

Im Prinzip ja -aber welcher Wert für 'insecure' gilt für das 'register' in der general-section? :wink:

Ja ok, aber dann sollte doch eigentlich gar nichts gehen und es müßte den Sipagate-Acount dessen Register dort ebenfalls aufgeführt ist auch betreffen.


Gruß

Tulip

 

[tulip]

@Netview,

Hi,

ich mal einen SIP-Debugger angeworfen und einmal ein "normales"
beenden des Gespräches simuliert (auflegen der Gegenstelle)
und außerdem mal solange den Debugger laufen lassen bis sich das ganze von selbst erledigt.

Bei der Variante wo sich das ganze von selbst erledigt sieht es so aus das ich vom SIP-Proxy ein BYE bekomme. Dann schickt der Asterisk noch ein BYE raus und das war es.
Ich würde mal sagen das (warum auch immer) mein Provider das Gespräch beendet.
Es sieht so als würde der RTP-Stream "abreißen" und daraufhin der Provider den Call auslösen. Der Effekt den beide beteiligten Endgeräte (Asterisk gerufene Stelle) haben deutet auch daraufhin.
Beide hören schlicht und ergreifend nichts mehr, einfach Funkstille.

Hat einer noch eine Idee??

 

[tulip]

Hallöle ich mal wieder,

kommt mir ein wenig wie ein Monolog vor..

Ich habe das ganze versucht mal weiter einzugrenzen und habe erstmal diverse bristuffed * Versionen durch.
bristuff-0.2.0-RC3, bristuff-0.2.0-RC3a, bristuff-0.2.0-rc2b und bristuff-0.2.0-RC5. Überall das gleiche Ergebniss, Sipgate funktioniert und bei GMX ist nach 30 Sekunden funkstille, aber nur in das Festnetz. Diverse Handynetze (0175, 0170, 0172, 0160) funktionieren (ich denke nach ca. 5 Duzend Anrufen kann man da eine Aussage treffen).
Ich habe jetzt mal eine Mail an den GMX-Support losgetreten, mal sehen was die dazu sagen. Wenn das ganze scheitern sollte wird mir wohl nichts anderes übrig bleiben als dem * eine Absage zu erteilen, schade eigentlich.

eventuell hat irgendjemand noch eine Idee, ich kann mir nicht vorstellen das ich der einzige bin mit einem * bei GMX, oder etwa doch?


Gruß

Tulip

 

[rajo]

Moin,

guck mal hier, das Posting von Hupe:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=11354&highlight=
evtl. hilft das

 

[tulip]

Hi rajo,

vielen Dank für deinen Tipp.
Den Link hatte ich auch schon mal zu Gesicht bekommen ihn aber weiter nicht beachtet, da mein Cisco einen SIP-Fixup hat. Wie ich jetzt bemerkt habe funktioniert der nicht so dolle.
Ich habe meinem * mal eine offizielle IP verpasst und schon funktioniert das ganze.
Danach habe ich mal wieder meine PIX ausgegraben und genated mit dem Ergebnis das es auch funktioniert (die berherbergt ebenfalls besagten SIP-Fixup)
Dann wieder den Router dran mit dem Eintrag meiner DynDNS-Domain und schon löppt das ganze. offensichtlich ist das IOS des Routers ein wenig buggy was die SIP-Funktionen angeht
Jetzt ist wohl IOS testen angesagt. Wenn ich ein passendes finde werde ich es hier posten.

Was ich ein wenig komisch finde ist das, das Gespräch aufgebaut wird und nicht gleich die Verbindung beendet wird. Ich schätze mal das, das IOS des Routers ca. 30 Sekunden die Pakete umschreibt und dann den Dienst versagt.
Außerdem die Tatsache das die diverse Handynetze ohne Schmerzen funktionieren.

 

[tulip]

[gelöst] Asterisk mit GMX Account hinter Firewall

so nachdem ich eine Zeit lang pausiert habe bin ich das Problem noch mal angegangen und wollte hier mal meine Erfahrungen kundtun. eventuell gibt es ja den einen oder anderen der ähnliches vorhat.

Ziel war es eigentlich meine PIX abzulösen wegen einer (noch) fehlenden QOS-Funktionen. Ansonnsten ist die PIX in Verbindung mit VoIP speziell mit SIP nur zu empfehlen, alldieweil keinerlei statische Nat-Einträge zum * notwending sind.

Das ganze sollte dann aber in Verbindung mit meinem GMX-Account noch laufen. Mit einem IOS-Router der QOS beherrscht ist das mit GMX nicht zu machen da nach ca. 30-50 Sekunden die Verbindung abbricht. Sieht nach einem Bug in der Software aus.

Also habe ich mich nach etwas anderen umgesehen. Da ich mich vor geraumer Zeit mal mit dem IPCOP beschäftigt hatte fiel die Entscheidung ihn. das ganze sollte ja auch auf einer Maschine laufen die, die Firewall auf einer Compact-Flashcard beherbergt. Da der COP sehr schlank ist drängt er sich wegen zusätzlichen Funktionen mehr oder weniger auf.

Die Installation war kein Problem, nach ca 20 Mintuten lief der IPCOP wie ich es wollte, bis auf.... VoIP via GMX-Account. Yes genau so mag ich es. Mehrer Nächte lesen, testen und tüffteln für die Katz.

Eine Registrierung war dauerhaft nicht möglich, vom telefonieren mal abgesehen. Innerhalb des RTP-Streams tauchte wieder mal meine Private-Address auf und GMX kloppte das Gespräch in die Tonne. Es hilf auch nicht mit den bekannten * Parametern externhost und externip herumzuspielen.

Ein weiteres Problem war noch nach einem IP Wechsel (ich gehöre zu dem Sparbrötchen die sich keine feste leisten können/wollen)

Aufgrund der Problematik mit IPTables (Verbindungen werden im Nat-Table gehalten mit der alten Public-IP)

Das ganze lies sich nur umgehen wenn ich den * solange schlafen legt bis die Verbindungen rausflogen. Sch.....

Also wieder mal umgeschaut was es so gibt, da fiel mein Auge auf Siproxd. Also runtergenuckelt und auf einer IPCOP-Development umgebung kompiliert, das ganze dann auf meinen IPCOP installiert ein wenig getüftelt was die Einstellungen angeht und voila es funktioniert.

Zugegebenermaßen gibt es einen kleinen Haken, ich musste auf den COP externe Verbindungen auf die RTP-Ports und UDP 5060 zulassen. Aber das nehme ich hin solange der Kram ohne Reload-Script und Neustarten diverser Dienste funktioniert.

So nun kam es auf das QOS an, deshalb war ja der ganze Aufriss.

Das l7filter Paket für den IPCOP installiert Script zusammengesucht, abgeändert getestet irgendwann lief auch das.

So das Ende vom Lied ist jetzt das, das ganze auf einem IPCOP 1.46 mit Siproxd und i7filter Paket mit QOS läuft und in einer Qualität die mich ehrlich gesagt positiv verwundert. Bei einem Testdownloads ist die Sprachqualität wie ich finde sehr gut (in beide Richtungen wohlgemerkt). Falls es den einen oder anderen interessiert kann ich das Qos-Script mal posten.

So jetzt ist gut