J’avais acheté il y a quelques temps une oreillette bluetooth. À cette époque, j’avais vilainement galéré avec btsco et la stack bluetooth Linux, pour finalement obtenir un résultat moyennement satisfaisant puisque l’attachement de l’oreillette nécessitait moult manipulations.

Sur ma Debian flambant neuve, et pres de 3 ans plus tard, les choses se sont considérablement améliorées.

1. ajout des lignes suivantes dans le fichier ~/.asoudrc :

pcm.bluetooth {
         type bluetooth
         device 00:11:22:33:44:55
}

Ou vous remplacerez evidemment 00:11:22:33:44:55 par l’identifiant que vous retournera un hcitool scan, correspondant à votre oreillette.

2. création du fichier /etc/bluetooth/audio.service avec le contenu suivant :

[Bluetooth Service]
Identifier=audio
Name=Audio service
Description=Bluetooth Audio service
Autostart=true

Après un redémarrage de la stack bluetooth, /etc/init.d/bluetooth restart, il suffira alors de spécifier dans le logiciel souhaité, twinkle par exemple, “bluetooth” comme device in/out. Et non, ekiga ne supporte pas ça (ceci est explicitement ecrit ici)

Sur un sujet complètement different, pour assouvir les vils instincts de gamaize qui m’assaillent parfois, j’ai fait l’aquisition d’une NVidia 8600GT, une carte d’entrée de gamme chez NVidia, mais qui s’avère tout à fait efficace avec les jeux recents pour peu qu’on ne veuille pas taper dans des résolutions élevées. J’ai appris que ces cartes ne sont pas, loin s’en faut, livrées avec leur clocking optimal, comprendre qu’elles sont allègrement underclockées. La manipulation nécessaire à l’obtention de leur capacité prévue est la suivante :

Ajouter l’option Option "Coolbits" "1" à la section Device de votre /etc/X11/xorg.conf, redémarrer X11, installer puis démarrer nvidia-settings. Une section “Clock Frequencies” devrait être disponible. Séléctionnez “3D Clock Frequencies” et cliquez sur “Auto-detect”. Une fois les fréquences détectées, cliquer sur “apply”. J’ai gagné une centaine de mégahertz de cette façon. Attention, l’operation n’est pas permanente, un redémarrage de X réinitialise ces valeurs aux factory defaults, un petit script sera du meilleur effet pour automatiser ce parametrage.

Evidemment, le bestiau ne se raccorde que via un RJ45 magique.

Tout naturellement, je me tourne vers brctl et commence une conf des plus classiques à coups de brctl addbr br0; brctl addif blah blah blah vous connaissez tout ça par coeur. Et bah oui mais non. Il se trouve que ça merde à plein tubes cette histoire. Je ne sais pas si c’est parce que le lien vers l’exterieur se trouve sur le brin wireless, si c’est parce que ce dernier utilise WPA, mais le résultat est là, l’interface monte, fonctionne pendant quelques secondes / minutes, puis plus rien, néant, no route to host. Misère.
Je me souviens alors de ce tout petit tool, parprouted, qui permettait de faire du bridging ARP. Ni une ni deux :

# parprouted wlan0 eth0
# ifconfig 10.20.30.40

Je sette l’IP du snom, et.. et AH-AAAH DANS TON CUL BRCTL. Ça marche.
Voici la partie associé de mon /etc/network/interfaces

auto eth0
iface eth0 inet static
        pre-up parprouted wlan0 eth0
        address 192.168.30.21
        netmask 255.255.255.0
        gateway 192.168.30.1

Trop dur…

. libosip2 dont il dépend
. siproxyd lui même

Ça donne à peu près ça :

$ pwd
/home/imil/fonera/src/own/libosip2-2.2.2
$ export FONBUILD=/path/to/fonera/build/env
$ export FONENV=/path/to/fonera/fake/root/filesystem
$ CFLAGS=-I${FONBUILD}/staging_dir_mips/usr/include LDFLAGS="-L${FONBUILD}/staging_dir_mips/usr/lib -lcrypt" CC=mips-linux-uclibc-gcc ./configure --host=mips --disable-hashtable --prefix ${FONENV}
$ make && make install

FONBUILD est le chemin vers l’environnement de compilation décompressé
FONENV est mon point de montage CIFS mounté depuis la Fonera sur /usr/local
puis :

$ pwd
/home/imil/fonera/src/own/siproxd-0.5.13
$ CFLAGS=-I${FONBUILD}/staging_dir_mips/usr/include LDFLAGS="-L${FONBUILD}/staging_dir_mips/usr/lib -lcrypt" CC=mips-linux-uclibc-gcc ./configure --enable-fli4l-22-uclibc --enable-static --host=mips --prefix=${FONBUILD} --with-libosip-prefix=${FONBUILD}
$ make

