Cisco 7940G Konfiguration für T-Online

[REigner]

Hallo,

ich habe heute mein Cisco 7940G Telefon bekommen und möchte damit
nun bei T-Online meine Freiminuten nutzen...

Allerdings komme ich mit der Konfiguration leider nicht klar.
T-Online liefert ja eine Vielzahl von Daten, wobei in der Cisco
SIP-Konten Konfig nur sieben Punkte sind.

Hat das schon jemand am laufen und kann mir sagen wie die
Parameter im Telefon gesetzt werden müssen, damits mit dem
Nachbarn klappt?

TIA
Reinhard

 

[RB]

Hallo, Reinhard, und willkommen im Forum!

Hilfe-Seite von T-Online zum Thema bietet eigentlich alle Informationen.

Ich habe es selber nicht ausprobiert, aber theoretisiere hier mal:

proxy1_address: "tel.t-online.de"    ; Can be dotted IP or FQDN
# Proxy Server Port (default - 5060)
proxy1_port: 5060 
# Line 1 appearance
line1_name: "<Rufnummer (032222....)>"   ; ohne Leerzeichen/Sonderzeichen!
# Line 1 Registration Authentication 
line1_authname: "<T-Online-E-Mail-Adresse>"  ; Kleinbuchstaben z.B. "[email protected]"!
# Line 1 Registration Password
line1_password: "........"
# Line 1 Display Name (Name, der beim Angerufenen angezeigt werden soll)
line1_displayname: "<eigener Name>"
# Line 1 Short Name (Name, der fuer die Line-Taste benutzt werden soll)
line1_shortname: "T-Online"

Probier's mal aus und gib dann Rückmeldung. Viel Spaß!

 

[REigner]

Hallo RB,

ich habe mir mal die SIPdefault und SIPmacadress vom
Cisco Einstieg Thread geladen und die T-Online Daten eingetragen.
Dazu habe ich mir noch einen Account bei SIPgate geholt und diesen
für die Line2 definiert.

Jetzt kann ich mich nur vom Festnetz aus anrufen (zu T-Online).
Abgehend steht im Display nur "Calling (out INV)"

Wenn ich auf der console einen "debug sip-task" absetze bekomme
ich Folgendes:

SIPTaskProcessMessage: Line filter: Determing destination line ...
SIPTaskProcessMessage: Line filter: Previous Call ID. Message not in reTx list.
SIPTaskProcessMessage: Line filter: Call ID match not found: Rejecting.

2. Versuch

Ich habe daraufhin den sipgate account entfernt. Nun funktionierts
abgehend aber wenn ich am Festnetz abhebe habe ich am
7940G weiterhin das Freizeichensignal.
Im Display: Ringing destination (in 180)"
Auf beiden Telefonen hört man nichts vom anderen.
Ankommend höre ich nur auf dem Festnetz Sprache, jedoch auf
dem 7940G nicht.

3. Versuch

Im Router (Draytek Vigor 2200E) folgende Portbereiche geöffnet:
16384-32766 UDP (diesen Bereich habe ich deswegen erhöht, da T-Online ja 30000-30005 benutzt, oder ist das hier was anderes?)
5060 UDP
5070 UDP
3478 UDP
3479 UDP
80 TCP

Nun habe ich das "normale" Freizeichen über dem Cisco-Freizeichen,
also ich habe nun mit leichtem Versatz zwei Freizeichen in der Leitung.
Das angerufene Festnetztelefon kann nun die Sprache zum 7940G
übertragen, aber auf dem Festnetztelefon kommt keine Sprache an.
Wenn ich mit dem Festnetz anrufe, geht die Sprachübetragung wieder
in beide Richtungen.

Wenn ich die Ports, welche bei T-Online angegeben sind zusätzlich
forwarde passiert gar nichts - alles bleibt gleich.

Was soll ich denn nun einstellen?
Ach ja, nach einigen abgehenden Anrufen mit oben genanntem
Problem, kommt nur noch "Reorder" und sofort besetzt.
Wenn ich den Strom vom 7940G abziehe und damit neu starte
funktioniert es wieder...


HILFE, ist das kompliziert

 

[REigner]

Ach ja: Die Firmware ist 7.5

 

[CTU]

Hallo Reinhard ,

