kurz vorm Wahnsinn versuche ich nun schon seit Tagen eine lauffähige
Konfiguration zu meinem VoIP Provider PBX-Network (oder Sipgate) zu er-
stellen. Interessanterweise funktionieren eingehende Gespräche problemlos,
doch abgehend kommt keine Verbindung zustande.
Obwohl ich keinen Outbound Proxy aktiviert habe, erscheint im Fenster “Status
VoIP Accounts” unter Outbound Proxy: 480 Temporarily unavailable. Dies er-
scheint nach dem Verbindungsversuch, ich erhalte ein Besetzt.
Um irgendwelchen NAT Problemen zu begegnen, betreibe ich die Anlage
mittlerweile an zwei festen, öffentlichen IP Adressen. Da stellt sich mir
sowieso schon die Frage, ob hier vielleicht schon ein Problem auftaucht.
Die 6000er hat als TK-Anlage die “.5” und das VoIP Modul die “.6” … Was
läuft eigentlich über das VoIP Modul für ein Verkehr? Registriert lt. Pro-
vider Übersicht ist die “.5”. Es ist kein STUN und kein NAT (für SIP und RTP)
aktiviert. In der Firewall sind im Moment für Testzwecke alle Ports bidirek-
tional geöffnet. Also total offen in/aus Richtung Internet.
Sowohl PBX-Network als auch Sipgate verhalten sich gleich …
Was mache ich falsch?
vG Michael
P.S: Man möge mir den Doppelpost hier und im IP-Phone Forum verzeihen,
da ich doch recht zeitnah eine Lösung suche.
auf dem VoIP-Modul sitzt ein recht fähiger DSP, der die Codecs rechnet. Mit anderen Worten läuft auf der .5 bei Dir die SIP-Kommunikation. Beim Gesprächsaufbau wird dann ausgehandelt, daß sämtliche RTP-Daten vom und zum Modul - sprich IP .6 - über dieses laufen sollen. Eine ggf. vorhandene Firewall sollte sozusagen die dynamisch ausgehandelten RTP-Ports zur VoIP-Modul-IP durchlassen können.
Damit habe ich zwar keine Lösungsidee, aber evtl. hilft Dir das Funktionsprinzip bei der Fehlereingrenzung.
an die RTP Ports habe ich eigentlich auch schon gedacht. Hast Du eine
Erklärung, dass nur abgehend Richtung Provider nicht telefoniert werden
kann, aber eigehend einwandfrei. Wenn die RTP Pakete nicht kommen
würden, dann wären doch auch kommende Gespräche betroffen.
Ergänzung:
Kommen mit dieser Lösung SIP über IP x und RTP über IP y vielleicht nur
wenige SIP Provider klar? Währenddessen Sipgate und PBX-Network sind
doch schon größere am Markt …
So richtig erklären kann ich das auch nicht, was in Deinem Fall schief gehen könnte. Da fehlen aussagekräftige Protokollmitschnitte.
[quote]Kommen mit dieser Lösung SIP über IP x und RTP über IP y vielleicht nur wenige SIP Provider klar? Währenddessen Sipgate und PBX-Network sind
doch schon größere am Markt[/quote]Die Idee, daß die Provider - warum auch immer nur in eine Richtung - mit den zwei öffentlichen IPs nicht klar kommen ist mir auch schon durch den Kopf gegangen. Vlt. hat das noch keiner so benutzt? Nahezu jeder, der das so benutzt hängt in irgendeiner Form hinter einem NAT und taucht damit aus Sicht des SIP-Providers nur mit EINER öffentlichen IP auf.
Du wirst für eine Problemlösung um einen Wiresharkmitschnitt nicht herum kommen…
Dieses Jahr werde ich mich für meinen Teil ausklinken…
Guten Rutsch!
Dauerbesetzt
bevor ich jetzt ins neue Jahr starte, noch ein paar Randbemerkungen, die
ich Aufgrund meiner Testerei bemerkt habe.
Also die Auerswald hängt an einer Astaro Firewall, es ist sowohl der VoIP
Proxy eingeschaltet als auch bidirektional auf .5 + .6 alle Ports freigeschal-
tet. Es dürfte also eigentlich kein Problem geben …
Ich habe Ninja (ein sehr guter SIP Client = Monatelang im Einsatz und nur
beste Erfahrungen damit gemacht) auf meinem Notebook installiert, mit O2
UMTS Karte und kann mich in die Auerswald einloggen. Kann vom Notebook
als auch von Heimapparat Verbindungen zur "außenliegenden Nebenstelle"
aufbauen. Verständigung perfekt …
Eingehende Gespräche von den VoIP Providern funktionieren einwandfrei,
auch die Rufverteilung bereitet keinerlei Probleme. Verständigung ebenfalls
auch über einen längeren Testanruf 3-5 Minuten problemlos.
Aber sobald ich ein Gespräch vom Heimapparat in Richtung VoIP Provider
aufbaue, erscheinen Fehler 480 = PBX-Network oder “KlickKlack” Fehler 404
= Sipgate. Bei letzterem kann es aber an Sipgate liegen, da die Umstellung
auf “Trunking” zwar durchlaufen wurde, aber die Rufnummernverlängerung
noch aussteht (Datenbankproblem bei denen, Support arbeitet seit 2-3
Tagen daran … Aber jetzt ist ja Wochenende und Silvester)
Vielleicht siehst Du oder ein weiterer Mitleser hier irgendwelche Fehler-
quellen oder Parallelen die zur Lösung beitragen.
wenn nur ausgehende Gespräche Probleme bereiten: Welches Rufnummernformat ist denn in der Anlage für Sipgate eingetragen? Falls nicht “ohne Landesvorwahl” eingetragen ist, versuchs mal damit.
Ansonsten wäre ein Netzwerkmitschnitt wirklich die beste Möglichkeit den Fehler zu finden. Sipgate läuft sonst eigentlich absolut problemfrei.
ich habe soeben den Verbindungsaufbau mitgeschnitten. Mir fällt auf, dass
sowohl bei Sipgate als auch bei PBX-Network ganz offensichtlich die führende
Null bei der Zielrufnummer fehlt. Ich habs mal ein wenig “verfremdet”, muss ja
nicht die Originalrufnummer hier öffentlich angegeben werden. x=zahlen. Klar
Ich hab jetzt zwei verschiedene Formate der gewählten Rufnummer, einmal
mit +49 und einmal ohne Landesvorwahl … getestet. Etwas irritiert bin ich,
dass ich keine Änderung des Formats feststellen kann?! Sollte die
fehlerhafte Rufnummer wirklich das Problem sein, so wäre es logisch, dass
es zu einer Fehlermeldung kommt.
Habt ihr eine Idee, wie man die führende Null mitgeben kann? Als Amtsvorwahl nutze ich 1801 für PBX, 1800 für Sipgate …
Wähle also am Telefon:
180106327xxxxxxx (oder 180006327xxxxxxx) als Zielrufnummer.
In der Auerswald habe ich unter Grundeinstellungen:
180106327xxxxxxx (oder 180006327xxxxxxx) als Zielrufnummer[/quote][quote]Habt ihr eine Idee, wie man die führende Null mitgeben kann?[/quote]Na wäre es dann nicht naheliegend einfach die Amtholungsnull hinter dem Account noch mitzuwählen - so, wie in der Hilfe für “nichtdirekte” Amtapparate auch beschrieben?
In Deinem Fall also 1801006327xxxxxxx.
Wenn Die Accountnummer nicht vorwählen würdest, würdest Du ja auch eine Null mehr wählen, um an das Amt zu kommen. Die andere Möglichkeit wäre die Teilnehmer auf “Direkten Amtapparat” zu stellen.
Ich denke das erklärt das Verhalten. SIP-Provider akzeptieren i.d.R. nur Nummern mit Ortsvorwahl - und die fangen immer mit einer Null an.
Klar könnte man jetzt Denken, daß die Anlage ja bei einer Accountnummer weiß, daß es zum Amt geht. Hintergrund ist sicherlich, daß man - egal ob man die Accountnummer vorwählt - immer das selbe Rufnummernformat hat. Das ist z.B. bei Wahlen aus Rufnummernspeichern sinnvoll. So wählt man immer die eingespeicherte Nummer und muß nicht jedesmal eine Null hin- oder wegmachen, wenn man über den Account geht - oder halt nicht.
Gruß Dauerbesetzt
PS: Du schriebst ja, daß Du bis jetzt mehr aus der Asterisk-Ecke kommst. Dort gibt es diese Unterscheidung mit Internen und Externen Accounts nicht. Das ist bei “klassischen” Telefonanlagen oft anders.
Sack und Asche … Darauf wäre ich im Leben nicht gekommen!!
[quote=Dauerbesetzt]Hi Michael,
Na wäre es dann nicht naheliegend einfach die Amtholungsnull hinter dem Account noch mitzuwählen - so, wie in der Hilfe für “nichtdirekte” Amtapparate auch beschrieben?
In Deinem Fall also 1801006327xxxxxxx.
[/quote]
Mit beiden SIP Provider funktioniert es … Danke Dir für den Tip!!!
Dabei stellt sich mir natürlich zwangläufig ein paar Fragen:
Ich habe mehr oder minder “willkürlich” die 1800…n für VoIP "Vorwahl"
gewählt. Gibt es hier vielleicht von Deiner Seite einen Tip, was sinn-
voller ist? 0 für Telekom, 1 für VoIP 1 … 9 für VoIP 9 Provider? Doch
habe ich in der Anleitung gelesen, dass bei zu kurzen Kurzwahlen hier
ich mir ganze Zahlenbereiche blockiere. 3 Vorwahl alle 30, 300, 3000
würde nicht mehr funktionieren. Was nimmst Du für diesen Fall?
Kann man die “zusätzliche Null” gut umschiffen und ggf. automatisch
voranstellen kann?
Sack und Asche … Darauf wäre ich im Leben nicht gekommen!!
[quote=Dauerbesetzt]Hi Michael,
Na wäre es dann nicht naheliegend einfach die Amtholungsnull hinter dem Account noch mitzuwählen - so, wie in der Hilfe für “nichtdirekte” Amtapparate auch beschrieben?
In Deinem Fall also 1801006327xxxxxxx.
[/quote]
Mit beiden SIP Provider funktioniert es … Danke Dir für den Tip!!!
Dabei stellt sich mir natürlich zwangläufig ein paar Fragen:
Ich habe mehr oder minder “willkürlich” die 1800…n für VoIP "Vorwahl"
gewählt. Gibt es hier vielleicht von Deiner Seite einen Tip, was sinn-
voller ist? 0 für Telekom, 1 für VoIP 1 … 9 für VoIP 9 Provider? Doch
habe ich in der Anleitung gelesen, dass bei zu kurzen Kurzwahlen hier
ich mir ganze Zahlenbereiche blockiere. 3 Vorwahl alle 30, 300, 3000
würde nicht mehr funktionieren. Was nimmst Du für diesen Fall?
Kann man die “zusätzliche Null” gut umschiffen und ggf. automatisch
voranstellen kann?
Danke nochmals!!
vG Michael
P.S: Ist das jetzt ein Feature oder ein Bug in der Auerswald Firmware?
[quote]P.S: Ist das jetzt ein Feature oder ein Bug in der Auerswald Firmware? [/quote]Wie ich schon versucht habe zu erläutern - denke ich daß das ein Feature ist.
I.d.R. sagst Du ja nicht bei jedem Gespräch vorher, über welchen Provider der Weg zum Amt gebahnt werden soll. Das sollte ja möglichst die Anlage automatisch machen. Was ich versuche zu erklären ist, daß der Anwender ja möglichst einfach nur die Nummer wählen soll und die Anlage den günstigsten Weg kennt. Also speichert man in sein - z.B. analoges DECT-Telefon - die Nummer so wie sie ist mit Amtholungsziffer.
Wenn man jetzt doch mal - warum auch immer - explizit über einen VoIP-Account gehen möchte wählt man diesen und kann die Nummer so wie sie aus dem Rufnummernspeicher des Telefons kommt übernehmen.
Mal so und mal so wäre leicht verwirrend. Dann doch einfach IMMER mit dieser Null.
[quote]Was nimmst Du für diesen Fall?[/quote]Ich habe da irgendwelche vierstelligen Nummern eingetragen, da ich die Accounts nicht ausdrücklich auswähle. Ich benutze das Automagische Routing der Anlage. Über die Prioritätensteuerung und Rückfall auf ISDN, wenn z.B. alle VoIP-Kanäle dicht sind denke ich da gar nicht drüber nach…
Gruß und gute Nacht
Dauerbesetzt
PS: schön jedenfalls, daß das gelöst werden konnte
schließe mich Deiner Argumentation an, ist eher ein Feature … Eigentlich
auch logisch, die 0 mitzuwählen, heißt ja “Amt” und da spielt es eigentlich
keine Rolle, wo das Amt letztendlich liegt … Bei CbC ist es ja eigentlich
ähnlich bis gleich …
versuche ich nun schon seit Tagen eine lauffähige
