[Problem] Telekom 15 Min Abbruch bei Ausgehend

[geforce28]

Mh, das ist mir ja schon soweit klar.
Gehen wir mal davon aus, dass die Tests erfolgreich wären und ich dadurch potenziell angreifbar bin, wie setze ich das Ganze dann um, sodass ich sicher bin ?
Da komme ich noch nicht sorecht dahinter und es würde mir wahnsinnig helfen, wenn sich jemand der Sache annehmen würde und meine oben geposteten 2 Configs (Dialplan + pjsip) mal so darstellen kann, dass es sicher wäre... !

 

[sunseb]

Hallo geforce28,

hast du vielleicht einen Lancom-Router mit Call-Manager? Ähnlich der Empfehlung von koyaanisqatsi könntest du dann eine SIP-Leitung zur Telekom machen und den Asterisk über eine SIP-PBX-Leitung anbinden. Damit umgehst du das NAT-Problem und dein Asterisk kann im LAN bleiben. Funktioniert hier einwandfrei schon ewig ;-)

Lieber Gruß,
Sebastian

 

[geforce28]

Hm leider nicht...!
Mein lancom hat lediglich ein SIP ALG, ist also keine Option, es sei denn ich kaufe extra noch ein extra Gerät dafür.

Aber wie macht der Lancom das dann?
Doch dann wohl auch per NAT??
Also muss das ganze doch auch iwie mit PJSIP realisieren zu sein?

 

[rentier-s]

Bei chan_pjsip gibt es eine match Anweisung, damit kann man (im Gegensatz zu chan_sip) auch kompletten Netzwerkbereichen einen Context zuordnen. Dazu ist ein entsprechender endpoint notwendig, der als context dann telekom-in bekommt. Wobei es grundsätzlich kein Problem ist, das ganze über default abzuwickeln, mache ich bei chan_sip auch so, aber in default darf auf keinen Fall ein include=>telekom-out stehen!

Damit die internen endpoints telefonieren können, bekommen sie einen passenden context Eintrag, von dem aus dann interne und abgehende Telefonate möglich sind. Das Prinzip ist das gleiche wie bei chan_sip.

SIP hinter einem NAT ist theoretisch auch ohne Portforwarding möglich, so lange ein keepalive das Portmapping offen hält. Da Asterisk aber kein STUN kann, gibt er im Contact immer den bindport an. Die Telekom ist absolut nicht NAT tolerant (anders als zB. sipgate), und verlässt sich allein auf den Contact. Asterisk muss daher auch auf diesem erreichbar sein, also Portforwarding. Das gleiche gilt auch für die RTP Ports (rtp.conf).

 

[geforce28]

@rentier-s:
Danke für die Ausführliche Antwort.

Also ich fasse mal zusammen:
Ich sollte telekom-out aus dem Default Context rausnehmen und einen eigenen Context für meine internen Telefone anlegen und zuweisen, der dann telekom-out und telekom-in beinhaltet, richtig ??

Und da die Telekom nicht NAT tollerant ist kann ich das ganze ohne Portforwarding vergessen.

Dann muss ich ja jetzt nur noch die Umsetzung schaffen.
Denn der Asterisk, der die Telekom anbindung hat ist über IAX2 an einen anderen Asterisk gekoppelt, der ganz normal CHAN_SIP benutzt und damit die internen Telefone versorgt...

- - - Aktualisiert - - -

So ich habe mich jetzt mal an die Umsetzung gemacht.

Also auf dem Asterisk Server der die Anbindung an die Telekom hat habe ich nun wie folgt konfiguriert:
PJSIP.conf:

[global]
type=global
user_agent=Asterisk05
endpoint_identifier_order=ip,username
default_from_user=HAUPTRUFNUMMER


[transport-dtag]
type=transport
protocol=udp
bind=10.0.41.10:5060
local_net=10.0.41.0/255.255.255.0
tos=cs6