also ich weiß , dass die meisten hier im Forum mit der SIP-Version 7.5 Probleme hatten , was die Sprachübertragung angeht.

Aufgrund mangelnder Erfahrung kann ich dir jetzt nicht sagen , ob bei dir vielleicht auch andere Einstellungen falsch sind , aber mit einem Downgrade auf 7.4 waren die meisten hiesigen User gut beraten.

Warte einfach mal die Antwort von RB ab und dann sehen wir weiter. :wink:

CTU

 

[REigner]

Hallo,

ich bin nun Deinem Rat gefolgt und habe mir bei Cisco die Firmware 7.4 gezogen und aufgespielt.
Man glaubt es kaum - es funktioniert, zumindest was die Tests bis jetzt angeht.
Hätte ich nicht gedacht, daß mit einem Firmwaredowngrade alles getan ist. Wurde wohl nicht recht getestet.. :?

Dann muß ich auch noch herausfinden, wieviel Einträge ich aus dem Router wieder entfernen kann, denn ich will die Einträge möglichst gering halten.
Ein Draytek ist schließlich kein Cisco, dem man ne seitenlange Konfig reinladen kann ;-)


cheers
Reinhard

 

[CTU]

Freut mich , dass Fortschritte zu verzeichnen sind.
Ja , also leider hat 7.5 noch etliche Bugs und daher 7.4.
Habe ich auch auf meinem 7960 und das ist die im moment neueste verlässliche Firmware.

Wünsche weiterhin gutes gelingen !

CTU

 

[RB]

Moin!

Tja, die 7.5 ist leider eher unbenutzbar. Ich hatte auch die Probleme, daß das Telefon nach einiger Zeit sogar komplett eingefroren war und nur noch ein Reset geholfen hat. Mit 7.4 ist es deutlich besser zu betreiben.

Zu den Ports:
Grundsätzlich sind alle Portangaben Client-spezifisch, haben also nichts mit dem Provider zu tun. Du mußt die Ports ans Telefon weiterleiten, die Du mit voip_control_port und start_media_port bis end_media_port festgelegt hast. Alles sind UDP-Ports. Der Rest ist zumindest für das Cisco-Telefon irrelevant.

Hier im Forum gibt es noch ein paar Threads, die sich mit den RTP-Ports (aka Media-Ports) und deren Parametrierung im Cisco befassen. Da gibt es auch noch ein paar kleine Stolperstellen dahingehend, daß das Telefon nicht immer die Eintragungen für den Start- und Ende-Port übernimmt. Das sind ebenfalls Firmwarefehler. Zum Glück kann man das aber gut per Telefon-Menü kontrollieren...

 

[REigner]

Hi,

wegen den Ports muß ich halt mal suchen oder hast Du gleich nen Link für mich?

Wenn das Clientspezifisch ist, warum sagt mir T-Online, ich solle die Ports,
welche ich weiter oben schon aufgezählt habe, freischalten.
Oder meinst Du, die haben ihr Softwaretelefon so vorkonfiguriert?
Wieviele RTP-Ports brauche ich eigentlich? Könnte ja auch nur einen oder zwei angeben...

Portweiterleiten mußte ich nicht - nur die Ports generell öffnen, und selbst
da bin ich mir noch nicht ganz sicher ob das nötig ist.
Heute bin ich wieder zuhause und kann das Telefon an meinem Router,
auch Draytek, aber 2600Gi, ausprobieren.
Am 2200E gabs Probleme mit dem DNS. Dafür gabs aber ne Firmware,
die genau dieses Problem am Router behebt.


Grüße
Reinhard

 

[RB]

T-Online ist halt Telekom - die erzählen schnell mal irgendwas ohne fundierte Kenntnisse. Ich habe damit auch schon so meine Erfahrungen gemacht. Ausnahmen sind hier nur die Techniker, an die man aber nur schwer drankommt. Ich habe schon öfter damit Erfolg gehabt, daß ich die Call-Center-Mitarbeiter solange mit Fachbegriffen bombardiere, bis sie freiwillig zur Technik durchstellen ;-)

Ich gehe davon aus, daß es sich bei den Angaben um eine Mixtur aus den Einstellungen verschiedener Clients handelt - wohl weil man den Mitarbeitern nicht zutraut/zumuten möchte, detailliert nachzufragen, was denn nun eingesetzt wird. Das würde ja auch erhebliche Kenntnisse respektive eine größere Datensammlung voraussetzen.

