Machbarkeit eigenes SIP-Phone

    • Offizieller Beitrag

    Ausgangslage:
    - PJSIP lässt sich bei mir nicht installieren
    - Linphone scheint bei einigen Probleme zu machen
    - Video Streaming wird von einigen benötigt
    - viele wünschen sich mehr Fokussierung von mir auf die Grundfunktionen einer TFE
    - Im Forum gibt es Experten für Netzwerk, Hardware, Software, VoIP, SIP, RTC, Sicherheit,...


    Wunsch:
    Ich würde gern eine Schnittstelle für Audio und Video Übertragung anbieten, die bei jedem out of the box lauffähig ist und an allen wichtigen Messpunkten Möglichkeiten zur Fehlersuche bietet. Mit Paketen wie linphone oder pjsua fällt mir das schwer.
    Warum das ganze nicht in einzelne Teile splitten und diese einzeln anbieten und kombinieren lassen?
    Jetzt brauche ich eure Hilfe, ob ich mich verrenne und ob es sinnvoll ist.
    - Audio und Video als RTC Stream bereitstellen (http://www.linux-projects.org/modules/news/)
    - SIP mittels Twisted (http://twistedmatrix.com/docum…wisted.protocols.sip.html)


    So kann jeder zuerst den Audio und den Video stream testen und konfigurieren.
    Wenn das geht, dann kann der RTC Stream genutzt werden und durch das SIP von DoorPi an den Client übergeben werden.
    Der SIP Client ist dann voll und ganz auf die Funktion als TFE zugeschnitten.


    Würde das aus eurer Sicht das Thema verbessern oder ist das verschenkte Zeit?


    Ich würde aber versuchen auch eine Alternative, z.b. linphone, weiterhin zu unterstützen.
    Wer kann mir bei diesem Vorhaben helfen?

    Hallo Thomas.


    Ich habe mich heute durch Linphone gewühlt und denke, eine Eigenentwicklung lohnt sich kaum. Linphone ist ziemlich gut dokumentiert und hat alles, was wir brauchen (und ne Menge mehr). Das Ding kann Logfiles produziere bis die SD Karte verglüht. Auf diese Weise habe ich auch ziemlich schnell rausbekommen welche Codec verwendet werden, und warum z.B. G722 nicht. Der ist nicht im Lieferumfang dabei. :)


    Realtime Communication ist echt nicht einfach. SIP ist da noch das leichteste weil nicht Zeitkritisch. RTP als reiner Stream bringt uns bei Verbindungen zu TK Anlagen nicht weiter. Ich würde dringend empfehlen bei Standards zu bleiben und das Rad nicht neu zu erfinden.

    • Offizieller Beitrag

    Dann brauche ich Hilfe bei der Richtung der Entwicklung.
    Ihr habt Probleme, von mir erwartet ihr Hilfe, ich soll wenn möglich das Rad nicht neu erfinden, aber mich auf die Grundfunktionen fokussieren...
    Aber wie? Was braucht ihr und was muss programmiert werden?
    Ich hab das Gefühl, dass ich mich im Kreis drehe....


    Ich würde gern den Schritt von einer Einmann-Programmierung hin zu einem Gemeinschaftsprojekt schaffen.

    Im SIP/RTC Bereich kann ich sicher unterstützen. Damit kenne ich mich einfach ziemlich gut aus und habe seit Jahren Erfahrung mit Fehlersuche etc. Mein Problem ist nur, ich bin nicht der "klassische" Entwickler und kenne Python seit ich mich mit DoorPi beschäftige. Ich denke, anderen geht es ähnlich. Da sollten wir erst mal eine Schnittstelle finden.

    BTW, ich habe auch noch ein bisschen in Sachen Video Stream rumgespielt und Motion ausprobiert. Auf den ersten Blick würde ich sagen, hat alles was man sich wünscht. Steuerbar über HTTP, kann selbst Events auslösen, braucht sehr wenig CPU. Klappt sogar mit der Fritzbox, allerdings momentan nur als Internet Dienst und nicht im Sprechstellenmodus. Weis der Geier warum, aber das lässt sich sicher rausfinden.

    Zitat von AndyGR42

    BTW, ich habe auch noch ein bisschen in Sachen Video Stream rumgespielt und Motion ausprobiert. Auf den ersten Blick würde ich sagen, hat alles was man sich wünscht. Steuerbar über HTTP, kann selbst Events auslösen, braucht sehr wenig CPU. Klappt sogar mit der Fritzbox, allerdings momentan nur als Internet Dienst und nicht im Sprechstellenmodus. Weis der Geier warum, aber das lässt sich sicher rausfinden.

    Hi,


    das klingt interessant. Da das hier eigentlich OT ist: Würdest Du das freundlicherweise in einem eigenen Thread beschreiben bitte?