The point I was making (in my 15 minute talk at ecomm) was that SILK represents a best-effort codec, i.e. for any given connection/time it does the best it can by monitoring lost packets – rather like the way TCP/IP works. This contrasts with the TDM codecs which allocate a static amount of bandwidth at the start of a call and stick with that throughout.

In those terms I see Speex as (just) on the TDM side of the fence (and I agree that is a _totally_ subjective viewpoint) because the bandwidth 'allocation' is fixed for the duration of a call.

I'm totally with you on the disruptive benefits of open source. Skype is aware of them too, if their submission of SILK to the IETF as a standard goes through then they will almost certainly open source SILK too.

I'm afraid I'm ignorant of CELT – but I read that the benefits were in the higher sample rates (e.g. 48kHz), which isn't really current VoIP territory.

What you are expounding on the reasons why you prefer SILK. It might be valid, but that is not the contention. The point I am contending and that is characteristic of eComm crowd is to claim the world for one of them, fairness be damned. One would think that self-described disruptors will prefer true open source efforts, like Speex and CELT. OK, eComm decided not to shine light on them. But at least be historically accurate.

Jim: This is one of the troubles of deferring to people, especially when the person is amenable for open discussion.

it has similar quality/bitrate etc settings.

The difference for me (and the key point in our second SILK deployment) is that with SILK you can tweak the encoder settings from packet to packet as the network changes. In the Speex version I worked with you would have to re-inititialize the encoder when you want to adapt to changing conditions.

This sounds esoteric – but in a domestic setting, my wifi network varies wildly, depending on the Youtube usage of my children – with SILK we can adapt around that _during_ a call.

SILK also lets me set the expected packet loss, so the encoder can add an appropriate amount of redundant info for the PLC to use to recover the audio when a packet is lost.