Linphone build structure and x86 support

General
1

Hi @ssumpf,

I’ve been digging into your repositories lately (depot/genode) and I’m finally starting to wrap my head around the Linphone structure.

I truly believe that porting Linphone is the ultimate “stress test” for anyone aiming to master the Genode architecture. Since it uses so many drivers and libraries at once, it’s the best way for me to make sure I really get how the whole framework works.

My ultimate goal is to get Linphone running as a full x86 experience. I’ve explored your current repos, but I wanted to ask: is there a specific branch in your Git where the build process is already somewhat “turn-key” or functional?

Even if the current state is ARM-specific, it would still be incredibly helpful. Seeing a working ARM baseline would clarify the missing pieces in my understanding (specifically regarding the Makefiles and artifacts handling).

2

@hamed: The linphone-sdk folder contains the SDK and builds the linphonec daemon, which provides basic VoIP functionality. linphone-simple is a small Ubuntu UI toolkit (now called Lomeri) based on ubports-linphone / linphone-simple · GitLab. I have build both for Sculpt-25.10 for the PinePhone, but it can be build for x86_64 as well. If I find the time, I will publish a version for Sculpt-26.04, which would be a good starting point. Right now, I would use the version from my goa-projects repo, Sculpt 25.10 and Goa for Sculpt-25.10. For 26.04 the project needs to be adjusted. There also might be some adjustments necessary for 25.10. Once it’s working for 25.10, the next goals would be to test it on x86, upgrade to 26.04, and upgrade the SDK to a current versions since it is quite dated.

2 Likes
3

Thank you for the detailed explanation. I haven’t worked with the goa tool yet and lack sufficient knowledge in it for now. Although I plan to dive into it as soon as possible, my mind is currently occupied with porting Linphone from ARM to x86, which is a very exciting challenge for me.

My goal is to achieve a static build during the project compilation, similar to the way .run scripts handle builds. Do you think I can fulfill my requirements by leveraging your goa project (which I’ve already looked into)?

What I’ve done so far is extract linphone-simple and linphone-sdk from the raw, pkg, and src folders in your depot, along with all their dependencies. However, I got stuck because the content.mk files were missing, and I’m not yet familiar with the concept of artifacts within the Genode framework.

I chose this specifically because it wasn’t available in your x86 version; I saw it as a personal challenge to port a project with many side effects to the system and get it running.

4

I tried to port Linphone to x86. (I must say, VFS, the OSS/GPU emulator, and the other components still blow my mind!)

The linphonec component is bound to nic_router with the IP address 10.0.3.2. nic_router itself registers with the IP 192.168.8.20.

On the other side, there is a local Linux instance set to 192.168.8.10 running linphonec.

I also added a few port forwarding rules to nic_router:

<udp-forward port="5060" domain="downlink" to="10.0.3.2"/>
<tcp-forward port="5060" domain="downlink" to="10.0.3.2"/>
<udp-forward port="7078" domain="downlink" to="10.0.3.2"/>
<udp-forward port="7079" domain="downlink" to="10.0.3.2"/>

I am working on version 25.11, but I am experiencing the same issue on 26.05 as well. By the way, I actually prefer the XML structure over the new TCL model :slight_smile:

Without these, calls wouldn’t connect from either side. However, with port forwarding enabled, incoming call requests go through and can be accepted, but after that, no audio is passed at all—there is complete silence, and as a result, the call automatically drops after 30 seconds.

I should also mention that I tried fine-tuning the configuration using the factory files attached. Furthermore, despite this issue, text messaging works perfectly fine in this setup. Ring tones and incoming call ringtones are also audible on both sides without any problems.

I wanted to ask: Do I need to modify anything in the attached factory files or the .run configuration? Or could this be a driver connectivity issue—meaning that even though it rings, there might be a driver-level issue in mediastream2 that I’m overlooking?

