Standortkopplung ohne TK-Anlage

[AndreasMarx]

Hallo zusammen,

ich bin jetzt mal soweit, daß ich mit unter jedem Konfigurationspunkt im VOIP-Call-Manager was vorstellen kann (fragt sich nur, ob ich da immer richtig liege )

Mal 'ne Frage zu dem im Referenzhandbuch beschriebenen Einsatzszenario "VoIP-Kopplung von Standorten ohne SIP-TK-Anlage" (Kapitel 13.8.5):

Da wird vorgeschlagen die beiden LANCOMs jeweils gegenseitig als SIP-PBX-Leitung einzutragen. Hmm. Ich hätte die eigentlich eher als SIP-Provider eingetragen. Bei der ersten Variante müssen doch die Benutzer auf beiden LANCOMS konfiguriert sein. Damit sind die 16 möglichen Benutzer ziemlich schnell erschöpft. Bei der Variante "SIP-Provider" benötigt jeder LANCOM auf der jeweils anderen Seite nur einen Benutzer.

Was mich außerdem irritiert: Ich kann eine SIP-PBX-Leitung im Call-Manager als Zielleitung angeben. Was, wenn der Anrufende gar keinen Account auf der Gegenseite hat?

Ich hab beim "Versuchen-zu-verstehen" die SIP-PBX-Leitung eigentlich unter dem Thema transparenter SIP-Proxy verbucht. Diese beiden Sachen passen da aber nicht so richtig ins Bild.

Seid Ihr bitte nochmal so geduldig und klärt mich auf?

Ein leicht verwirrt dreinschauender,
Andreas

EDIT: Typo korrigiert

[suvuk]

Bei SIP-Provider kann benötigt jeder LANCOM auf der jeweils anderen Seite nur einen Benutzer.

Ein SIP-Provider im eigentlichen Sinne (z. B. Sipgate) stellt Dir ja nur eine eingegehende Nummer zur Verfügung. Du könnstest also nicht mehr unterscheiden, wer angerufen wird, wenns über den SIP-Provider (oder über die als SIP-Provider eingetragene Gegenstelle) "klingelt".

Was mich außerdem irritiert: Ich kann eine SIP-PBX-Leitung im Call-Manager als Zielleitung angeben. Was, wenn der Anrufende gar keinen Account auf der Gegenseite hat?

Dann wird entsprechend den Einträgen in der PBX weitergeroutet (sofern es wirklich eine PBX ist). Jedenfalls kennt die PBX im Gegensatz zum Provider mehrere Benutzer.

Ich hab beim "Versuchen-zu-verstehen" die SIP-PBX-Leitung eigentlich unter dem Thema transparenter SIP-Proxy verbucht. Diese beiden Sachen passen da aber nicht so richtig ins Bild.

Die SIP-PBX ist (IMHO) fähig, mehrere ein- und ausgehende Konten zu verwalten, während der SIP-Provider eben nicht wirklich unterscheiden und zuordnen kann.

Seid Ihr bitte nochmal so geduldig und klärt mich auf?
Ein leicht verwirrt dreinschauender,

Ich hoffe, Du bist jetzt nicht noch verwirrter, Du kennst ja meine inkompetenten Erklärungsversuche

[AndreasMarx]

Du könnstest also nicht mehr unterscheiden, wer angerufen wird, wenns über den SIP-Provider (oder über die als SIP-Provider eingetragene Gegenstelle) "klingelt".

Hallo Suvuk,

das müßte ich dann ja auch gar nicht. Die LANCOMs sind "über Kreuz" durch gegenseitige Anmeldungen verbunden, d.h. wenn LANCOM-A eine Verbindung aufbauen will, dann nutzt er seine Anmeldung an LANCOM-B, nicht die Anmeldung von B an A. Da kann er dann ja nicht nur "klingeln" sondern sich auch wünschen, mit wem er verbunden werden will.

Gruß,
Andreas

[suvuk]