À la fin de la compilation, j’obtiens un src/siproxyd que je scp dans l’/usr/bin de la Fonera.
Reste à créer un /etc/siproxyd.conf minimal :

if_inbound  = ath1
if_outbound = eth0
sip_listen_port = 5060
daemonize = 1
silence_log = 1
log_calls = 1
registration_file = /tmp/siproxd_registrations
autosave_registrations = 300
pid_file = /var/run/siproxd.pid
# on active le RTP proxy
rtp_proxy_enable = 1
rtp_port_low  = 7070
rtp_port_high = 7089
rtp_timeout = 300
rtp_dscp = 46
default_expires = 600
debug_level =      0x00000000
debug_port = 0
# 1.2.3.4 == l'ip de l'asterisk qui va effectivement enregistrer mes SIP phones
outbound_proxy_host = 1.2.3.4
outbound_proxy_port = 5060
outbound_proxy_port = 5060

Reste à ouvrir quelques ports sur la Fonera :

root@OpenWrt:/etc/init.d# tail -7 /etc/firewall.user
## -- VoIP
# SIP
iptables -t nat -A prerouting_rule -i $WAN -p udp --dport 5060 -j ACCEPT
iptables        -A input_rule      -i $WAN -p udp --dport 5060 -j ACCEPT
# RTP
iptables -t nat -A prerouting_rule -i $WAN -p udp --dport 7070:7089 -j ACCEPT
iptables        -A input_rule      -i $WAN -p udp -m udp --dport 7070:7089 -j ACCEPT

Et evidemment à entrer ces regles “à la main” pour qu’elles soient executées en live.
Moyennant quoi :

/usr/bin/siproxd

Et on admire la beauté d’un header SIP :

Sending to 4.3.2.1 : 5060 (NAT)
Transmitting (NAT) to 4.3.2.1:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bKde51f2040c5392cd5619453830d27d85;received=4.3.2.1
Via: SIP/2.0/UDP 192.168.10.231:5060;branch=z9hG4bK066469ba8
From: white ;tag=6af6d7ac5d3c755
To: 087XXXXXXX ;tag=as41ab49a5
Call-ID: a09785bc6c5225000878173ed3169649@192.168.10.231
CSeq: 1169873461 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: 
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing

Emouvant.

[channels]
; carte reliant la ligne Free
signalling=fxs_ks
context=free_pstn
channel => 1
language=fr
cidsignalling=bell
callerid=asreceived
callwaiting=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echotraining=yes
echocancelwhenbridged=yes
rxgain=00.0
txgain=00.0
callprogress=no
busydetect=yes
busycount=3
hanguponpolarityswitch=yes ; pour le raccrochage, aparemment pas supporté en 1.2

; carte reliant la ligne FT
signalling=fxs_ks
context=ft_pstn
channel => 2
language=fr
cidsignalling=bell
callerid=asreceived
callwaiting=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echotraining=no
echocancelwhenbridged=yes
rxgain=00.0
txgain=00.0
callprogress=no
busydetect=yes
busycount=3
hanguponpolarityswitch=yes

Apr 29 12:51:55 home /netbsd: Registered Span 2 (‘WCFXO/0′) with 1 channels
Apr 29 12:51:55 home /netbsd: wcfxo0: Out of space to write register 06 with e0
Apr 29 12:51:55 home /netbsd: wcfxo0: Out of space to write register 0f with 10
Apr 29 12:51:55 home /netbsd: 0: Failed to init DAA, giving up…

Et autres messages du driver de type:

wcfxo0: can’t map interrupt

Après quelques rapides recherches, je lis qu’il est souhaitable dans ce type de situation de :

. Activer l’option “Plug and Play OS” dans son BIOS
. Ajouter le support ACPI dans son noyau. Exemple :

options MPBIOS # configure CPUs and APICs using MPBIOS
options MPBIOS_SCANPCI # find PCI roots using MPBIOS
options MPACPI # configure CPUs and APICs using ACPI

acpi0 at mainbus0
options ACPI_PCI_FIXUP # PCI interrupt routing via ACPI
options ACPI_ACTIVATE_DEV # If set, activate inactive devices

Recompilation, installation du nouveau noyau, et depuis, tout semble se dérouler pour le mieux

Après avoir raccordé la ligne Free sur une des cartes X100P et la ligne FT sur l’autre, nous obtenons :

La présence des téléphones analogiques sur les lignes “Phone” assure simplement que si tout le systeme se vautrait lamentablement, des téléphones “classiques” seraient toujours en fonction.

