[Problem] O2 BSA VDSL mit Asterisk 13 PBX

[Eisenfaust]

Seit rund einem Monat hat Telefonica auch uns auf BSA und VDSL umgestellt. Damit einhergehend - auch ohne einen Prozeß zu führen - stellt O2 jetzt die DSL Zugangsdaten und SIP/Telephoniezugangsdaten bereit.

Die Zugangsdaten bestehen lediglich aus absolut notwendigen "LOGIN" Daten, also Ziel (SIP Server), Benutzer/Username und das obligatprische Paßwort.

Wir betreiben einen eigenen Router. Auf diesem Router läuft ein Asterisk (13.17.xx). Die Verbindung zum DSL Netz wird über ein VDSL Modem hergestellt.

Nun habe ich Probleme mich am O2 SIP Server zu authentifizieren, ich erhalte stets Fehler 401 zurück. Die Grundkonfiguration für den O2-Trunk habe ich an einen mit dem selben Hardwareaufbau funktionierenden T-Com Zugang versucht einzurichten, allerdings um die entsprechende URI und Schlüsseldaten ergänzt.

Bevor ich jetzt die Konfiguration des AOR, AUTH und Registrierens hier abwerfe, wüde ich gerne wissen, ob jemand hier im Forum bereits erfolgreich einen Asterisk mit einem O2 SIP Server verbunden hat.

Ich habe überhaupt keine Informationen, ob O2 STUN, Proxy usw. verwendet und wie diese konfiguriert sein müssen oder auf welchen RTP Portbereichen die Firewall eingehend transparent sein muß.

Der Asterisk in einem eigenen, sicheren Netzwerk hinter NAT. Derzeit "simuliere" ich STUN via DDNS. Allerdings habe ich keine Kenntnis darüber, wie die URI im "contact" auszusehen hat usw.

Ich danke schon mal im voraus.

 

[Eisenfaust]

Also, auf in die nächste Runde, jetzt einmal 'Butter bei die Fische".

In dem folgenden Beispiel sei meine Telephonnummer "0049 12 34567890", bzw. "+49 12 34567890" oder mit Vorwahl in der Bundesrepublik "012 34567890".

Für die Registrierung eines O2 Anschlusses verwende ich folgende Einträge in pjsip.conf, wie unten angegeben. Der ASTERISK Daemon sitzt in einem "sicheren" Netzsegment auf einer eigenen IP, d.h., er lauscht nicht auf allen Schnittstellen, die am System vorhanden sind. Das impliziert allerdings, daß der ASTERISK nicht mit der von O2 meinem Endgerät zugewiesenen IP mit der Außenwelt kommuniziert, sondern via NAT. Der ASTERISK verhält sich demgemäß wie ein SIP Telephon, das ich hinter meinem Router (und damit hinter NAT) anschließe. Eventuell sind hier Konfigurationsparadigmen sinnvoll, die ein SIP Telephon nach außen bringen können. O2 schweigt sich beharrlich auch darüber aus, wie man ein SIP Telephon anbindet - eine Sache, die man vielleicht mal mit mehr "Lex" angehen sollte.

Nun, da ich nicht weiß, welche IP mir der ISP DHCP zuweist, wenn ich ins Netz gehe und aufgrund der oben beschriebenen Konfiguration, nutze ich DDNS, um meine offizielle IP zu ermitteln, dazu sind die beiden Transport-Einträge external_XXX= in [transport_udp] nötig.

Die interessanten Aspekte der Registrierung sind dann weiter unten.

Wie lauten syntaktisch

contact_user=
server_uri=
client_uri=
outbound_proxy=
username=
from_user=
from_domain=
contact=

Kann jemand dazu etwas sagen?

In den DEBUG Logs des Asterisk finde ich folgende Einträge:

[...]
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Outbound REGISTER attempt 1 to 'sip:sip.alice-voip.de' with client 'sip:[email protected]'
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Received REGISTER response 502(DNS "Name Error" (PJLIB_UTIL_EDNS_NXDOMAIN))
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Processing REGISTER response 502 from server 'sip:sip.alice-voip.de' for client 'sip:[email protected]'
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Scheduling outbound registration to server 'sip:sip.alice-voip.de' from client 'sip:[email protected]' in 30 seconds
[...]

Diese Meldung erscheint, wenn mein DNS Server (auf dem Router) sip.alice-voip.de nicht auflösen kann. Gut, eine kleine dümmliche Schikane des ISP, um "nomadisches" Nutzen seiner ach so tollen IP Infrastruktur NICHT zu nutzen. Sowas kann man mit etwas Aufwand Phantasie umgehen, aber sei es 'drum.

Wenn dann mein Asterisk/Router mit dem richtigen DNS kommuniziert, gibts allerdings einen Fehler 401 - und ein solcher besagt laut Meinung von echten oder selbsternannten Experten: Authentifizierungsfehler. Das heißt, mein PBX konnte zwar den Registrar erreichen, aber die Gegenstelle will ihn nicht. Paßwort falsch? URI nicht im richtigen Format? Ich habe jetzt nahezu alle möglichen Permutationen der Darstellung der URI des username= (e164 in strictu sensu oder ohne "+", also sip:[email protected] oder sip:[email protected] beispielsweise), "contact=" und "client_uri=" durch.

Weiter unten in meiner Konfiguration sieht man im Objekt type=identify das Attribut match=. Hier weiß ich nicht so recht, aus welchen IP Adreßkreisen O2 zu mir herantritt. Hier (und in der Firewall) wären Einschränkungen nicht nur sinnvoll, sondern auch notwendig. Wenn diese Einträge nicht vorhanden sind, sprudelt es in den Log Dateien nur so von Verbindungsversuchen aus aller Herren Länder. Hier wären die ITSP in der Pflicht, im Kontext der Gesetzesnovelle zum FTEG mit Wirkung vom 01.08.2016 (Routerfreiheit) dafür zu sorgen, daß solche Informationen transparent und eben zum Portfolio der Zugangsdaten gehören.