Die LANCOMs sind "über Kreuz" durch gegenseitige Anmeldungen verbunden, d.h. wenn LANCOM-A eine Verbindung aufbauen will, dann nutzt er seine Anmeldung an LANCOM-B, nicht die Anmeldung von B an A. Da kann er dann ja nicht nur "klingeln" sondern sich auch wünschen, mit wem er verbunden werden will.

Dann sollte das eigentlich auch funktionieren. Die "Zielrufnummer" kann ja dann über den Callmanager ausgewertet werden. Hmm. Ohne IRL-Test ist mir das dann auch nicht ganz klar.

Gruß
Suvuk

[tunichtgut]

Hallo zusammen,

Da wird vorgeschlagen die beiden LANCOMs jeweils gegenseitig als SIP-PBX-Leitung einzutragen. Hmm. Ich hätte die eigentlich eher als SIP-Provider eingetragen. Bei der ersten Variante müssen doch die Benutzer auf beiden LANCOMS konfiguriert sein. Damit sind die 16 möglichen Benutzer ziemlich schnell erschöpft. Bei der Variante "SIP-Provider" benötigt jeder LANCOM auf der jeweils anderen Seite nur einen Benutzer.

nein, nusst Du nicht. Du legst auf jedem Router nur die lokal angemeldeten Nutzer an und machst Call Routing Einträge auf die per PBX zu erreichenden User, somit gehen auch nur Rufe auf die Call Routing Einträge existieren über die PBX, das is schon alles.

[AndreasMarx]

Du legst auf jedem Router nur die lokal angemeldeten Nutzer an und machst Call Routing Einträge auf die per PBX zu erreichenden User, ...

... und wenn so ein Call Routing auf den entfernten LANCOM rausgeht, dann schickt der lokale Call-Router einfach ein INVITE ohne vorheriges REGISTER und woher weiß der entfernte LANCOM dann, daß dieser INVITE authorisiert ist? der Call-Router nimmt ja wohl nicht alle INVITES an --- ich will schließlich nicht Vermittlung spielen für die ganze Welt.

Eine Möglichkeit wäre (fällt mir gerade ein), daß der entfernte LANCOM den lokalen über seine SIP-PBX Tabelle authorisiert, d.h. jede SIP-PBX-Leitung zu einem LANCOM benötigt auf der Gegenseite den umgekehrte Eintrag.

Ist das vielleicht so (Hoffnung keimt auf, daß ich es verstanden haben könnte)?

Andreas

[tunichtgut]

Du legst auf jedem Router nur die lokal angemeldeten Nutzer an und machst Call Routing Einträge auf die per PBX zu erreichenden User, ...

... und wenn so ein Call Routing auf den entfernten LANCOM rausgeht, dann schickt der lokale Call-Router einfach ein INVITE ohne vorheriges REGISTER und woher weiß der entfernte LANCOM dann, daß dieser INVITE authorisiert ist? der Call-Router nimmt ja wohl nicht alle INVITES an --- ich will schließlich nicht Vermittlung spielen für die ganze Welt.

Eine Möglichkeit wäre (fällt mir gerade ein), daß der entfernte LANCOM den lokalen über seine SIP-PBX Tabelle authorisiert, d.h. jede SIP-PBX-Leitung zu einem LANCOM benötigt auf der Gegenseite den umgekehrte Eintrag.

Ist das vielleicht so (Hoffnung keimt auf, daß ich es verstanden haben könnte)?

Andreas

Klar kommt zuerst ein INVITE (das ist übrigens immer so) dieser ist, richtig vermutet über die PBX-Line authentisiert. So sieht ein Ruf über PBX dann aus:

[SIP-Packet] 2006/02/10 10:25:24,510
Receiving Datagram with length 731 from 192.168.10.91:42933:
INVITE sip:210@voip.intern SIP/2.0
Via: SIP/2.0/UDP 192.168.10.91:42933;branch=z9hG4bK-6da803ae-36d401d7
From: "ISDN700" <sip:700@lcs.qs.fb.testnetz>;tag=1842415865-3679455068
To: <sip:210@voip.intern>
Call-ID: 3684831730@00:a0:57:01:23:45
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: LANCOM PBX
Server: 0.0.0.0
Allow: INVITE, ACK, CANCEL, BYE
Contact: <sip:700@192.168.10.91:42933>
Content-Type: application/sdp
Content-Length: 284