Un ztcfg -vv nous donne désormais:

Keyword: [loadzone], Value: [fr]
Keyword: [defaultzone], Value: [fr]
Keyword: [fxsks], Value: [1-2]

Zaptel Configuration
======================

Channel map:

Channel 01: FXS Kewlstart (Default) (Slaves: 01)
Channel 02: FXS Kewlstart (Default) (Slaves: 02)

2 channels configured.

Reste à renseigner le zaptel.conf, comme par exemple nous l’explique ce lien accompagné de que celui ci, et nous découvrons alors :

*CLI> zap show channels
Chan Extension Context Language MusicOnHold
pseudo ft_pstn fr
1 free_pstn fr
2 ft_pstn fr
*CLI>

Maintenant, il suffit d’arranger l’extensions.conf pour placer les appels sur l’un ou l’autre des liens, voire de traiter chaque appel de manière distincte (ou pas !). Exemple rapide dans lequel je passe les appels en 0800 sur FT et le reste sur Free :

; send green numbers to ft hin hin hin
exten => _0800.,1,Dial(Zap/2/${EXTEN})
; if it’s a 10 digit number (i.e local call)
exten => _XXXXXXXXXX,1,Dial(Zap/1/${EXTEN})

tu vois le topo.

Sous NetBSD, avec le driver zaptel-netbsd (comms/zaptel-netbsd), on ajoute à son /etc/lkm.conf ceci :

/usr/pkg/lkm/mod_zaptel.o -s – /usr/pkg/sbin/zaptel_postinstall – -
/usr/pkg/lkm/mod_wcfxo.o -s – - – -

Et au boot on obtiendra :

FXO device: vendor=1057 product=5608 subvendor=1057
wcfxo0 at pci1 dev 11 function 0: Wildcard X100P
zaptel at wcfxo0 not configured
wcfxo0: interrupting at irq 6
Registered Span 2 (‘WCFXO/0′) with 1 channels
wcfxo: DAA mode is ‘FCC’
FXO device: vendor=1057 product=5608 subvendor=1057
wcfxo1 at pci1 dev 12 function 0: Wildcard X100P
zaptel at wcfxo1 not configured
wcfxo1: interrupting at irq 9
Registered Span 3 (‘WCFXO/1′) with 1 channels
wcfxo: DAA mode is ‘FCC’

Il est evidemment possible de faire ce chargement directement grace à modload -s (ne pas oublier le -s) et en prenant bien soin d’executer le script /usr/pkg/sbin/zaptel_postinstall qui créera les devices nodes nécessaires à l’exploitation de la carte.

Et maintenant, on va tout pêter le téléphone de la maison…

Lorsque que j’ai décidé de mettre en vrac mon installation telephonique, je m’étais dis que, tant qu’à faire, autant que ce soit loutre-compliant. Alors mes conversations téléphoniques seront désormais redirigées sur ceci :

Apr 22 12:16:19 vader kernel: snd-bt-sco revision 1.11 $
Apr 22 12:16:20 vader kernel: snd-bt-sco: snd-bt-scod thread starting
Apr 22 12:17:08 vader kernel: snd-bt-sco: playback_open
Apr 22 12:17:08 vader kernel: snd-bt-sco: capture_open
Apr 22 12:17:08 vader kernel: Bluetooth: SCO (Voice Link) ver 0.5
Apr 22 12:17:08 vader kernel: Bluetooth: SCO socket layer initialized

via ceci :

Apr 22 00:06:00 vader kernel: usb 2-1: new full speed USB device using ohci_hcd and address 2
Apr 22 00:06:01 vader kernel: Bluetooth: Core ver 2.8
Apr 22 00:06:01 vader kernel: NET: Registered protocol family 31

Tout le nécessaire pour faire fonctionner ce petit monde est expliqué ici. Sous ubuntu, tout est fourni de base, sous debian, il vous faudra récupérer btsco (akaBluetooth-alsa Project), le compiler et l’installer. Pas de panique il ne s’agit que d’un module kernel et un executable réalisant le pont entre le materiel, ici un handset, et le dongle bluetooth.

Il ne reste plus qu’à spécifier à votre logiciel de télephonie préféré que le device I/O son est désormais /dev/dspX (X == 1 chez moi), soit celui registeré par btsco, et le tour est joué.
Note, j’utilise pour le moment xten-lite comme softphone SIP, ekiga s’étant révélé particulièrement pénible durant nos tests (crashs, load permanent, registration SIP qui ne s’effectue pas, puis si, puis pas, etc etc). Ça me fait un peu mal au cul d’utiliser un soft propriétaire mais j’imagine qu’ekiga sera bientôt beaucoup plus stable.