Der Netzzugang arbeitet, bis auf das PIN Problem (an anderer Stelle erörtert), einwandfrei. O2 hat konform der aktuellen Rechtslage alle Informationen zur Verfügung gestellt.
Neben der O2 telephonie existiert noch ein SIPgate Konto. Kurz: SIPgate arbeitet mit der eingesetzten Anlage und deren (spärlichen) Asterisk/PBX Angaben einwandfrei. Der PBX Server autorisiert und authentifiziert sich bei seiner Gegenstelle. Die hinter meinem Router/Firewall in einem dedizierten Netz untergebrachten Telephone arbeiten mit SIPgate problemlos.
Nur O2 macht bei der Registrierung an deren Server (sip.alice-voip.de) Probleme.Bislang konnte ich nicht herausfinden, woran es liegt. Asterisk protokolliert im Debugging Modus:
[Jul 22 19:02:53] WARNING[101203] res_pjsip_outbound_registration.c: Temporal response '401' received from 'sip:sip.alice-voip.de' on registration
attempt to 'sip:4933047110815@sip.alice-voip.de', retrying in '60'
Die Konfiguration erfolgt via PJSIP.
Um das NAT Problem zu lösen, verwende ich in der Definition zum Transport den DDNS Namen; das geht natürlich nur solange gut, wie die IP Wechsel nicht zu oft erfolgen. Ich habe heute festgestellt, daß O2 sehr häufig und willkürlich neue IPs im DHCP Verfahren verteilt - die Nichterreichbarkeit via VoIP korreliert mit dem Update auf den DNS Servern, die DDNS bedienen und ihre Daten weiterreichen. Eventuell kocht O2 hier ein eigenes DNS-Süppchen und die DDNS wird nicht aufgelöst?
Welche Möglichkeiten gibt es, außer STUN usw. und wenn STUN/ICE usw., wie setzt O2 das um und wie kann ich mit einem Fremdrouter diese Informationen erhalten und auswerten?.
[transport_udp]
type= transport
protocol= udp
local_net= 192.168.254.0/24
local_net= 127.0.0.1/32
bind= 192.168.254.1:5060
external_media_address= mein.ddns.eintrag
external_signaling_address= mein.ddns.eintrag
[registration_default](!)
transport= transport_udp
retry_interval= 60
forbidden_retry_interval= 300
expiration= 120
max_retries= 90
auth_rejection_permanent= false
Beim Attribut
contact_user=
im Kontext [trunk_o2](registration_default)
habe ich wahlweise mal
contact_user= O2-SIP-Benutzername
oder
contact_user= O2-SIP-Benutzername@sip.alice-voip.de
verwendet, selbiges habe ich auch im Kontext
[trunk_o2_auth]
type= auth
mit dem Attribut username= gemacht. Stets ohne Erfolg. Da ich auch einmal ein falsches Paßwort angegeben habe und immer noch "401" vom SIP Server von O2 zurückgeliefert wird, gehe ich davon aus, daß die Prüfung der Autorisierungs- und Authetifizierungsparameter noch gar nicht erfolgte, sondern im Vorfeld ein Problem auftritt.
;-------------------------------------------------------------------------------
; O2 Trunk
; O2-SIP-Benutzername : Telephonnummer ohne führende Null aber mit
; internationalem Länderprefix (ohne +)
; EinPasswortVonO2 : Das von O2 bereitgestellte Paßwort für die Telephonie via SIP
;-------------------------------------------------------------------------------
[trunk_o2](registration_default)
type= registration
contact_user= O2-SIP-Benutzername
outbound_auth= trunk_o2_auth
client_uri= sip:O2-SIP-Benutzername@sip.alice-voip.de:5060
server_uri= sip:sip.alice-voip.de:5060
[trunk_o2]
type= identify
endpoint= trunk_o2
match= sip.alice-voip.de
[trunk_o2_aor]
type= aor
max_contacts= 1
contact= sip:O2-SIP-Benutzername@sip.alice-voip.de
[trunk_o2_auth]
type= auth
auth_type= userpass
username= O2-SIP-Benutzername
password= EinPasswortVonO2
;realm= ims.telefonica.de
[trunk_o2_out]
type= endpoint
transport= transport_udp
context= funout_o2
dtmf_mode= rfc4733
disallow= all
allow= g722
allow= alaw
rtp_symmetric= yes
force_rport= yes
rewrite_contact= yes
timers= yes
from_user= O2-SIP-Benutzername
from_domain= sip.alice-voip.de
language= de
direct_media= no
outbound_auth= trunk_o2_auth
auth= trunk_o2_auth
aors= trunk_o2_aor
[trunk_o2_in]
type= endpoint
transport= transport_udp
context= o2_in
disallow= all
allow= g722
allow= alaw
outbound_auth= trunk_o2_auth
;[trunk_o2_identify]
;type= identify
;endpoint= trunk_o2_in
;match= 195.71.31.3
Der letzte Abschnitt type=identify ist sehr schwierig zu realisieren, weil niemand so recht weiß, im welchen IP Adreßkreis die O2 SIP Server liegen. Eventuell kann man das hier erfragen.
Generell wäre noch folgendes zu erfragen:
Wie sieht es eigentlich mit einer gesicherten VoIP Verbdinung zu O2 aus? IPsec/VPN oder TCP/TLS sind ja in Kreisen, wo es um die Sicherheit der Privatsphäre geht, bereits kein Thema mehr, sondern Standards. Daß hier die gesamte Telephonie im Klartext über den iberischen Erd-Äther geht, ist aus deutscher Sicht schon mal beängstigend ... Lösungen?
Lösung von Mister79
Zur Antwort springen