v=0
o=Lancom 12345 6789 IN IP4 192.168.10.91
s=Lancom PBX
c=IN IP4 192.168.10.91
t=0 0
m=audio 32814 RTP/AVP 8 0 106 2 104 103
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:106 G726-40/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:104 G726-24/8000
a=rtpmap:103 G726-16/8000


[Callmanager] 2006/02/10 10:25:24,520
From: 700@lcs.qs.fb.testnetz Line: 'FRANK1721'
To : 210@voip.intern <Number is complete>
Info: Parse call routing table for active entries
Info: Search in the local user database
==> From: 700@lcs.qs.fb.testnetz Line: 'FRANK1721'
To : 210@voip.intern Line: 'USER.ISDN'
InitiateCall: 210@voip.intern Line: 'USER.ISDN'

[Callmanager] 2006/02/10 10:25:24,530
ClnID From: '700'
Convert CldID: '210' ==> CldMSN: '420403'

[SIP-Packet] 2006/02/10 10:25:24,540
Sending Datagram with length 410 to 192.168.10.91:42933:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.10.91:42933;received=192.168.10.91:42933;branch=z9hG4bK-6da803ae-36d401d7
From: "ISDN700" <sip:700@lcs.qs.fb.testnetz>;tag=1842415865-3679455068
To: <sip:210@voip.intern>;tag=263325232-131662616
Call-ID: 3684831730@00:a0:57:01:23:45
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: LANCOM PBX
Server: LC1822
Allow: INVITE, ACK, CANCEL, BYE
Content-Length: 0

Andernfalls müsstest Du alle remote user ja auch nochmal in der eigenen user liste einpflegen, wo es dann wirklich schnell eng würde mit 16 Benutzern

[AndreasMarx]

der Nebel lichtet sich ... kennst Du dieses Gefühl, wenn Du auf einmal glaubst es verstanden zu haben

Code: Alles auswählen

[Callmanager] 2006/02/10 10:25:24,520 
From: 700@lcs.qs.fb.testnetz Line: 'FRANK1721'

Hier hat er schon gemerkt, daß der Call über SIP-PBX-Line 'FRANK1721' reinkam. Es macht das an der Quell-IP 192.168.10.91 oder der Domäne 'lcs.qs.fb.testnetz' oder beidem fest? Call ist damit autorisiert.

Code: Alles auswählen

==> From: 700@lcs.qs.fb.testnetz Line: 'FRANK1721' 
To : 210@voip.intern Line: 'USER.ISDN' 
InitiateCall: 210@voip.intern Line: 'USER.ISDN' 

[Callmanager] 2006/02/10 10:25:24,530 
ClnID From: '700' 
Convert CldID: '210' ==> CldMSN: '420403'

Der Benutzer 210 ist wohl ein lokaler ISDN-Benutzer. Die MSN hat er aus der ISDN-Mapping-Tabelle.

Ich hab das sichere Gefühl, daß das alles mal wieder wohldurchdacht ist. Leider steht das nicht immer alles in seiner vollen Pracht im Handbuch drin (ist ja so schon umfangreich genug). Für meinen Geschmack könnte das ruhig noch etwas technischer und präziser sein. Die Info, daß ein SIP-PBX-Eintrag auch Authorisierungsfunktion hat, hab ich nicht gefunden.

Viele Grüße,
Andreas

[MoinMoin]

Moin, moin!

... und wenn so ein Call Routing auf den entfernten LANCOM rausgeht, dann schickt der lokale Call-Router einfach ein INVITE ohne vorheriges REGISTER und woher weiß der entfernte LANCOM dann, daß dieser INVITE authorisiert ist? der Call-Router nimmt ja wohl nicht alle INVITES an --- ich will schließlich nicht Vermittlung spielen für die ganze Welt.

