Recording-Problem

  • Ich habe gestern abend angefangen, auf dem gleichen Raspberry Pi einen Asterisk aufzusetzen - war dann aber zu müde, das bis zum Ende durchzuziehen.


    Bisher meldet sich der Asterisk nur an der FritzBox an, und zwar mit denselben Daten, wie vorher das DoorPi


    Das Interessante ist die folgende Fehlermeldung.
    Apr 10 04:41:52] ERROR[8943]: chan_sip.c:4195 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data


    So wie es aussieht, stimmt etwas mit der Kommunikation nicht. Lassen wir mal Asterisk für den Moment aus dem Spiel - denn die Wahrscheinlichkeit ist sehr hoch, dass dasselbe Problem auch bei der Kommunikation zwischen DoorPi und fritzBox auftritt


    SIP wird benutzt, um die Verbindung auszuhandeln. Die eigentlichen Audiopakete kommen danach über UDP-Ports. Offenbar ist die auftretende "Halbverbindung" (UDP-Pakete FritzBox -> DoorPi kommen an, UDP-Pakete DoorPi->FritzBox kommen nicht an) durch falsch ausgehandelte oder blockierte Ports zu erklären - und hinter einer FritzBox durchaus bekannt.


    Zu dieser Interpretation passt es auch, dass bei vielen Nutzern von DoorPi das einfach Out-of-the-Box funktioniert, bei anderen mit komplizierten FritzBox-Setups aber nicht. Oder mal nicht und mal doch.


    Ich werde heute deshalb ein wenig mit der FritzBox herumspielen. In die Runde aber vorerst die Frage: Kennt jemand eine einfache Möglichkeit, bei der Kombination linphone/DoorPi die im SIP ausgehandeltenUDP-Ports anzuzeigen ?


    LG


    pah

  • Mir sind noch zwei Dinge eingefallen:
    1. Test mit linphone4raspberry Beispiel
    https://wiki.linphone.org/wiki…_example:_security_camera


    Dazu eventuell auch http://www.linphone.org/free-sip-service.html einen Account anlegen, der angerufen werden soll und diesen als SIP-Server in der Config anlegen.


    2. Test ohne Anmeldung am SIP-Server


    Wenn Du in der Config den SIP-Server leer lässt, dann wird DoorPi ohne SIP-Server Unterstützung gestartet.
    Ich habe mir dann z.B. den Linphone-Client auf dem PC installiert und in der DoorPi Config eingetragen

    Code
    1. [EVENT_AfterStartup]
    2. 10 = sleep:3
    3. 20 = call:motom001@192.168.178.24


    motom001 ist mein Benutzername im Windows-Client
    die 192.168.178.24 ist die IP meines PC's


    Somit geht das Gespräch "vollkommen" an der Fritzbox vorbei, bzw. diese agiert nur als Switch (in meinem Fall nicht einmal das)

  • So, eine Woche später - Problem gelöst.


    Offenbar holt sich linphone - oder doorpi - von der FritzBox die IP-Adresse des Raspberry Pi, statt sich diese von der eigenen Kiste zu nehmen.


    Auf der FritzBox wiederum kann es passieren, dass der interne DNS-Eintrag noch auf eine alte (dynamisch vergebene) IP-Adresse verweist.


    Führte dazu, dass dieser Raspberry - inzwischen mit statischer IP *.*.*.195 - eine SIP-Registrierung als *.*.*.51 bekam. TCP-Pakete werden offenbar in der FritzBox automatisch umgeleitet, aber UDP aus irgendeinem Grund nicht. Mit anderen Worten: Die von *.*.*.195 kommenden UDP-Pakete wurden vom IP-Phone-Client der FritzBox nicht akzeptiert, denn der wartete ja auf solche von *.*.*.51.


    Soll ich jetzt der Firma AVM mal drei halbe Arbeitstage von mir in Rechnung stellen ?


    LG


    pah

  • Hi, evtl. könnt Ihr ja mal versuchen in der Web-GUI der FritzBox die IP Adresse von DoorPi fix zuweisen auch wenn man den Pi auf statische IP eingestellt hat.


    Was mich wundert ist das Linphone hier erst die FritzBox nach der eigenen IP-Adresse abfragt. Hier evtl. mal versuchen die 127.0....... einzutragen in der Sektion Linphone in der doorpi.ini.

  • "IP-Adresse des Raspberry Pi, statt sich diese von der eigenen Kiste zu nehmen"


    Offenbar macht doorpi mit der eigenen identity aus der doorpi.ini eine DNS-Anfrage bei der FritzBox - hat darum vom SIP-Server die *51 als angemeldete IP zurückerhalten. Das war jedenfalls den traces zu entnehmen: Authentifizierung erhalten für die *51, obwohl der Authentifizierungsrequest von der *195 ausging.


    Man könnte sich dagegen absichern, indem die zurückgelieferte IP mit der des Senders verglichen wird.


    Nea: Das ist normalerweise bei mir im Netz immer so - die FritzBox ist diesbezüglich etwas kritisch.


    LG


    pah

  • Hatte ja auch das Problem und dachte ich hätte es mit der manuellen Installation gelöst, war aber nicht so.
    Nachdem ich wieder keinen Ton hatte und die Info von pahenning gelesen habe, wurde ich auf der Fritzbox fündig.
    Obwohl ich Eth0 auf dem Raspberry disabled hatte und der Pi über WLan mit einer statischen IP (192.168.xxx.3) konfiguriert wurde, war der in der Fritzbox-Maske 2 mal mit einer unterschiedlichen IP und Mac-Adresse vorhanden.
    Einmal mit der IP als ich den Pi aufgesetzt habe (Dynamische IP 192.168.xxx.32) und einmal mit der statischen IP(192.168.xxx.3). Ich habe die statische IP(192.168.xxx.3) auf dem Pi in die Installations-IP(192.168.xxx.32) geändert und siehe da, er wurde nur noch einmal mit der Mac-Adresse des WLan's erkannt. Da ich meine Server und 24/7 Geräte gerne die IP 192.168.xxx.2-10 gebe, aber meine DoorPi schon im produktiven Einsatz habe, kam ich zu dem Schluss, das ich alles so belassen werde.
    Ich glaube das die 2 Mac-Adresse nicht die von eth0 war, sondern die vom Bluetooth. Ich kann das aber aus den oben genannten Gründen nicht mehr nachvollziehen.

  • Die MAC des Bluetooth-Adapters auf der FritzBox zu finden ? Das halte ich für nicht richtig

    Ja das ist unlogisch, aber ich hatte eth0 deaktiviert und der war mit ifconfig auch nicht mehr aufgeführt.


    Ich habe noch mal die IP auf 192.168.120.3 geändert und die DoorPi ist danach unter 192.168.120.3 und 32 zu erreichen.
    mit ifconfig hat sich nur die IP vom wlan0 auf 192168120.3 geändert.


    Habe eth0 wieder aktiviert für die MAC.
    Es ist nicht die Mac-Adresse von eth0 die ich in der Fritzbox angezeigt bekomme.
    192.168.120.3 hat die wlan-Mac b8:27:eb:5a:6a:48
    192.168.120.32 hat eine unbekannte MAC b8:27:eb:7a:7d:a7


    Es ist auch nicht die Bluetooth MAC, wo kommt die MAC wohl her ? :-)

    Gruß
    Wal


    Kaum macht man es richtig, funktioniert es auch !

    4 Mal editiert, zuletzt von Wal ()

  • Das habe ich aber nicht getestet!

  • Das Problem mit der doppelten IP lässt auch asterisk nicht kalt. Ich kämpfe seit einiger Zeit das, manchmal, asterisk die Verbindung von Clients ablehnt aufgrund dessen das hier wohl dieser Bug besteht. Wenn ich den dhcp-client auf dem Pi deinstalliere klappt die Verbindung einwandfrei.


    Siehe hierzu mein Thema:
    http://www.doorpi.org/forum/thread/259-asterisk-probleme/