Konflikte zwischen ISDN-PPP-Einwahl und Voice-Call-Manager ?

[Koppelfeld]

Hallo,
ein Kunde setzt einen 1781VAW mit der All-IP-Option ein, und zwar in der sinnvollen Variante, in der der Router einen ISDN-Anschluß aufnimmt und als Gateway zu einer SIP-Anlage funktioniert.

Nun wird die Telekom den VDSL-Zugang ändern. Danach muß ich auf den Router, um die neuen Zugangsdaten einzutragen. Also: Eine zusätzliche ISDN-Verbindung tut not.
Wenn ich die jetzt einrichte, mache ich mir da eine MSN "kaputt" oder ist der LANCOM so schlau, daß er anhand des Dienstemerkmals erkennt, "Es ist HDLC/PPP, route den Call nicht, sondern nimm' ihn an" ?

[garfield0815]

na ich wurde mahl benannten du machst dir auf jeden Fall eine MSN kaput (die du dann in der ISDN Einwahl Schnittstelle hinterlegen musst )

sonst weis doch der Router gar nicht das das eine Einwahl ist

[Koppelfeld]

sonst weis doch der Router gar nicht das das eine Einwahl ist

ISDN ist deutsch und von Siemens. Da ist Denken stets hinderlich.
Neben der Plesiochronizität das einzig Positive an diesem stinkenden Zwischendecksmüllhaufen unterdessen ist das 'Dienstemerkmal'.
Im VCR kann man nicht danach differenzieren, aber der Router selbst könnte, wenn er wollte, sich den Ruf aufgrund des Dienstemerkmals 'unter den Nagel reißen'.

[MoinMoin]

Moin Koppelfeld!

In der Tat, der Router bekommt den Ruf genauso gemeldet, wie auch der VCM. Daher gilt hier wieder: der Schnellste gewinnt. Rufe, die nicht als Telefonie, 3,1kHz-Audio oder FAX markiert sind, werden vom VCM allerdings auch nicht weitergeleitet.

Oder besser, wurden. Jetzt gibt es den Clearmode, der einen als UDI markierten Call ins SIP weiterleiten kann. Keine Ahnung, ob das in der Richtung auch passiert. Ist eigentlich für die Vermittlung von Rufen zwischen internem ISDN und externem SIP gedacht.

Ciao, Georg

[Koppelfeld]

Oder besser, wurden. Jetzt gibt es den Clearmode, der einen als UDI markierten Call ins SIP weiterleiten kann. Keine Ahnung, ob das in der Richtung auch passiert.

Offenbar nicht. Zum Glück für mich. Ich sage ja, Nachdenken macht einen schlechten Teint.

Im Gegensatz zum VPN ist die PPP - Einwahl einfach und logisch zu konfigurieren, ich war ja echt erstaunt.

Es tut so, wie es soll, beim Dienstemerkmal Sprache routet der VCM und bei transparenter Datenübertragung übernimmt der PPP-Stack.

Als Bonus gibt es die Option, daß die PPP-Gegenstelle ein Routing-Tag zugewiesen bekommt. Damit kriegt man, bei gecrashtem VPN, qua Differenzierung die Rückroute hin.

Blöd:
Nun habe ich ein schönes "ISDN-VPN", kann aber den Router nicht darüber administrieren, weil jener die PPP-Verbindung nicht als VPN auffaßt.

[MoinMoin]

Moin Koppelfeld!

Geht auch nicht, wenn du die als Admin-MSN hinterlegte Rufnummer verwendest?

Ciao, Georg

[Koppelfeld]

{ Bei Rückfall auf ISDN-Backup kein Wartungszugriff auf den Router }

Geht auch nicht, wenn du die als Admin-MSN hinterlegte Rufnummer verwendest?

Nein, soeben probiert. Ein kleiner Proxy auf einem fernen TK-Server hilft jetzt.

Ist ja, nebenbei, auch nicht das Falscheste: Sonst sabotiere ich die VPN-Leitung und kann dann den entfernten Router via ISDN manipulieren.

Ansonsten kann ich nur sagen:
Ganz große Klasse, die Backup-Lösung. Kinderleichtes, völlig logisches Konfigurieren der PPP-Peers, und die Idee, sowohl beim VPN als auch bei PPP zunächst keine IP-Adressen festzulegen, sondern sich diese dynamisch bei Start des Interfaces aus den Routing-Tabellen zu fischen, ist genial. Denn so kann ich für VPN und PPP-Backup auf beiden Seiten die gleichen Netze verwenden.
Das habe ich bei Vendor C aber schon deutlich umständlicher gesehen (und bis heute noch nicht richtig kapiert).