Die Thematik mit der Portweiterleitung bzw. Portöffnung hat mir schon öfter ein :? abverlangt. Mir ist nicht klar, wie ein Router wissen soll, wohin die Daten für einen bestimmten Port denn nun geschickt werden sollen, wenn man es nicht explizit als Weiterleitung angibt ?!
Außerdem ist mir auch nicht klar was dieses "Öffnen" von Ports eigentlich sein soll. Das ist auch alles eine Frage der Terminologie des jeweiligen Herstellers bzw. Übersetzers.

Wenn's bei Dir so läuft - prima!

Zu der Anzahl Ports: Generell würde ich mindestens zwei vorsehen. Das hängt aber auch mit der Anzahl gleichzeitig aufgebauter Gesprächsverbindungen zusammen. Ich selber habe immer 5-6 RTP-Ports je Endgerät vorgesehen (und weitergeleitet )

 

[REigner]

Ich habe nochmal nachgelesen:
Eine Portöffnung ist idR nichts anderes als eine Portweiterleitung, aber:

- bei der Portöffnung kannst Du Portbereiche angeben, aber die Zielports bleiben gleich
- bei der Portweiterleitung kannst nur einen Port angeben, diesen aber auf einen anderen Zielport umleiten

LAN IP-Adresse muß man ja bei beiden angeben.

Und forwarden muß ich die Ports, weil die mit UDP arbeiten.
Wären das TCP-Ports müßte es eigentlich auch ohne Forwarding funktionieren, da Du ja sagtest, das RTP clientinitiiert ist...

Gruß
Reinhard

 

[RB]

OK, dann ist das "Port öffnen" bei Deinem Router einfach eine der Varianten des Port Forwardings bei mir. Leider ist die Terminologie nicht wirklich einheitlich.

da Du ja sagtest, das RTP clientinitiiert ist...

Nee, das ist ein Mißverständnis. Die Realtime-Streams können durchaus von draußen gestartet werden. Der Client sagt nur der Gegenseite, welche Ports dafür genommen werden sollen (über den Kontroll-Port, meist 5060). Grundsätzlich kann bei SIP alles von beiden Seiten aus initiiert werden.

Daher auch die Notwendigkeit, daß die eigene öffentliche IP-Adresse allen Beteiligten bekannt und die Ports von draußen erreichbar sein müssen.

 

[REigner]

Gut. Mit dem SIP-Protokoll muß ich mich mal genauer beschäftigen.
Mit dem STUN-Server braucht man ja diese Portforwardings nicht, oder?

 

[RB]

Die STUN-Geschichte ist eigentlich ein recht ausgeklügeltes Test-Verfahren, das dem STUN-Client ermöglichen soll, festzustellen, welche Art von NAT (bzw. ob überhaupt NAT) zwichen ihm und dem STUN-Server existiert. Es wird auch ausprobiert, ob man von einer anderen IP-Adresse (Ein STUN-Server ist immer eine gespaltene Persönlichkeit mit zwei Adressen) auf den abgehenden Port der STUN-Abfrage antworten kann, oder ob das nur für die ursprüngliche Adresse klappt. Außerdem wird die öffentliche IP-Adresse ermittelt.

Aufbauend auf den Ergebnissen wird dann wohl der ermittelte externe Port den Providern als zu benutzender Port mitgeteilt. Damit macht man sich die Tabelle der NAT-Einträge zunutze, um von außen ein Loch durch den Router zu finden. Ist m.E. aber keine sonderlich zuverlässige Lösung, da es ja je nach NAT-Variante auch wieder Timeouts gibt, die die Tabelleneinträge zumindest für UDP nach einer Zeit ohne Datenfluss (bei den RTP-Ports ja normal) wieder löschen. Eine bessere Chance hat man da wohl mit dem Kontroll-Port.

Bei "gehobenen" Router-Varianten mit symmetrischem NAT geht sowas gar nicht (abgesehen von der Ermittlung der öffentlichen IP-Adresse).

Das war jetzt das, was ich mir so zusammengereimt habe - wirklich intensiv nachgelesen hab ich das nicht, da es bei mir sowieso nicht funktioniert (ich habe symmetrisches NAT).