this application allows calling or responding to a SIP "data" call (see RFC4040) Without going deep into the rabbithole of ISDN, this application implements only ppp and converts octet-based ppp data from pppd to bitsyncrhonous RFC1618 on the network side

It is not intended to develop this to a fully fledged all corner case handling application but exists only because of having a Fritz!Card and Fritz!Box with S0 and having seen https://www.youtube.com/watch?v=rQfy8T-VOs4 from "The Serial Port" channel

V.110, V.120 or X.75 is not implemented.

V.110 might be useful for this to be a GSM dialup server (or calling a ppp server that runs over GSM)

I don't see a need for X.75 since as far as I know usually ppp/internet was set up mostly using RFC1618

The reason why this application does not support emulating a AT modem is because this application will only work with ppp and not dealing with AT commands too calling pppd directly was choosen.

To use ipv6 instead of ipv4 for sip and rtp transport, just add --ipv6 to the command line If you don't want to register to a pbx, just don't set --reg, --user and --pass. If --bindport is not set the application will use a random port (not 5060) to bind itself to. If you want some consistency just set this value to something you find appropriate You can use --srtp to enable opportunistic srtp, if you call (--dial) or register (--reg) with sips: or sip:...;transport=tls, srtp will be mandatory

Fritz!Box note: CLEARMODE does not work when calling directly from an internal SIP extension to the Fritz!Box's internal S0 bus. The call must be routed through a PBX where the Fritz!Box is registered as a SIP client or trunk.

If the --pppd option is not used, a helper binary is employed to start pppd. This helper is a small setuid-root program with most parameters hard-coded.

Using the helper allows ppp-sip-isdn itself to run as an unprivileged user. For dial-in server deployments this is strongly recommended, since the SIP stack and media processing do not require root privileges.

The helper always uses the PPP options file:

/etc/ppp/options.isdn

PPP parameters should be configured there. IP addresses are provided by ppp-sip-isdn and therefore must not be specified in that file.

a options.isdn file for a dialin server might be something like

mp
proxyarp

The helper binary must be installed as:

/usr/local/libexec/ppp-sip-isdn/ppp-helper

(see the Makefile).

A typical installation is:

install ppp-helper /usr/local/libexec/ppp-sip-isdn/ppp-helper
#Only members of the dip group will then be permitted to start or stop PPP sessions through the helper.
chown root:dip /usr/local/libexec/ppp-sip-isdn/ppp-helper
chmod 4750 /usr/local/libexec/ppp-sip-isdn/ppp-helper

The helper validates:

the requested PTY belongs to the invoking user, local and remote IP addresses are syntactically valid

To authorize termination of a PPPD instance, the helper verifies:

• the specified PID exists,
• the process executable matches the configured PPPD path,
• the process was started with the helper-specific argv[0] identifier,
• the PTY used by the PPPD instance still belongs to the invoking user.

No user-supplied PPP options are passed to pppd; the executable path, configuration file and command-line arguments are fixed by the helper.

In doubt see the source code, but in general something like this on the "server" side

# user must be member of dip, see above
env SIP_PASS=secret ppp-sip-isdn --loglevel 1 --id sip:number@pbx.server --reg sip:pbx.server --user number --bindport 44444 --ppplocalip 10.0.1.1 --pppremoteipstart 10.0.1.2 --linecount 8

and on the "client" (channel bind 2 calls, as root because of pppd)

#as root because of pppd, else put every parameter in /etc/ppp/options.isdn and leave --pppd and run as user, must be member of group dip in that case
sudo env SIP_PASS=secret ppp-sip-isdn --loglevel 1 --id sip:number@pbx.server --reg sip:pbx.server --user number --pppd "noauth user myuser password mypassword mp" --bindport 44443 --linecount 2 --dial sip:dialinnumber@pbx.server

one one side (server)

sudo ppp-sip-isdn --loglevel 1 --id sip:serverside@localhost --pppd "noauth mp" --bindport 5060 --ppplocalip 10.0.1.1 --pppremoteipstart 10.0.1.2 --linecount 2

on the other side (client)

sudo ppp-sip-isdn --loglevel 1 --id sip:clientside@localhost --pppd "noauth mp" --bindport 5060 --dial sip:serverside@ip-of-server --linecount 2

you should get 2*64kbps. Once maybe that felt blazing fast, but except for nostalgia, this speed is useless today.

cd ppp-sip-isdn
git submodule init
git submodule update
make

I am looking for help from someone familiar with Cisco IOS voice gateways and ISDN BRI interfaces to create a setup guide for using a Cisco router as an ISDN-to-SIP CLEARMODE gateway for ppp-sip-isdn.

The goal is:

 Retro PC with ISDN card
        ↓
 ISDN S0 bus
        ↓
 Cisco router (voice-enabled + BRI card)
        ↓
 SIP CLEARMODE (RFC4040)
        ↓
 ppp-sip-isdn

Such a setup would make ppp-sip-isdn much more practical for retrocomputing enthusiasts, since Cisco voice routers with BRI interfaces are relatively common on the second-hand market and are often already owned by people interested in legacy networking and ISDN.

If you have experience configuring Cisco voice gateways, dial peers, and CLEARMODE/RFC4040 transport, contributions, configuration examples, or testing are highly appreciated.

Since PCMA over RTP consumes the same bandwidth as CLEARMODE, the same payload can be transmitted as PCMA as far as the telephony stack is concerned. Naturally, the stack must not perform any audio processing on the stream. If it leaves the audio untouched, this mode can be used to create a 64 kbps peer-to-peer data channel. This approach is entirely proprietary, likely never saw use in real-world systems, and is admittedly a bit of a hack. Its primary purpose is to test connectivity through PBXs that would otherwise refuse CLEARMODE calls. As a bonus, Wireshark can now let you hear what CLEARMODE would sound like. 🙂

simply pass --pcma on both ends