Liebe Community,
das gelegentlich diskutierte Problem nicht dauerhaft an Telekom-Anschlüssen funktionierender Asterisk-Konfigurationen stört extrem stark und passt nicht in eine Zeit, in der die Telekom auf VoIP drängt. Schließlich wird nicht ernsthaft überall ein Speedport gewünscht sein. Bei mir liegt eine Doppel-SOHO-Lösung in zwei Städten mit All-IP-Anschluss vor. In beiden Fällen ist ein Telekom- und ein Kabelanschluss vorhanden mit je einer Fritzbox und dahinter einem pfSense-Firewall hinter dem sich dann Asterisk in einer FreePBX-Distribution befindet. Die beiden Netze sind über VPN verbunden und die Asterisk-Lösungen sind zusammengeschaltet, so dass ein (!) zeitweiliger Ausfall eines Trunks verkraftbar ist - aber nicht der Ausfall beider Trunks. Das hat mehr als ein Jahr lang bestens funktioniert. Nun funktioniert bei gleicher Konfiguration in einer Stadt alles prima und in der anderen Stadt funktionieren eingehende Anrufe, aber bei ausgehenden Anrufen meldet das Asterisk-Log bei Folgeanrufen gern:
chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '[email protected]'. Giving up.
Die sip.conf war und ist (wobei man bei All-IP-Anschlüssen ja am eigenen Anschluss kein "secret" übermitteln soll und auch der Benutzername kurz sein soll):
Natürlich habe ich vor dieser Frage schon X Varianten erfolglos durchprobiert. Trotzdem: Weiß jemand Rat?
Mit freundilchem Gruß
Michael Schefczyk
das gelegentlich diskutierte Problem nicht dauerhaft an Telekom-Anschlüssen funktionierender Asterisk-Konfigurationen stört extrem stark und passt nicht in eine Zeit, in der die Telekom auf VoIP drängt. Schließlich wird nicht ernsthaft überall ein Speedport gewünscht sein. Bei mir liegt eine Doppel-SOHO-Lösung in zwei Städten mit All-IP-Anschluss vor. In beiden Fällen ist ein Telekom- und ein Kabelanschluss vorhanden mit je einer Fritzbox und dahinter einem pfSense-Firewall hinter dem sich dann Asterisk in einer FreePBX-Distribution befindet. Die beiden Netze sind über VPN verbunden und die Asterisk-Lösungen sind zusammengeschaltet, so dass ein (!) zeitweiliger Ausfall eines Trunks verkraftbar ist - aber nicht der Ausfall beider Trunks. Das hat mehr als ein Jahr lang bestens funktioniert. Nun funktioniert bei gleicher Konfiguration in einer Stadt alles prima und in der anderen Stadt funktionieren eingehende Anrufe, aber bei ausgehenden Anrufen meldet das Asterisk-Log bei Folgeanrufen gern:
chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '[email protected]'. Giving up.
Die sip.conf war und ist (wobei man bei All-IP-Anschlüssen ja am eigenen Anschluss kein "secret" übermitteln soll und auch der Benutzername kurz sein soll):
Code:
vmexten=*97
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
useragent=FPBX-2.11.0(11.14.2)
disallow=all
allow=g722
allow=ulaw
allow=alaw
allow=g726
allow=g729
allow=h264
allow=h263p
callevents=no
language=de
jbenable=no
defaultexpiry=240
allowguest=no
srvlookup=no
minexpiry=60
maxexpiry=3600
registerattempts=0
registertimeout=30
notifyhold=yes
rtpkeepalive=30
g726nonstandard=no
t38pt_udptl=yes,redundancy,maxdatagram=400
videosupport=yes
maxcallbitrate=384
canreinvite=no
rtptimeout=20
rtpholdtimeout=300
notifyringing=yes
checkmwi=10
nat=yes
externhost=(Domain)
externrefresh=120
localnet=192.168.0.0/255.255.0.0
[Telekom]
disallow=all
username=(Telefonnummer)
type=friend
trustrpid=yes
sendrpid=yes
qualify=yes
nat=yes
keepalive=30
insecure=port,invite
host=tel.t-online.de
fromdomain=tel.t-online.de
dtmfmode=rfc2833
directmedia=no
defaultexpiry=600
context=from-trunk
allow=g722,ulaw,alaw
register=(Telefonnummer)@tel.t-online.de/(Telefonnummer ohne Vorwahl)
register=(Telefonnummer)@tel.t-online.de/(Telefonnummer ohne Vorwahl)
register=(Telefonnummer)@tel.t-online.de/(Telefonnummer ohne Vorwahl)
register=(Telefonnummer)@tel.t-online.de/(Telefonnummer ohne Vorwahl)Natürlich habe ich vor dieser Frage schon X Varianten erfolglos durchprobiert. Trotzdem: Weiß jemand Rat?
Mit freundilchem Gruß
Michael Schefczyk
Zuletzt bearbeitet von einem Moderator:
