Connect- und Sprachprobleme mit Cisco 7940 SIP 7.3

Hallo,

setz den start_media_port auf 16384 und den end_media_port auf 16388 und leite die Ports auf deinem Router weiter.
Das 7940 nimmt nicht alle Port-Ranges die man ihm anbietet, ist ein wenig wählerisch

P.S.: Willkommen im Forum!

Hallo,

gehe ich richtig in der Annahme, dass die Aussage auch für das 7960 gilt, sprich dass die Ports 16384 bis 16388 zu verwenden sind?

Das könnte ein ähnliches Problem lösen, welches ich mit dem 7960 und Sipgate habe. Auch bei mir ist die Anmeldung "unsauber", in der Art wie es Dune_2021 unten beschreibt. Hatte auch schon meinen ADSL Router Zyxel Prestige 642 in Verdacht bzw. dass das NAT nicht richtig vom 7960 erkannt wird.

Werde es mal mit den beschriebenen Ports und entsprechender Portforwarding versuchen.

Danke & Gruss, Guido

Hallo Guido,

bestätigen kann ich das für das 7960G nicht definitiv, mangels Testmasse ;-)

Die beiden Telefone sind aber von der Hard- und Software zu 99% identisch.

Moin!

Das 7960 hat genau die gleichen Probleme mit den RTP-Port-Angaben wie das 7940. Ist ja auch die gleiche Firmware...

Manche Angaben klappen, andere wiederum nicht. Das ist ein interner Berechnungsfehler der Firmware.

Für Neugierige oder Leute der Gattung Bit-Beißer: Man kann das schön sehen, wenn man Debugging aktiviert. Da gibt es bestimmte Ausgaben, wo man dann den Rechenfehler in der Hex-Kodierung gut erkennen kann

Ralf,

hast Du das mal an Cisco weitergeleitet? Oder falls Du das ein wenig deatillierter schildern kannst, könnte ich versuchen das Problem an unsere Cisco Support Leute weiterzugeben.

Gruss Guido

Moin!

Da Cisco ja kein Interesse an Endkunden hat und die SIP-Firmware auch recht stiefmütterlich behandelt wird, habe ich darauf verzichtet.
Außerdem darf man nicht vergessen, daß ich ja seit August auf meine Lizenz warte, also eigentlich die Firmware gar nicht habe...

Für die Details müßte man eine Debug-Session starten bei geänderten RTP-Ports. Wenn man die sip-*-Debugs einschaltet und dann eine Anruf startet, bekommt man auch die Angaben der intern verwendeten RTP-Ports. Ich habe das dann mit verschiedenen RTP-Port-Einstellungen gemacht. Wenn man den richtigen Debug aktiviert, bekommt man auch mit, wie das Cisco die Menüeinträge bei Änderung ausliest und konvertiert. Das ist dann aber SEHR umfangreich! Ich habe mir das ganze damals nicht abgespeichert, weil ich das Telefon mit SIP-Firmware sowieso als ein Beta-Produkt einstufe. Es hat noch diverse Macken...

Cisco 7960, Ports & ISH Kabel

Hallo Mitstreiter,

von Ports kann ich Euch auch so richtig einen erzählen! Ich habe die Flat Plus - Leitung von ISH. Kabelmodem von den Herrschaften bekommt man ja gestellt. Zusätzlich habe ich für die Dame des Hauses ISH Telefon bestellt. Dann steckt man ein analoges Telefon einfach in das Kabelmodem.

Seitdem ich das Cisco 7960 nutze, habe ich aber folgendes Problem:

Wenn ich ein Gespräch über Sipgate oder auch GMX führe, und meine Freundin ein Gespräch auf der ISH - Leitung annimmt oder selbst initiiert kann ich bei meinem Gespräch von meiner Gegenstelle nicht mehr gehört werden!
Ich dachte natürlich: Port überlappung oder ähnliches. Und direkt mal Ish gefragt, welche Ports denn von deren proprietärer VoIP-Technik von meiner Leitung genutzt werden. Die Herrschaften behaupten jedoch, daß deren "Telefonleitung" vollkommen unabhängig von der Internetleitung sei und ich deshalb beim VoIP-Anbieter nachfragen sollte! Ja sicher....

Die einfachste Lösung wäre sicherlich, einfach die Ports zu ändern. Einfacher gesagt als getan. Die "Fehler" in der Cisco-Firmware haben meine Vorredner ja bereits erwähnt. Dazu vielleicht eine kleine Ergänzung: Alle Ports >= 16384 können im Cisco eingetragen werden. Darunter geht allerdings nichts. Meine Vermutung geht nun natürlich dahin, daß genau diese Ports auch vom ISH-Kabelmodem, und zwar ALLE verwendet werden. Ich habe Stichproben bis hoch auf 32766 gemacht und jedes mal wenn ich ein Gespräch auf der ISH-Leitung aufgebaut habe (an dieser Stelle ein Dank an die kostenlose T-Com - Hotline) hört mich meine Gegenstelle nicht mehr. Sobald ich das ISH-Telefonat beende kann mich die Gegenstelle wieder verstehen.
Das kann doch nicht am Router liegen oder wie seht Ihr das? ISH verhält sich da völlig stur. Ist ja klar, die wollen natürlich am liebsten, daß ich noch ne zweite Telefonleitung von denen für weitere 10 Euro dazuschalten lasse. Aber dann kann ich mir ja direkt DSL und ISDN holen. Diesbezüglich sind die ISH-Preise definitiv zu hoch. Aber das tut ja auch nichts zur Sache, schließlich wollen wir hier VoIP nutzen!

Hat vielleicht jemand eine idee, wie man das Cisco-Telefon auf andere Ports < 16384 zwingen kann? Oder vielleicht noch einen anderen Vorschlag? Bin für jede Hilfe dankbar.

Grüße,
Dermolch2

Ich habe gerade nochmal die Ports > 32766 getestet, und muss leider berichten, daß unser Cisco auch diese vollständig ablehnt. Es ist also nur ein Portbereich von 16384 bis 32766 möglich.

Wenn also jemand eine Idee hat....

Moin!

Bemerkung am Rande: Als ich mit den RTP-Ports gekämpft habe, konnte ich auch im genannten Bereich längst nicht jede Port-Kombination nutzen (ursprünglich wollte ich die 30000..30005 haben). Die Eingaben wurden entweder erst gar nicht angenommen oder aber falsch interpretiert (kamen intern völlig andere Werte an, als eingegeben, egal ob per Datei oder Menü). Das war allerdings FW 7.1. Hat sich ja vielleicht verändert (verbessert?) mittlerweile.

@dermolch2
Ich kann mir eigentlich nicht vorstellen, daß das Kabelmodem (oder ish-seitig der entsprechende Router) einen ganzen Port-Range sperrt. Damit würden sie ja den Internet-Zugang effektiv lahmlegen. Es handelt sich ja hier um die Richtung nach draußen. Dort ist ein (Source-)Port aus diesem Bereich eigentlich völlig normal. Auch für gänzlich andere Anwendungen!

Aber um das auszuprobieren, müsste man mal einfach ein paar Verbindungsversuche auf verschiedenen Ports in beide Richtungen machen. Sofern Du einen einigermaßen brauchbaren Router mit einer vernünftigen Log-Funktion hast, wird er ja Verbindungsversuche von außen als "Einbruchsversuche" oder so protokollieren. Das gleiche sollte dann beim Gegenüber möglich sein. Fehlt nur noch ein geeignetes Tool. Unter Linux kein Problem, denke ich. Da gibt es genug Netzwerk-Werkzeuge, wo man sowohl Source-, als auch Destination-Port frei wählen kann.