[Gelöst] BINTEC be.IP+, DECT150 keine ausgehenden Gespräche

[LUNO42]

Hallo,

ich versuche gerade in einem kleinen Büros einen be.IP+ mit DECT150 und drei (DECT) Telefonen an den Start zu bekommen.
Nach einigen Hürden ist der SIP Anschluss nun insofern konfiguriert, dass Anrufe an die die einzelnen Telefondurchwahlen der Telefone und an eine Sammelrufnummer funktionieren. An das Thema Inbound Calls kann man also einen Haken machen.

Was ich gerade überhaupt nicht auf die Reihe bekomme sind die ausgehenden Rufe.
Die üblichen Verdächtigen:
- Amtkennziffer
- Berechtigungsklasse
habe ich bereits geprüft. Dort war das Problem nicht zu beseitigen.

Vielleicht liegt das Problem ja auch gar nicht bei der Anlage an sich sondern bei der Variante der Anbindung
in das lokale Netzerk. Die be.IP (und damit auch die DECT Basisstation) wurden in einem vorhandenen LAN mit vorhandenem Router in ein separates VLAN "eingesperrt".

Was ich im Handbuch der be.IP nicht so recht entdeckt habe, wie das Handling der SIP Nachrichten mit vorgeschalteten NAT Gateway erfolgt. In der VoIP Konfiguration der be.IP gibt es einen Schalter "Vorgeschaltetes Gerät mit NAT" den ich auch aktiviert habe. Ob dieser Schalter allerdings genau das tut was ich erwarte, ist für mich gerade nicht erkennbar.

Erwartungshaltung wäre hier, dass für die an den Provider zu sendenden SIP Pakete die externe IP Adresse verwendet wird.

Die Frage ist, tut die be.IP+ das auch ? Einen STUN Server habe ich bis jetzt nicht konfiguriert, da der Provider keinen angegeben hat. Da es sich um eine feste IPv4 Adresse handelt könnte man die externe IP auch irgendwo "fest verdrahten" ... falls das überhaupt geht.

Bei der Gelegenheit: da der SIP Provider einen STUN Server nicht anbietet, welchen nimmt man den üblicherweise, wenn man einen braucht ?

Noch etwas zum NAT Gateway. Das ist ein Linux basierter EdgeRouter mit standardmässig aktivierten NAT ALG. Dieser ALG hat die üblichen Linux Kernel NAT SIP Module aktiviert. Wenn ich mich recht entsinne klappt das inbound sehr gut (deshalb kommen vermutlich die Gespräche auch ganz prima an). Oubound muss glaube ich der Client die passenden Absender ins SIP Paket schreiben. Wie gesagt hier die Frage, ob das die be.IP+ auch tatsächlich tun.

So langsam gehen mir die Ideen aus ...
Vielleicht hat ja jemand damit Erfahrung und kann mir einen Tip geben, mit dem ich weiterkommen.

Danke schon mal vorab !

 

[LUNO42]

Letztlich hat das hier geholfen, auch wenn es nicht vollständig das Problem abdeckt.
http://faq.bintec-elmeg.com/index.p...IP_Provider:_Versatel_(1&1)_SIP-DDI_Anschluss

Zusätzlich ist es eine gute Idee bei der Versatel anzurufen und das Feature "CLIP -no screening-" aktivieren zu lassen.
Ich setze das Problem mal auf "Gelöst"

 

[MuP]

Welches Detail war letztendlich relevant?

 

[LUNO42]

Hallo,

anders als in der Problembeschreibung vermutet braucht es keinen STUN Server.
Wenn man im Feld "From Domain" die feste IP (IPv4) Adresse der Anbindung einträgt und gleichzeitig
"Vorgeschaltetes Gerät mit NAT " aktiviert, gehen die Pakete schon mal mit der richtigen Source IP auf den Weg.

Bei Versatel sind dann noch die Angaben im SIP HEADER nicht unwichtig.
P-Preferred und P-Asserted kann und sollte man dabei ggf. gleich ausschalten.
Aktuell habe ich P-Asserted auf "Anruferadresse" um hier eine individuelle Übertragung der Rufnummer
zu erreichen.Bei Angaben in P-Preferred hat der Versatel Gateway den Call abgelehnt, was man dann erst bei einem
SIP Trace sieht.

Wichtig war im übrigen auch noch:
- Internationale Rufnummer erzeugen
- Nationale Rufnummer erzeugen

Aber diese Information kann man auch aus Datenblatt des Anbieters entnehmen.

Das Feature CLIP no screening muss bei Versatel separat beauftragt und aktiviert sein. Dann kann man bei einer Anrufweiterschaltung auch z.B. auf dem Handy die Rufnummer des A-Teilnehmers am C-Teilnehmer sehen.
Ist zumindest in meinem Fall gern genommen ... Ggf. wollen genau das Feature aber nicht alle haben.
Zumindest kostet das nichts extra und damit kann man es einschalten lassen.