Der ist automatisch authorisiert, wenn er von der IP kommt, die das LANCOM für die PBX-Leitung zur Gegenseite ermittelt hat. Dafür brauchtst du die überkreuz definierten PBX-Leitungen.

Generell ist es aber schon richtig, auch nicht authorisierte INVITES zuzulassen, wenn der Angerufene ein interner Teilnehmer ist. Ansonsten würdest du bei SIP auf die Möglichkeit verzichten, den Zielteilnehmer ohne den Umweg über einen SIP-Provider direkt zu erreichen. Derzeit geht das mit einem LANCOM allerdings nicht und es fehlen auch noch Konfigurationsmöglichkeiten für z.B. Amtsberechtigungen.

Ciao, Georg

[AndreasMarx]

Hallo Georg

Der ist automatisch authorisiert, wenn er von der IP kommt, die das LANCOM für die PBX-Leitung zur Gegenseite ermittelt hat. Dafür brauchtst du die überkreuz definierten PBX-Leitungen.

Das ist ein starkes Argument, PBX-Lines immer über VPN zu führen (wie ja auch im Handbuch empfohlen). Was bei mir auf dem WAN-Interface so mit internen LAN-IPs ankommt, das ist schon erstaunlich.

Generell ist es aber schon richtig, auch nicht authorisierte INVITES zuzulassen, wenn der Angerufene ein interner Teilnehmer ist.

Hmm, also ähnlich, wie ein gescheit konfigurierter Mail-Transport-Agent das auch macht: Was von intern kommt oder nach intern geht ist OK (hier beim MTA über Domain ermittelt), der Rest wird abgewiesen.

So langsam finde ich richtig Spaß an der Sache. Habt ihr richtig gut hinbekommen. Hoffentlich bekomme ich meine VOIP-Option bald.

Viele Grüße,
Andreas

[tunichtgut]

der Nebel lichtet sich ... kennst Du dieses Gefühl, wenn Du auf einmal glaubst es verstanden zu haben

Der Benutzer 210 ist wohl ein lokaler ISDN-Benutzer. Die MSN hat er aus der ISDN-Mapping-Tabelle.

Ich hab das sichere Gefühl, daß das alles mal wieder wohldurchdacht ist. Leider steht das nicht immer alles in seiner vollen Pracht im Handbuch drin (ist ja so schon umfangreich genug). Für meinen Geschmack könnte das ruhig noch etwas technischer und präziser sein. Die Info, daß ein SIP-PBX-Eintrag auch Authorisierungsfunktion hat, hab ich nicht gefunden.

Viele Grüße,
Andreas

Ja, das kenn ich gut, auch wir haben VoIP schliesslich nicht mit der Muttermilch aufgenommen

Der ISDN Benutzer 210 ist btw. eine AGFEO200IT am NT des 1722 Auch die Funktion das AGFEO LCR auf den LANCOM zu biegen, das Du in einem anderen Posting angefragt hattest, läuft hier mittlerweile. (schwupps, das warst du garnicht aber ggf. liest hans ja mit )

Das Rufe von PBX-Lines sich nicht mehr authentisieren müssen kam erst recht spät in die Firmware rein, ggf. hat das deshalb nicht mehr in die Doku gefunden.

[MoinMoin]

Moin, moin!

Das ist ein starkes Argument, PBX-Lines immer über VPN zu führen (wie ja auch im Handbuch empfohlen). Was bei mir auf dem WAN-Interface so mit internen LAN-IPs ankommt, das ist schon erstaunlich.

Aber nicht weiter gefährlich, denn die Antwort wird dank der gefälschten Absenderadresse neimals den eigentlichen Absender erreichen. Somit kann mit einer gefälschten Adresse auch nicht schmarotzend Telefoniert werden. Denkbar wären allerdings DoS-Attacken.

Ciao, Georg