[dtag-defaults](!)
type=registration
transport=transport-dtag
outbound_auth=dtag
server_uri=sip:tel.t-online.de
line=yes
endpoint=dtag
retry_interval=60
forbidden_retry_interval=300
expiration=480
auth_rejection_permanent=false
max_retries=535680


[dtag-MSN1](dtag-defaults)
client_uri=sip:[email protected]
contact_user=+49123456789


[dtag-MSN2](dtag-defaults)
client_uri=sip:[email protected]
contact_user=+491234567899


[dtag-MSN3](dtag-defaults)
client_uri=sip:[email protected]
contact_user=+4912345678999


[dtag]
type=auth
auth_type=userpass
username='T-ONLINE_ZUGANGSNUMMER'
realm=tel.t-online.de




[dtag-out]
type=endpoint
transport=transport-dtag
context=unspecified
disallow=all
allow=g722
allow=alaw
outbound_auth=dtag
from_domain=tel.t-online.de
aors=dtag
direct_media=no
tos_audio=ef
trust_id_outbound=yes
send_pai=yes
timers=no


[dtag-in]
type=endpoint
transport=transport-dtag
context=sip-in-telekom
disallow=all
allow=g722
allow=alaw
outbound_auth=dtag


[dtag]
type=identify
endpoint=dtag-in
match=tel.t-online.de


[dtag]
type=aor
contact=sip:tel.t-online.de

Extensions.conf:

[general]
static=yes
writeprotect=no


[unspecified]
; wer hier landet ist entweder schlecht konfiguriert oder hat keine "Rechte"
exten => _X.,1,Answer()
exten => _X.,2,Verbose(D E F A U L T ==> ${CALLERID(num)} kam um ${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)} in UNSPECIFIED an als er versuchte die Nummer ${EXTEN} anzurufen.)
exten => _X.,3,Hangup()


[sip-in-telekom]
;intern-extern-rufnr-zuordnung
exten => +491234567899,1,Dial(IAX2/asterisk01/959291,260,r)
exten => +4912345678999,1,Dial(IAX2/asterisk01/959290,260,r)
exten => +49123456789,1,Dial(IAX2/asterisk01/535100,260,r)




[sip-out-telekom]
exten => _0./01234567899,1,Set(CALLERID(num)=+491234567899)
exten => _0./+491234567899,2,Set(CALLERID(name)=+491234567899)
exten => _0./+491234567899,n,Dial(PJSIP/${EXTEN}@dtag-out,260,r)


exten => _0./012345678999,1,Set(CALLERID(num)=+4912345678999)
exten => _0./+4912345678999,2,Set(CALLERID(name)=+4912345678999)
exten => _0./+4912345678999,n,Dial(PJSIP/${EXTEN}@dtag-out,260,r)


exten => _0./0123456789,1,Set(CALLERID(num)=+49123456789)
exten => _0./+49123456789,2,Set(CALLERID(name)=+49123456789)
exten => _0./+49123456789,n,Dial(PJSIP/${EXTEN}@dtag-out,260,r)

Die Anbindung an den anderen Asterisk sieht so aus:
IAX.conf:

[general]
autokill=yes
disallow=all
allow=g722
allow=alaw


[asterisk01]
type=friend
username=asterisk05
secret=PASSWORT
auth=plaintext
host=10.0.20.5
context=default
peercontext=default
qualify=yes
trunk=yes


[asterisk01-out]
type=friend
username=asterisk05-out
secret=PASSWORT
auth=plaintext
host=10.0.20.5
context=sip-out-telekom
peercontext=sip-out-telekom
qualify=yes
trunk=yes

Auf dem Asterisk01, an dem die Endpoints angebunden sind ist allerdings alles über context "Default" geregelt...
Dies sollte aber kein Sicherheitsrisiko darstellen, da man dort ja nur lokal rankommt und sich dieser Server auch in einem extra Voice VLAN befindet.


Was meint ihr??
So gut oder noch Verbesserungsvorschläge ?