.titleBar { margin-bottom: 5px!important; }

[Problem] O2 BSA VDSL mit Asterisk 13 PBX

Dieses Thema im Forum "O2" wurde erstellt von Eisenfaust, 28 Juli 2017.

  1. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    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.
     
  2. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    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:491234567890@sip.alice-voip.de'
    [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:491234567890@sip.alice-voip.de'
    [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:491234567890@sip.alice-voip.de' 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:+491234567890@sip.alice-voip.de oder sip:491234567890@sip.alice-voip.de 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:491234567890@sip.alice-voip.de'
    [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:491234567890@sip.alice-voip.de'
    [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:491234567890@sip.alice-voip.de' 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:491234567890@sip.alice-voip.de: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:491234567890@sip.alice-voip.de: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:491234567890@sip.alice-voip.de: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:491234567890@sip.alice-voip.de: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:491234567890@sip.alice-voip.de: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:491234567890@sip.alice-voip.de

    [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:491234567890@sip.alice-voip.de

    [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
     
  3. sparkie

    sparkie Aktives Mitglied

    Registriert seit:
    13 Nov. 2005
    Beiträge:
    1,524
    Zustimmungen:
    12
    Punkte für Erfolge:
    38
    Beruf:
    Rentner
    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:)
     
  4. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    #4 Eisenfaust, 29 Juli 2017
    Zuletzt bearbeitet: 29 Juli 2017
    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.
     
  5. Zentronix

    Zentronix Mitglied

    Registriert seit:
    24 Jan. 2010
    Beiträge:
    368
    Zustimmungen:
    9
    Punkte für Erfolge:
    18
    #5 Zentronix, 29 Juli 2017
    Zuletzt bearbeitet: 29 Juli 2017
    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.

    Code:
    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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=uaXXXXXXse
    To: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>
    Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
    CSeq: 116 REGISTER
    Max-Forwards: 70
    User-Agent: snomXXX/8.7.5.35
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=h7g4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXdf
    From: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>;tag=uaXXXXXXse
    Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
    CSeq: 116 REGISTER
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=gXXXXXXX64
    To: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>
    Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
    CSeq: 117 REGISTER
    Max-Forwards: 70
    User-Agent: snomXXX/8.7.5.35
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=h7g4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9d
    From: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>;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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=gXXXXXXX64
    To: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>
    Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
    CSeq: 118 REGISTER
    Max-Forwards: 70
    User-Agent: snomXXX/8.7.5.35
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=h7g4EsXXXXXXXXXXXXXXXXXXXXXXXXXXX56c
    From: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>;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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=gXXXXXXX64
    To: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>
    Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
    CSeq: 119 REGISTER
    Max-Forwards: 70
    User-Agent: snomXXX/8.7.5.35
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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:49XXXXXXXXXXX@sip.alice-voip.de>;tag=h7g4EXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX5b
    From: "Mein-O2-Account" <sip:49XXXXXXXXXXX@sip.alice-voip.de>;tag=gXXXXXXX64
    Call-ID: 31353XXXXXXXXXXXXXXXXXXXXXXXX8-p6XXXXXXXXXe
    CSeq: 119 REGISTER
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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:49XXXXXXXXXXX@sip.alice-voip.de>
    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.
     
  6. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    #6 Eisenfaust, 29 Aug. 2017
    Zuletzt bearbeitet: 29 Aug. 2017
    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.
     
  7. koyaanisqatsi

    koyaanisqatsi IPPF-Urgestein

    Registriert seit:
    24 Jan. 2013
    Beiträge:
    10,671
    Zustimmungen:
    123
    Punkte für Erfolge:
    63
    Schau mal in der ersten OK Antwort vom Server unter: Contact:
    Code:
    Contact: <sip:49XXXXXXXXXXX@192.168.XX.XX: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
     
  8. Zentronix

    Zentronix Mitglied

    Registriert seit:
    24 Jan. 2010
    Beiträge:
    368
    Zustimmungen:
    9
    Punkte für Erfolge:
    18
    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.

    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.
     
  9. Zentronix

    Zentronix Mitglied

    Registriert seit:
    24 Jan. 2010
    Beiträge:
    368
    Zustimmungen:
    9
    Punkte für Erfolge:
    18
    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:

    Code:
    ------------------------------------------------------------------------
    #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
    ------------------------------------------------------------------------
    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.
     
  10. sparkie

    sparkie Aktives Mitglied

    Registriert seit:
    13 Nov. 2005
    Beiträge:
    1,524
    Zustimmungen:
    12
    Punkte für Erfolge:
    38
    Beruf:
    Rentner
    #10 sparkie, 29 Aug. 2017
    Zuletzt bearbeitet: 29 Aug. 2017
    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)?
     
  11. Zentronix

    Zentronix Mitglied

    Registriert seit:
    24 Jan. 2010
    Beiträge:
    368
    Zustimmungen:
    9
    Punkte für Erfolge:
    18
    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.
     
  12. sparkie

    sparkie Aktives Mitglied

    Registriert seit:
    13 Nov. 2005
    Beiträge:
    1,524
    Zustimmungen:
    12
    Punkte für Erfolge:
    38
    Beruf:
    Rentner
    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...
     
  13. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    #13 Eisenfaust, 1 Sep. 2017
    Zuletzt bearbeitet: 1 Sep. 2017
    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:491234567890@sip.alice-voip.de>;tag=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    To: <sip:491234567890@sip.alice-voip.de>
    Call-ID: yxyxyxyxyxyxyxyxyxyxyxyxyxyxy
    CSeq: 15095 REGISTER
    Contact: <sip:491234567890@XXX.XXX.XXX.XXX: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:491234567890@sip.alice-voip.de>;tag=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    From: <sip:491234567890@sip.alice-voip.de>;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:491234567890@sip.alice-voip.de', retrying in '30'

    [...]
     
  14. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    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:491234567890@sip.alice-voip.de: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?
     
  15. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    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.
     
  16. koyaanisqatsi

    koyaanisqatsi IPPF-Urgestein

    Registriert seit:
    24 Jan. 2013
    Beiträge:
    10,671
    Zustimmungen:
    123
    Punkte für Erfolge:
    63
    #16 koyaanisqatsi, 26 Sep. 2017
    Zuletzt bearbeitet: 26 Sep. 2017
    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.
    Code:
    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.
     
  17. sparkie

    sparkie Aktives Mitglied

    Registriert seit:
    13 Nov. 2005
    Beiträge:
    1,524
    Zustimmungen:
    12
    Punkte für Erfolge:
    38
    Beruf:
    Rentner
    #17 sparkie, 26 Sep. 2017
    Zuletzt bearbeitet: 26 Sep. 2017
    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.
     
  18. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    @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!
     
  19. koyaanisqatsi

    koyaanisqatsi IPPF-Urgestein

    Registriert seit:
    24 Jan. 2013
    Beiträge:
    10,671
    Zustimmungen:
    123
    Punkte für Erfolge:
    63
    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
     
  20. Eisenfaust

    Eisenfaust Neuer User

    Registriert seit:
    26 Dez. 2006
    Beiträge:
    46
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Beruf:
    Quertreiber
    Ort:
    Bundeshauptkloake (Berlin)
    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.