Das Problem der DNS Namensauflösung sehe ich im Kontext der Spionage und des Abgreifens persönlicher Informationen: es ist hinlänglich bekannt, daß DNS Anfragen zur Generierung von Bewegungsprofilen benutzt werden können. Zwar kann man juristisch dem ITSP gemäß BDSG der Nutzung widersprechen, aber wer hält sich denn schon in den südeuropäischen Ländern an sowas, wenn das selbst hierzulande nicht klappt? Zudem ist auch bekannt, daß die ISPs Anfragen "umbiegen", um ihren Werbe- oder sonstigen Scheiß feilzubieten. Sicherlich wird man das nicht mit einem Google DNS 8.8.8.8 eliminieren können. Aber der CCC unterhält ebenfalls einige relativ schnelle DNS Systeme. Nur soviel dazu. Das sind einige, vielleicht hier nicht hingehörende Gedanken.

Kann dann der Name via DNS aufgelöst werden, erfolgt diese Log Meldung (bitte nicht an den unterschiedlichen Datumeinträgen stören, ich Logge und teste bereits seit einiger Zeit ...):

[... im debug Log ...]
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Outbound REGISTER attempt 10 to 'sip:sip.alice-voip.de' with client 'sip:[email protected]'
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Received REGISTER response 502(DNS "Name Error" (PJLIB_UTIL_EDNS_NXDOMAIN))
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Processing REGISTER response 502 from server 'sip:sip.alice-voip.de' for client 'sip:[email protected]'
[Jul 29 14:02:54] DEBUG[100413] res_pjsip_outbound_registration.c: Scheduling outbound registration to server 'sip:sip.alice-voip.de' from client 'sip:[email protected]' in 30 seconds

[Jul 23 10:22:34] DEBUG[100239] res_pjsip_outbound_registration.c: Received REGISTER response 401(Unauthorized 11030230330)
[Jul 23 10:22:34] DEBUG[100239] res_pjsip_outbound_registration.c: Processing REGISTER response 401 from server 'sip:sip.alice-voip.de:5060' for client 'sip:[email protected]:5060'
[Jul 23 10:22:34] DEBUG[100239] res_pjsip_outbound_registration.c: Scheduling outbound registration to server 'sip:sip.alice-voip.de:5060' from client 'sip:[email protected]:5060' in 60 seconds

[... im message Log ...]
[Jul 22 22:11:25] WARNING[100324] res_pjsip_outbound_registration.c: Temporal response '401' received from 'sip:sip.alice-voip.de:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'


Besonders interessant ist dieser Eintrag (message Log):

[...]
[Jul 21 12:44:46] WARNING[100263] res_pjsip_outbound_authenticator_digest.c: Host: '195.71.31.47:5060': Unable to create request with auth. No auth credentials for realm(s) 'ims.telefonica.de' in challenge.
[Jul 21 12:44:46] WARNING[100263] res_pjsip_outbound_registration.c: Failed to create authenticated REGISTER request to server 'sip:sip.alice-voip.de:5060' from client 'sip:[email protected]:5060'
[Jul 21 12:44:46] WARNING[100263] res_pjsip_outbound_registration.c: Fatal response '401' received from 'sip:sip.alice-voip.de:5060' on registration attempt to 'sip:[email protected]:5060', stopping outbound registration

Der Host: '195.71.31.47:5060' will offenbar etwas von mir, scheinbar eine Authentifikation und erwartet ein 'realm=ims.telefonica.de'. Von wo kommt diese Anforderung? Aus der registrierung meines Trunks oder der Authentifizierung meines "Endpoints"?

Nun, ich hoffe jemand hat ein paar Vorschläge oder konstruktive Gedanken.


[... Konfiguration PJSIP ...]