<start name="nic_router" caps="500" ram="10M" priority="-1">
    <provides>
        <service name="Nic"/>
        <service name="Uplink"/>
    </provides>
    <config verbose_domain_state="yes" verbose_packet_drop="no" verbose_packets="no" >

        <policy label_prefix="drivers" domain="uplink"/>
        <policy label_prefix="linphonec" domain="downlink"/>

        <domain name="uplink" interface="192.168.8.20/24" gateway="192.168.8.10" >
            <nat domain="downlink"
                udp-ports="16384"
                tcp-ports="16384"
                icmp-ids="16384"
            />

            <udp-forward port="5060" domain="downlink" to="10.0.3.2"/>
            <tcp-forward port="5060" domain="downlink" to="10.0.3.2"/>
            <udp-forward port="7078" domain="downlink" to="10.0.3.2"/>
            <udp-forward port="7079" domain="downlink" to="10.0.3.2"/>
            
        </domain>

        <domain name="downlink" interface="10.0.3.1/24">
            <dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_config_from="uplink"/> 

            <tcp dst="0.0.0.0/0"> <permit-any domain="uplink"/> </tcp>
            <udp dst="0.0.0.0/0"> <permit-any domain="uplink"/> </udp>
            <icmp dst="0.0.0.0/0" domain="uplink"/>
        </domain>
    </config>        
</start>


<start name="linphonec" caps="800" ram="512M" priority="-1">
    <config ld_verbose="on">
        <env key="HOME" value="/home"/>

        <arg value="linphonec"/>
        <arg value="-a"/>
        <arg value="-b"/>
        <arg value="/home/factory.settings"/>
        <arg value="-s"/>
        <arg value="sip:192.168.8.10:5060"/>
        <arg value="-l"/>
        <arg value="/dev/log"/>
        <arg value="-d"/>
        <arg value="6"/>

		<libc stdin="/dev/null" stdout="/dev/log" stderr="/dev/log"
		      rtc="/dev/rtc" socket="/socket" pipe="/pipe" rng="/dev/random">
		</libc>

        <vfs>
			<dir name="dev">
				<log/><null/>
				<jitterentropy name="random"/>

				<oss name="dsp" verbose="on" ifrag_size="2048" ofrag_size="2048"/>
				<rtc/>
			</dir>
			<dir name="pipe"> <pipe/> </dir>
			<dir name="socket"> <lxip dhcp="yes"/> </dir>
			<dir name="share">
				<tar name="share-belr.tar"/>
				<rom name="rootca.pem"/>
				<rom name="ringback.wav"/>
				<rom name="oldphone-mono.wav"/>
			</dir>
			<dir name="etc">
				<inline name="resolv.conf">
                    nameserver 8.8.8.8
                </inline>
                <inline name="nsswitch.conf">
                    hosts:dns
                    networks:dns
                </inline>
			</dir>
			<rom name="hello8000.wav"/>
			<rom name="hello44100.wav"/>
			<dir name="home">
				<dir name=".local">
					<dir name="share">
						<dir name="linphone">
							<ram/>
						</dir>
					</dir>
				</dir>
				<rom name="factory.settings"/>

				<fs/>
			</dir>
        </vfs>
    </config>



[sip]
root_ca=/share/rootca.pem
verify_server_certs=1
verify_server_cn=1
use_ipv6=0
ipv6_migration_done=1
default_proxy=0
media_encryption=none
inc_timeout=30
in_call_timeout=0
delayed_timeout=4
auto_answer=1

[rtp]
ipv4_sdp_address=192.168.8.20
audio_rtp_port=7078
audio_jitt_comp=60
media_encryption=none


[sound]
remote_ring=/share/ringback.wav
local_ring=/share/oldphone-mono.wav
echocancellation=1
ec_delay=100

[net]
nat_address=192.168.8.20
firewall_policy=nat_address

[nat_policy_0]
nat_address=192.168.8.20
type=nat_address
5

@hamed: I cannot find any obvious mistake in your configuration. For Sculpt 26.05 I built the Linphone scenario for the PinePhone as well and I also was not able to get audio working (it was working with the 25.10 release). I did not investigate the problem any further, but there might be a chance that the linephone-sdk in my goa-projects is outdated and not working properly. I briefly looked into updating the SDK, but at the time the gitlab servers of the project had issues when checking out the various submodules.

Anyway, it looks like you got pretty far :+1:

1 Like