What apt doesn't infer by itself when using backports

On a debian squeeze host I had to upgrade a package that pulls more than 40 dependencies.
The target version was provided by squeeze-backports.
I got sure that squeeze-backports was somewhere in /etc/apt/sources.list.d/, and so available.
Then I specified the backports candidate version:

sudo apt-get install package=bpo_version

No cigar.
Two of the pulled packages didn't exist in squeeze.
But why was apt trying to get them from squeeze, and not from squeeze-backports, to which package=bpo_version belongs?

The thing is that apt has been designed to do that.
The solution is to indicate explicitely the target release with the -t option:

sudo apt-get -t squeeze-backports install package=bpo_version

and that works smoothly.

Problem solved then? Yes, unless you're using Puppet, which doesn't allow you to specify the target release.
After spending some time with apt pinning, I've decided to script the update as an Exec in a manifest:
 

exec {'install_from_backport':
         command => '/usr/bin/apt-get -t squeeze-backports install package',
}

 package { "package":
         ensure => "bpo_version",
         require => [Exec['apt-get update'], Exec['install_from_backport']],
 }

Hope this saves some time to the reader, but feel free to indicate what you would have done instead.

Where WebRTC-enabled FreeSWITCH expects the DTLS certificate

WebRTC-enabled FreeSWITCH uses DTLS-SRTP.
For this reason it needs to generate a fingerprint, which requires a certificate.

While you can find here [1] hints on how to generate a certificate, it may be useful to know that FreeSWITCH expects the certificate to be located in:

/etc/freeswitch/tls/dtls-srtp.crt

I inferred this from the source code rather than finding it documented somewhere, so this may save the reader some time.
(But feel free to comment and point to a related documentation).

And if you generate a pem file, you can retrieve the required .crt by copying from the .pem just the certificate part.

[1] http://wiki.freeswitch.org/wiki/SIP_TLS#Configuration - Note: this document refers to the generation of certificates to enable TLS, rather than DTLS. Don't get confused by references to SIP encryption, and simply focus on the certificate generation.

Toggle line numbers on vim

For the series "I Can Survive Without Knowing This", how to toggle line numbers on vim:

:se nu!

You can enable automatically line numbers in your vimrc by adding 'se nu', or to make it a little more readable, 'set number'.

VoIP calls encoded with SILK: from RTP to WAV

SILK is a codec defined by Skype, but can be found in many VoIP clients, like CSipSimple.
It comes in different flavours (sample rates and frame sizes), from narrowband (8 KHz) to wideband (24 KHz).
Since Wireshark doesn't allow you to decode an RTP stream carrying SILK frames, I was curious to find a programmatic way to do it. In fact, this has also allowed to me to earn a "tumbleweed" badge in stackoverflow.

You may argue that a Wireshark plugin would be the right solution, but that's probably for another day.

Initially I thought it was sufficient to read the specification for RTP payload when using SILK; the truth is that I had to reverse engineer a solution by looking at SILK SDK's test vectors.

There, I discovered that a file containing SILK audio doesn't have the file header indicated in the IETF draft ("!#SILK"), but a slightly different one ("!#SILK_V3").

More importantly, each encoded frame is not preceded by a block header, but by two bytes specifying its length.

Given these findings, it was a matter of extracting the RTP payload for each packet.

In Wireshark, I've selected the RTP stream I wanted to decode and exported it as raw binary.

A problem was that SILK doesn't have a fixed length to represent an audio frame. By using libpcap (libpcap0.8 on Debian squeeze) though, I could simply loop on the list of packets, read each length, subtract the packet header length and retrieve the exact payload length. I did this in C, but any other libpcap implementation (e.g. for python or perl) would do. Using libpcap is not strictly necessary, but helps, in particular when padding is involved.

Once the bitstream was ready, I decoded it in raw PCM format with the decoder available in the SILK SDK (downloadable from here). I knew the original encoded audio was at 24 KHz and 20 msec/frame, which also happen to be the decoder's default settings.

$ ./decoder ~/silk_from_rtp.bit ~/silk_from_rtp.raw

From the raw PCM to a WAV, handy to play on any PC, the step is easy and sox does the job. I just had to specify the sample rate, again of course 24 KHz, the encoding (16 bit unsigned, little-endian), and that was it!

$ sox -V -t raw -b 16 -e signed-integer -r 24000 silk_from_rtp.raw silk_from_rtp.wav

UPDATE (11/9/2014): The SILK SDK (and dev.skype.com) has disappeared. If you want to download it, try this (I used version 1.0.9).

The quickest way to verify SIP connectivity

As simple as this:

sipsak -s sip:

sipsak will send an OPTIONS request to , defaulting to UDP port 5060.

The sound of silence (encoded with G.711)

There are times where you check the RTP streams in your VoIP capture and everything looks sane, although one or more parties in the call reported no audio.

Those times, in particular when G.711 is in use, can be made a little less frustrating by looking at the RTP payload.

In fact, it's possible that one party is just sending silence. With G.711 silence has its own coding, and it's easy to spot:

a-law: silence is either a payload entirely populated with 0x55 or 0xD5 (depending on the sign applied).
u-law: silence is a payload entirely populated with 0xFF.

debian packages - what version is available and from which repo?

'apt-cache' madison is the answer.

Example:

giavac@myhost$ apt-cache madison vim
       vim | 2:7.3.547-7 | http://ftp.uk.debian.org/debian/ wheezy/main amd64 Packages

From apt-cache man page:

 madison pkg...
           apt-cache's madison command attempts to mimic the output format and a subset of the functionality of the Debian archive
           management tool, madison. It displays available versions of a package in a tabular format. Unlike the original madison, it can
           only display information for the architecture for which APT has retrieved package lists (APT::Architecture).

Find files larger than a certain size

Not rocket science, but useful, and want to have it handy here.

Find files larger than 1M in '.':

find . -type f -size +1000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'