;-------------------------------------------------------------------------------
; Templates (c)
;-------------------------------------------------------------------------------
; Transport via UDP
[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= ddns.de
external_signaling_address= ddns.de

[registration_default](!)
transport= transport_udp
;retry_interval= 60
retry_interval= 30
forbidden_retry_interval= 180
fatal_retry_interval= 240
expiration= 120
max_retries= 90
auth_rejection_permanent= false


[endpoint_std_nat](!)
dtmf_mode= rfc4733
disallow= all
allow= g722
allow= g726
allow= alaw
allow= ulaw
rtp_symmetric= yes
force_rport= yes
rewrite_contact= yes
timers= yes
direct_media= no
language= de


;-------------------------------------------------------------------------------
; O2
;-------------------------------------------------------------------------------
[trunk_o2](registration_default)
type= registration
contact_user= 491234567890
outbound_auth= reg_trunk_o2
server_uri= sip:sip.alice-voip.de
;outbound_proxy= sip:ims.telefonica.de
client_uri= sip:[email protected]

[reg_trunk_o2]
type= auth
auth_type= userpass
username= 491234567890
password= GeheimesPW
;realm= sip.alice-voip.de

[trunk_o2](endpoint_std_nat)
type= endpoint
transport= transport_udp
context= internalsip_o2
callerid= 01234567890
from_user= 491234567890
from_domain= sip.alice-voip.de
outbound_auth= trunk_o2
auth= trunk_o2
aors= trunk_o2

[trunk_o2]
type= aor
max_contacts= 1
contact= sip:[email protected]

[trunk_o2]
type= auth
auth_type= userpass
username= 491234567890
password= GeheimesPW
;realm= sip.alice-voip.de

[trunk_o2_in]
type= endpoint
transport= transport_udp
context= o2_in
disallow= all
allow= g722
allow= g726
allow= alaw
allow= ulaw
outbound_auth= trunk_o2

[trunk_o2_in]
type= identify
endpoint= trunk_o2
;match= 195.71.31.0/24,193.189.245.0/24,213.20.127.47/24

 

[sparkie]

sorry, ohne deine Ausfuehrungen genauer gelesen zu haben...
Das ganze NAT und STUN Gedoens hat mich irgendwann so genervt, dass ich die externe Anbindung meines Asterisk nur noch per 'externaddr' konfiguriere.
So wie hier beschrieben:
https://www.ip-phone-forum.de/threads/firewallregeln-für-sip-anbieter.288452/#post-2188858

Damit verhaelt sich der Asterisk fuer die externen (im Internet befindlichen) Gegenstellen so, als wenn er direkt per oeffentlicher IP erreichbar waere. Obwohl er natuerlich auf irgendeinem geNATeten Rechner bei mir im Netz laeuft. Damit loesten sich bei mir ein Grossteil der Probleme mit externer Anbindung in Wohlgefallen auf

 

[Eisenfaust]

Dein Link beschreibt das ältere SIP.conf, ich habe aber geschrieben, daß ich PJSIP.conf verwende.

Die "direkte Methode" mit Verwendung der externen IP Adresse geht in meinem Falle nicht, weil ich den Asterisk in ein Jail einsperre/einsperren will. Ich konfiguriere ein Router-Firewall-System zu Fuß und benutze kein vorkonfektioniertes System.

 

[Zentronix]

O2 schweigt sich beharrlich auch darüber aus, wie man ein SIP Telephon anbindet

Ich habe auf dem Schreibtisch ein Snom-Telefon, das sich hinter einem NAT-Router befindet. In dieses habe ich einfach die Zugangsdaten eingetragen. Als da sind:

Account: 49XXXXXXXXXXX
Password: **********
Registrar: sip.alice-voip.de

Außer einem "Keepalive interval" sonst nix. Alles Standard. Kein Proxy. Kein STUN. Läuft.

Habe mal hier das SIP-Trace einer Neuregistrierung angehängt (zur Sicherheit mit "X"en etwas verfremdet). Vielleicht hilft's.

Sent to udp:195.71.31.47:5060 at Jul 29 20:XX:XX (780 bytes):

REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 192.168.XX.XX:2048;branch=zXXXXbK-m0XXXXXXXXvg;rport
From: "Mein-O2-Account" <sip:[email protected]>;tag=uaXXXXXXse
To: "Mein-O2-Account" <sip:[email protected]>
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 116 REGISTER
Max-Forwards: 70
User-Agent: snomXXX/8.7.5.35
Contact: <sip:[email protected]:2048;line=8XXXXX4l>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:aXXXXXXa-4XX9-4XXa-8XX9-XXXXXXXXXXXX>";audio;mobility="fixed";duplex="full";description="snomXXX";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog
X-Real-IP: 192.168.XX.XX
Supported: path, gruu
Expires: 0
Content-Length: 0

Received from udp:195.71.31.47:5060 at Jul 29 20:XX:XX (848 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.XX.XX:2048;received=77.181.XX.XX;rport=2048;branch=zXXXXbK-m0XXXXXXXXvg
To: "Mein-O2-Account" <sip:[email protected]>;tag=h7g4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXdf
From: "Mein-O2-Account" <sip:[email protected]>;tag=uaXXXXXXse
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 116 REGISTER
Contact: <sip:[email protected]:2048;line=8XXXXX4l>;expires=0;q=1.0;reg-id=1;+sip.instance="<urn:uuid:aXXXXXXa-4XX9-4XXa-8XX9-XXXXXXXXXXXX>";audio;mobility="fixed";duplex="full";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Path: <sip:195.71.31.47;transport=udp;lr>
Service-Route: <sip:195.71.31.47:5060;transport=udp;lr>
Content-Length: 0

Sent to udp:195.71.31.47:5060 at Jul 29 20:XX:XX (783 bytes):

REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 192.168.XX.XX:2048;branch=zXXXXXK-7ryXXXXXXXXe;rport
From: "Mein-O2-Account" <sip:[email protected]>;tag=gXXXXXXX64
To: "Mein-O2-Account" <sip:[email protected]>
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 117 REGISTER
Max-Forwards: 70
User-Agent: snomXXX/8.7.5.35
Contact: <sip:[email protected]:2048;line=8kXXXXX5>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:aXXXXXXa-4XX9-4XXa-8XX9-XXXXXXXXXXXX>";audio;mobility="fixed";duplex="full";description="snomXXX";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog
X-Real-IP: 192.168.XX.XX
Supported: path, gruu
Expires: 3600
Content-Length: 0

Received from udp:195.71.31.47:5060 at Jul 29 20:XX:XX (621 bytes):

SIP/2.0 401 Unauthorized 11030230330
Via: SIP/2.0/UDP 192.168.XX.XX:2048;received=77.181.XX.XX;rport=2048;branch=zXXXXXK-7ryXXXXXXXXe
To: "Mein-O2-Account" <sip:[email protected]>;tag=h7g4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9d
From: "Mein-O2-Account" <sip:[email protected]>;tag=gXXXXXXX64
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 117 REGISTER
Path: <sip:195.71.31.47;transport=udp;lr>
Service-Route: <sip:195.71.31.47:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="ims.telefonica.de",nonce="AF5EB99FACD17C590000XXXXXXXXXX29",algorithm=MD5,qop="auth"
Content-Length: 0

Sent to udp:195.71.31.47:5060 at Jul 29 20:XX:XX (1023 bytes):

REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 192.168.XX.XX:2048;branch=z9hXXXXXXXXXsejq1baf8;rport
From: "Mein-O2-Account" <sip:[email protected]>;tag=gXXXXXXX64
To: "Mein-O2-Account" <sip:[email protected]>
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 118 REGISTER
Max-Forwards: 70
User-Agent: snomXXX/8.7.5.35
Contact: <sip:[email protected]:2048;line=8kXXXXX5>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:aXXXXXXa-4XX9-4XXa-8XX9-XXXXXXXXXXXX>";audio;mobility="fixed";duplex="full";description="snomXXX";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog
X-Real-IP: 192.168.XX.XX
Supported: path, gruu
Authorization: Digest username="49XXXXXXXXXXX",realm="ims.telefonica.de",nonce="AF5EB99FACD17C590000XXXXXXXXXX29",uri="sip:sip.alice-voip.de",qop=auth,nc=00000001,cnonce="12b9c55a",response="4ab4343f65f36bbd69d5efab8138e0a0",algorithm=MD5
Expires: 3600
Content-Length: 0

Received from udp:195.71.31.47:5060 at Jul 29 20:XX:XX (632 bytes):

SIP/2.0 401 Unauthorized 1103023033C
Via: SIP/2.0/UDP 192.168.XX.XX:2048;received=77.181.XX.XX;rport=2048;branch=z9hG4bK-37rsejq1baf8
To: "Mein-O2-Account" <sip:[email protected]>;tag=h7g4EsXXXXXXXXXXXXXXXXXXXXXXXXXXX56c
From: "Mein-O2-Account" <sip:[email protected]>;tag=gXXXXXXX64
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 118 REGISTER
Path: <sip:195.71.31.47;transport=udp;lr>
Service-Route: <sip:195.71.31.47:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="ims.telefonica.de",nonce="3D9875C6AED17C590000XXXXXXXXXX0A",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0

Sent to udp:195.71.31.47:5060 at Jul 29 20:XX:XX (1023 bytes):

REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 192.168.XX.XX:2048;branch=z9hGXXXXXXXXXXXXXXXl;rport
From: "Mein-O2-Account" <sip:[email protected]>;tag=gXXXXXXX64
To: "Mein-O2-Account" <sip:[email protected]>
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 119 REGISTER
Max-Forwards: 70
User-Agent: snomXXX/8.7.5.35
Contact: <sip:[email protected]:2048;line=8kXXXXX5>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:aXXXXXXa-4XX9-4XXa-8XX9-XXXXXXXXXXXX>";audio;mobility="fixed";duplex="full";description="snomXXX";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog
X-Real-IP: 192.168.XX.XX
Supported: path, gruu
Authorization: Digest username="49XXXXXXXXXXX",realm="ims.telefonica.de",nonce="3D9875C6AED17C590000XXXXXXXXXX0A",uri="sip:sip.alice-voip.de",qop=auth,nc=00000001,cnonce="4f621e9d",response="e2f9c1d33c3b4cfdXXXXXXXXXXf0945",algorithm=MD5
Expires: 3600
Content-Length: 0

Received from udp:195.71.31.47:5060 at Jul 29 20:XX:XX (1012 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.XX.XX:2048;received=77.181.XX.XX;rport=2048;branch=z9hGXXXXXXXXXXXXXXXl
To: "Mein-O2-Account" <sip:[email protected]>;tag=h7g4EXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX5b
From: "Mein-O2-Account" <sip:[email protected]>;tag=gXXXXXXX64
Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
CSeq: 119 REGISTER
Contact: <sip:[email protected]:2048;line=8kXXXXX5>;expires=3590;q=1.0;reg-id=1;+sip.instance="<urn:uuid:aXXXXXXa-4XX9-4XXa-8XX9-XXXXXXXXXXXX>";audio;mobility="fixed";duplex="full";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Associated-Uri: <sip:[email protected]>
Path: <sip:195.71.31.47;transport=udp;lr>
Service-Route: <sip:195.71.31.47:5060;transport=udp;lr>
Content-Length: 0
Authentication-Info: qop=auth,rspauth="badffc8a4de17072XXXXXXXXXX257ca7",cnonce="4f621e9d",nc=00000001

Habe mir diesen SIP-Trace mal genauer angeschaut:

Call 116 ist die Aufhebung der bestehenden Registrierung (erkennbar am "Expires: 0").

Calls 117–119 bilden die erfolgreiche Neu-Registrierung. Warum dabei zweimal der 401er auftritt, entzieht sich meinem Verständnis. Einmal sollte eigentlich reichen zur Übermittlung der Challenge. Bin aber nicht der Super-SIP-Experte.

Grüße.

 

[Eisenfaust]

Hallo @Zentronix.

Vielen Dank für Deinen Beitrag. Ich konnte erst antworten.

Bis jetzt funktioniert meine Telephonie via O2 noch immer nicht. Mit "pjsip set logger on" kann ich mir Ähnliches auf der Konsole ansehen, allerdings erledigt sich mein Autorisierungsversuch schon beim ersten Mal mit "401", wie oben beschrieben.

Da ich kein SIP Experte bin kann ich auch wenig über "Autoprovisionierung" und dessen Mechniasmus (wenn überhaupt, abseits des TR-069 Protokolles) sagen. Evtl. erhält Dein SNOM VoIP Telephon Daten/Informationen, die nicht hier gezeigt sind? Wie ich Deinem Posting oben entnehme, ist das "Realm" mit "ims.telefonica.de" belegt. Diesen Host bzw. Namen sehe ich oft im Kontext der Fehlermeldungen. Ansonsten sehen meine Registrierungsdaten - bis auf die X ;-) - identisch aus.

Mit Asterisk bin ich noch nicht ganz firm, erstelle aber bei allen Verbindungsversuchen einige MBytes an Protokolldaten, die ich im Moment mit einem heuristischen Algorithmus auszuwerten versuche - ich habe derzeit zu viele Endgeräte im Spiel, vielleicht sollte ich einfach auch mal ein Telephon dazu mißbrauchen, eine Direktverbindung herzustellen. O2 könnte - nur eine Vermutung - das Trunking absichtlich stören.

Was mich noch interessiert:

SIP benötigt für die Abwicklung des RTP UDP Portfreigaben auf der Firewall. Da ich weder UPnP noch sonst eine sophistische Deep Inspection/Connection Trackking a la Linux verwende, weiß ich im Moment nicht so recht, ob sich nicht hieraus Probleme ergeben, die zwar mit sipgate.de Konten kein darstellen, aber die intransparente Abwicklung der Kommunikation mit O2 stören könnten. Um ankommende SIP Signalisierungen abwickeln zu können, werden alle UDP Kontaktaufnahmen auf Port 5060 - 5070 an den Asterisk PBX Server weitergeleitet. Wie aber behandelt man korrekt die UDP Traverse?

Gibt es, außer das RFC, gute (deutsche) Beschreibungen des SIP Protokolles? Ich habe diverse (in Englisch) gefunden, aber sie sind unvollständig und setzen teilweise viel zu viel Hintergrundwissen voraus.

Ich danke schon mal im voraus.

 

[koyaanisqatsi]

Warum dabei zweimal der 401er auftritt, entzieht sich meinem Verständnis.

Schau mal in der ersten OK Antwort vom Server unter: Contact:

Contact: <sip:[email protected]:2048;line=8XXXXX4l>;expires=0

...da hat ein Contact: zufälligerweise ein Expire von: 0
Und eben dieser Contact muss sich wieder registrieren.
Eigentlich hat da keine lokale IP was zu suchen.
Klappt den ein eingehender Anruf mit Audio in beide Richtungen?

Registerabfolge
1. Registrierungsversuch wird immer mit 401, aber mit einem: NONCE
2. Versuch mit richtig beantworteten NONCE bekommt: OK

 

[Zentronix]

Bis jetzt funktioniert meine Telephonie via O2 noch immer nicht. Mit "pjsip set logger on" kann ich mir Ähnliches auf der Konsole ansehen, allerdings erledigt sich mein Autorisierungsversuch schon beim ersten Mal mit "401", wie oben beschrieben.

Also eine 401 ist doch normal, da man damit zur Authentifizierung aufgefordert wird. Man bekommt mit dem 401 eine "Challenge" zugesendet, mit der man seine Autorisierungsdaten verschlüsselt.

Ich wunderte mich nur, warum das 401 gleich zweimal auftrat. Der erste Anmeldeversuch wurde abgewiesen (mit "stale=true"). Beim zweiten Versuch klappte es dann.

SIP benötigt für die Abwicklung des RTP UDP Portfreigaben auf der Firewall.

Ich habe keinerlei Portfreigaben gemacht, das macht bei mir die NAT-Firewall im Router ganz automatisch. Das SIP schlägt sich von innen durch, es muß aber in regelmäßigen Abständen (1 Minute oder so) wiederholt werden. Beim "Symmetrischen RTP" werden die UDP-Portnummern des abgehenden Datenstroms auch für den ankommenden Datenstrom verwendet und flutschen so durch die Firewall.

Grüße.

 

[Zentronix]

Schau mal in der ersten OK Antwort vom Server unter: Contact: ...

...da hat ein Contact: zufälligerweise ein Expire von: 0

Und eben dieser Contact muss sich wieder registrieren.

Ich habe absichtlich am Telefon auf Neuregistrieren gedrückt. Daher wohl der REGISTER mit Expires 0 zum Aufheben der bereits bestehenden Registrierung.

Hier nochmal in Kurzform die Requests und Replies (ohne die anfängliche Deregistrierung). Der 401 tritt doppelt auf:

------------------------------------------------------------------------
#117 -> REGISTER; Expires: 3600

#117 <- 401 Unauthorized
        WWW-Authenticate: Digest realm="ims.telefonica.de",nonce="AF5EB99FACD17C590000XXXXXXXXXX29",algorithm=MD5,qop="auth"
------------------------------------------------------------------------
#118 -> REGISTER; Expires: 3600
        Authorization: Digest username="49XXXXXXXXXXX",realm="ims.telefonica.de",nonce="AF5EB99FACD17C590000XXXXXXXXXX29",uri="sip:sip.alice-voip.de",qop=auth,nc=00000001,cnonce="12b9c55a",response="4ab4343f65f36bbd69d5efab8138e0a0",algorithm=MD5

#118 <- 401 Unauthorized
        WWW-Authenticate: Digest realm="ims.telefonica.de",nonce="3D9875C6AED17C590000XXXXXXXXXX0A",stale=true,algorithm=MD5,qop="auth"
------------------------------------------------------------------------
#119 -> REGISTER; Expires: 3600
        Authorization: Digest username="49XXXXXXXXXXX",realm="ims.telefonica.de",nonce="3D9875C6AED17C590000XXXXXXXXXX0A",uri="sip:sip.alice-voip.de",qop=auth,nc=00000001,cnonce="4f621e9d",response="e2f9c1d33c3b4cfdXXXXXXXXXXf0945",algorithm=MD5

#119 <- 200 OK
        Authentication-Info: qop=auth,rspauth="badffc8a4de17072XXXXXXXX
------------------------------------------------------------------------

Eigentlich hat da keine lokale IP was zu suchen.

Klappt den ein eingehender Anruf mit Audio in beide Richtungen?

Es klappt wirklich so.

Die lokale IP-Adresse wird wohl durch schlaue Server ersetzt (sprich: der SIP-Server erkennt, daß er mit der lokalen IP-Adresse aus dem aus dem Protokoll nichts anfangen kann und ersetzt sie durch die IP-Adresse aus der TCP-Kommunikation).

Audio geht auch. Meiner Meinung nach durch die Segnungen des Symmetric RTP.

Grüße.

 

[sparkie]

Beim "Symmetrischen RTP" werden die UDP-Portnummern des abgehenden Datenstroms auch für den ankommenden Datenstrom verwendet und flutschen so durch die Firewall.

das mag lange gut gehen aber nicht immer. Ich hatte frueher auch eine Loesung in der ich dachte ich lasse alles die NAT erledigen.

Bis dann in ganz spezielle Faelle eintraten, in denen die RTP Verbindung von extern kam und von intern kam nichts. So protokolliert im tcpdump. Anscheinend hat intern auf den extern gewartet, der aber nie durchkam. Seit ich die RTP Ports von extern nach innen immer 1:1 durchleite hatte ich nie mehr solche Probleme. Und eine besondere Gefahr geht von den statischen Portforwardings nicht aus.

Ist bei dir immer gewaehrleistet dass 'intern' zuerst sendet (um die Firewall zu oeffnen)?

 

[Zentronix]

Ist bei dir immer gewaehrleistet dass 'intern' zuerst sendet (um die Firewall zu oeffnen)?

Ob das gewährleistet ist, weiß ich nicht. Ich hoffe nur, daß der RFC 4961 (immerhin schon 10 Jahre alt) genug Magie auf die Hersteller der betroffenen Komponenten ausgestrahlt hat.

Im Büro telefonieren wir den ganzen Tag so und es hat noch keine Beschwerde gegeben. Vielleicht geht ja auch man Anfang mal ein Pieps verloren, ohne daß man es merkt.

Grüße.

 

[sparkie]

Vielleicht geht ja auch man Anfang mal ein Pieps verloren, ohne daß man es merkt.

ja genau, das hatte ich auch ich hatte mich immer ueber die 'lost packets' im tcpdump gewundert. Dann war schon klar warum die verloren gingen...

 

[Eisenfaust]

Damit mein "Faden" hier nicht weiter abdriftet und gekapert wird, möchte ich mich mit MEINEM Problem wieder zurückmelden.

Nochmals: ich bin nicht firm in Sachen Protokollanalyse, obschon ich einiges an (theoretischem) Rüstzeugs mitbringe.


Weiter unten seht Ihr den Registrierungsversuch meines PBX/Asterisk 13.17.0 mit dem SIP Server auf Seiten telefonica/O2. Es sind übrigens die einizgen beiden Meldungen, die sich in meinem Fall im gesamten Log wiederholen! REGSITER -> Registrierungsversuch, dann Antwort 401, dann nix mehr. Jetzt müßte doch

"Cseq: 15096 REGISTER" erneut erscheinen?

Mit dem Gerede bezgl. Firewall und NAT kann ich nicht viel anfangen, es ist indifferent. Meine Betriebssystemplattform ist FreeBSD, das IP-Filter "ipfw", ich verwende In-Kernel-NAT. Die Port Weiterleitung ist so konfiguriert, daß 5060/udp auf den Host (Jail) mit der IP geführt wird, auf der Asterisk läuft. Die Ports werden 1:1 weitergleitet. Derzeit ist die Firewall für Testzwecke auf "Durchzug" geschaltet, läßt also alles, was zum PBX geht, durch. Es gibt gewiß Firewalls, die via ALG die in den SIP Daten mittransportierten SDP Protokolldaten auswerten und entsprechend delegieren bzw. UDP Ports (oder TCP, je nach Konfiguration) offen halten oder öffnen, aber das ist ersteinmal irrelevant.

Vielleicht ergeben sich aus den hier gezeigten Fragmenten Anhaltspunkte, was schief geht. Mir gehen die Ideen aus, O2/telefonica hat mir schriftlich mitgeteilt, daß man weitere Informationen als die zur Verfügung gestellten nicht liefern wird und man geht auch nicht auf das Problem ein, daß die REGISTER Versuche bereits im Keim erstickt werden. Weil, wie unten zu sehen, bereits die Rückantwort 401 liefert und mein PBX offenbar gar keinen Cseq: xxx+1 REGISTER versuch unternimmt, nehme ich an, daß meine Authentifikationsdaten falsch sind - falsches Paßwort, falscher Username, was auch immer. Um justiziable Informationen zusammentragen zu können, werde ich mehr brauchen als nur das unten gezeigte :-(

Was passiert hier?



[...]
[Sep 1 17:32:06] VERBOSE[100189] res_pjsip_logger.c: <--- Transmitting SIP request (829 bytes) to UDP:213.20.127.47:5060 --->
REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;rport;branch=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
From: <sip:[email protected]>;tag=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
To: <sip:[email protected]>
Call-ID: yxyxyxyxyxyxyxyxyxyxyxyxyxyxy
CSeq: 15095 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 1800
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Max-Forwards: 70
User-Agent: Asterisk13
Authorization: Digest username="491234567890", realm="ims.telefonica.de", nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxx", uri="sip:sip.alice-voip.de", response="186x11yd2843a333fb11133315b44ff1", algorithm=MD5, cnonce="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", qop=auth, nc=00000001
Content-Length: 0


[Sep 1 17:32:06] VERBOSE[100188] res_pjsip_logger.c: <--- Received SIP response (589 bytes) from UDP:213.20.127.47:5060 --->
SIP/2.0 401 Unauthorized 1103003032F
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;rport=5060;branch=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
To: <sip:[email protected]>;tag=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
From: <sip:[email protected]>;tag=yyyyyyyyyyyyyyyyyyyyyyyyyyyyy
Call-ID: yxyxyxyxyxyxyxyxyxyxyxyxyxyxy
CSeq: 15095 REGISTER
Service-Route: <sip:213.20.127.47:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="ims.telefonica.de",nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",algorithm=MD5,qop="auth"
Content-Length: 0

[Sep 1 17:32:06] WARNING[100189] res_pjsip_outbound_registration.c: Temporal response '401' received from 'sip:sip.alice-voip.de' on registration attempt to 'sip:[email protected]', retrying in '30'

[...]

 

[Eisenfaust]

Mir gehen so langsam die Ideen aus.
Heute Morgen habe ich einen erneuten Versuch unternommen, meinen Asterisk mit O2 zu verbinden. Die Antwort der Gegenstelle lautet:

[...]
[Sep 10 09:29:49] WARNING[100160]: res_pjsip_outbound_registration.c:792 void schedule_retry(struct registration_response *, unsigned int, const char *, const char *): No response received from 'sip:sip.alice-voip.de:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '90'
[...]

Ist das nicht schön? Die Tage vorher kam es ab und an mal zu einem "Registered". Was mir im ersten Moment ein Frohlocken entgleiten ließ, wurde sogleich von viel Enttäuschung verfolgt. Wähle ich oder ein Familienmitgleid meine O2 Nummer, so erhalte ich jetzt "Die von Ihnen gewählte Rufnummer ist nicht vergeben"! Das ist eine Frechheit hoch drei.

Derweil hat sich Telefonica schriftlich auf meine Bitte hin, mir erweiterte Anmeldetdaten für SIP zukommenzulassen bzw. mit mir einen Paßwortwechsel durchzuführen, gemeldet. Eine ganze Seite nahezu schwachsinniger Äußerungen - beginnend mit: gerne hätten wir Ihr Problem telefonisch mit ihnen ...". Wie telefonisch, wenn ich kein Telephon habe, über das man mich erreichen kann? Und: die alternative Mobilnummer zeigt nicht an, daß mich O2 angerufen hat.

Mein Gejammer ist vermutlich eines unter vielen abertausenden in diesem Lande, die mit diesem iberischen UNternehmen die gleiche Freude haben, deshalb meine Frage hier wieder im sachlichen Kontext:

Kann man via Debugging Optionen des Asterisk so konfigurieren, daß erweiterte Daten, die der SIP Server auf O2 Seite schickt, angezeigt werden?

 

[Eisenfaust]

Ich würde gerne hier noch ein Addendum anbringen.

Meine obige Konfiguration arbeitet soweit auch mit O2. Soweit so gut. Aber auch nur "fast". Ein generelles Problem im Fahrwasser des Unternehmens Telefonica/O2 scheinen DNS Auflösungen zu sein. In einem anderen "Thread" habe ich das Problem näher erläutert. O2 nennt keine eindeutigen DNS Server, sie werden zufällig mit dem DHCP ausgeliefert und es scheint, als würden diese auch immer wieder verwürfelt. Der Host "sip.alice-voip.de" kann von externen DNS Servern nicht aufgelöst werden - nur manchmal erzielt man einen Treffer. In den O2 Foren kennen die sogenannten "O2 Gurus" scheinbar nur einen Terminus technicus, nämlich jenen der "nomadischen VoIP Nutzung" - damit wird nahezu jeder etwas komplexere Fehler erklärt, der abweichend von An-Ausschalten aufkommt.

Ich vermute, daß die externen Treffer bei Wahl eines bestimmten DNS oder Caches daher rühren, daß Volontäre eigene DNS pflegen und sip.alice-voip.de händisch einpflegen und manchmal diese Tabellen propagieren. O2 selbst löst "sip.alice-voip.de" nicht auf - manchmal, wenn man ns[1-3].telefonica.de oder ns[1-3].hansenet.de als DNS heranzieht.

Interessant ist, daß im Falle des glücklichen Umstandes einer (der vielen) IP für sip.alice-voip.de hanbhaft zuwerden und der entsprechenden Ersetzungen im Eingang gezeigten Konfiguration, eine Registrierung bei O2s Registrar möglich ist. Es klappt auch manchmal, daß ich mich von extern selber anrufen kann - dann klingelt das telephon nur ganz kurz und binnen weniger Millisekunden bricht aber die Verbindung wieder ab. Heraastelephonieren funktioniert überhaupt nicht, hier scheint es ein NAT Problem zu geben (PJSIP und entsprechende Einträge meines DDNS Eintrages), wenn sich mein Endpunkt bei O2 authentifizieren will.

Interessant wie kurios sind aber die Versuche mich selber anzurufen. Das klappt ein oder maximal drei Male, danach heißt es: "Die von ihnen gewählte Rufnummer ist nicht vergeben. Bitte rufen sie die Auskunft an." Das ist schon interessant, was sich mein (noch) Anbieter hier leistet!

Ich weiß also nicht, welche obskuren "Techniken" Telefonica verwendet, um das berüchtigte nomadische Nutzen des VoIP Anschlusses zu verhindern, jedenfalls scheinen verwürfelte DNS Server eine Rolle zu spielen.

Vielleicht hat jemand mehr Erfahrungen und auch Einsichten in dieses Thema. Ich würde mich freuen, mehr zu erfahren.

 

[koyaanisqatsi]

Moins

Ein zensurfreier DNS Server kennt kein: sip.alice-voip.de
...aber: alice-voip.de
Und ein UDP Scan auf Port 5060 ergab auch einen offenen Port.

nmap -sU -p5060 alice-voip.de

Starting Nmap 6.47 ( http://nmap.org ) at 2017-09-26 12:30 CEST
Nmap scan report for alice-voip.de (85.183.254.1)
Host is up (0.017s latency).
rDNS record for 85.183.254.1: www.alice-dsl.de
PORT     STATE         SERVICE
5060/udp open|filtered sip

Nmap done: 1 IP address (1 host up) scanned in 1.89 seconds

Vielleicht den mal probieren ?

Registrare
Eventuell ist sip.alice-voip.de wirklich nur der Registrar, der über einen Proxy ( alice-voip.de ? ) erreicht wird.
Ähnlich wie bei mehreren Fritz!Boxen im lokalen Netz, wo jede "fritz.box" als Registrarname hat aber adressiert wird über den Proxy, der die echte IP oder DNS der gemeinten Fritz!Box enthalten muss.

 

[sparkie]

O2 nennt keine eindeutigen DNS Server, sie werden zufällig mit dem DHCP ausgeliefert und es scheint, als würden diese auch immer wieder verwürfelt. Der Host "sip.alice-voip.de" kann von externen DNS Servern nicht aufgelöst werden - nur manchmal erzielt man einen Treffer.

wieso sollte es ueberhaupt die Verpflichtung von O2 sein, dass "sip.alice-voip.de" von extern aufgeloest werden kann?
In welcher Spec soll das stehen?
Dass der Sip-Server nur intern aufgeloest wird kann O2 jederzeit so handhaben. Was sie wohl auch tun

Es ist hingegen DEINE Aufgabe die per DHCP ausgelieferten DNS entsprechend auszuwerten und zu nutzen.

Falls es ein Problem fuer dich sein sollte von 'extern' an die 'internen' DNS zu kommen (was von O2 ohnehin nicht so vorgesehen ist) dann musst du halt ein Tunnel/VPN aufsetzen.
Obwohl das von O2 vermutlich eher nicht gewuenscht wird kommst du somit auch von extern ueberall dran.
Und umgehst somit Seiteneffekte der vielleicht etwas zickigen O2 DNS Konfiguration.

ich verstehe nicht wo da ueberhaupt ein Problem sein soll.

 

[Eisenfaust]

@koyaanisqatsi:
Vorab: vielen Dank!

Ich hatte in meiner Not auch schon "alice-voip.de" ausprobiert, allerdings stets(!) in Verbindung mit der URI des Registrars (also immer brav ALLE sip.alice-voip.de => alice.voip.de) gewandelt. ich habe nie mit nmap nach der Existenz des SIP Ports gesucht, sondern lediglich diesen angepingt ...

Jetzt habe ich Deinen (einfachen wie folgreichtigen - und im Resultat grandiosen!) Vorschlag ausprobiert - und siehe da: zumindest 'reinrufen kann ich! Ein großer Schritt. ich habe zwar kein Audio, da ich nicht weiß, auf welchen Ports O2 die RTP Kommunikation abwickelt (ich habe derzeit ein dümmliches Portforwarding von 10000-30000 (sipgate)). Kein Audio ist ja das übliche NAT/RTP Problem. Vielen Dank!

Schwer verdaubar ist zum Einen die Kost für mein Ego, daß ich die Permutation oben nicht selber durchgeführt habe - man wird streß- und betriebsblind!, deshalb nochmals vieln herzlichen Dank!. Zum Anderen aber war eine meine schriftlichen Anfragen an O2 eben die Frage nach Registrar und Proxy, da mir die Stellung beider durch das Studium der RFCs zum thema SIP/VoIP irgendwann klar wurde. Von O2 kam eine Seite sinnloses Geschwurbel und dann am Ende, im letzten Satz (1 Satz!), man habe mir zum xx.xx.2017 die SIP Daten bereits schriftlich mitgeteilt! DieFragen haben ich zwei Mal in präzisierter Form an Telefonica Bundesrepublik Deutschland geschickt. Die Antworten waren stets minder- bis nullwertig. In Anlehnung an Einträge in den TKom Foren versuchte ich mir hier Hilfen zu holen. Das ärgert mich gerade jetzt, ohne daß ich beschreiben kann wie sehr!

Danke!

 

[koyaanisqatsi]

streß- und betriebsblind

Mensch halt
...kenn ich nur zu gut.
Aber durch den ganzen Streß und Ärger merkt man sich dass besser, bleibt haften, fürs nächste mal.

Beim NAT RTP Problem kann ich leider (für Asterisk) nicht helfen.
...da mein Asterisk, auch aus Sicherheitsgründen, eine Fritz!Box als Gateway nutzt.
Und ich wahrlich kein Profi bin was das Absichern eines Asterisk vor "Sipvicious* Antestern" angeht.


* https://github.com/EnableSecurity/sipvicious

 

[Eisenfaust]

[...]
Beim NAT RTP Problem kann ich leider (für Asterisk) nicht helfen.
...da mein Asterisk, auch aus Sicherheitsgründen, eine Fritz!Box als Gateway nutzt.
Und ich wahrlich kein Profi bin was das Absichern eines Asterisk vor "Sipvicious* Antestern" angeht.


* https://github.com/EnableSecurity/sipvicious

Auch wenn mein Asterisk technisch gesehen auf dem selben Gerät sitzt wie Firewall und Routing Daemon, so ist es logisch gesehen doch so wie bei Dir - oder irre ich mich hier? Mein Asterisk wird in einem Jail zuhause sein und über eine eigene, virtuelle Netzwerkschnittstelle zum Router und von dort via Firewall/NAT nach außen geführt. Im Moment ist das automatisierte Erzeugen meines Routerimages mit Jails (es betrifft die automatisierte Installation der Software) noch Baustelle, allerdings sitzt Asterisk auf einem per Firewall getrennten Netzwerk, das via VLAN auch technisch von anderen Netzen isoliert werden soll - die Telephone haben nichts in unserem eigentlichen Server-LAN zu suchen.

Ich will damit sagen, daß Du doch ebenso NAT RTP Probleme kennen mußt, sofern Dein Asterisk in die Außenwelt will? Oder ist der Trunk über den SIP Client auf der AVM Kiste realisiert und Dein innernetzseitiger Asterisk dient als Trunk zur AVM FritzBox?

Wie dem auch sei. Factum est: Dein Ratschlag mit dem etwas anderen Proxy hat dazu geführt, daß ich mich jetzt via Registrar (den ich als IP angeben muß) registrieren kann UND wenigstens ab und an Anrufe von außen machen kann. Ich komme noch immer nicht nach draußen und habe in der Console permanent

[2017-09-27 19:43:47] WARNING[100847]: chan_sip.c:4072 int retrans_pkt(const void *): Retransmission timeout reached on transmission XYZ47110815XXXXXXXXXXXX for seqno 1 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Der Fehler tritt sofort auf, sobald in irgendeiner Form der O2 Trunk benutzt wird. Von innen nach außen komme ich überhaupt nicht. Ohne jetzt tiefer nachgesehen zu haben vermute ich, daß der Endpunkt für die abgehenden Rufe sich nicht authentifizieren kann, weil eben die Kommunikation nicht klappt. Warum auch immer. Ein Kollege hat mein Setup an seinem Telekom Anschluß ausprobiert - mit den entsprechenden Änderungen und dem gleichen Betriebssystem, ich muß dazu nur die SD Karte tauschen. Und: es geht dort auf anhieb, so wie es bei mir auch mit sipgate klappt. Lediglich das NAT/Firewall Gespann des Berkeley UNIX macht hier noch Probleme.

Ich weiß nicht, was O2 will oder macht. Das Unternehmen hat sich entschieden, einen Kunden loszuwerden. Mit IPv6 fällt der gesamte NAT Unsinn ohnehin weg. Ich bin mal gespannt, ob sich das positiv auf die handhabung ausübt.

Meines Wissens nutzt O2 ja ebenfalls IPv6. Die Telekom setzt doch derweil alles auf IPv6 auf - und via Tunnel wird dann von IPv6 auf IPv4 Ingress und umgekehrt Egress getunnelt - eventuell liegt hier das Geheimnis, weshalb es mit den vergatterten Anbieterroutern (O2 Horror Box) immer klappt. Aber alles Spekulation.