Codec2 Call Testing Service

If I haven't been using Skype for a while, I check that everything is working properly using their 'Call Testing Service'. This service tells you to record a message, then plays it back.

Thinking that this would be great for testing a codec2-over-udp setup, I’ve been playing with a similar service, using this script:


ncat –udp -l \$LOCAL_HOST \$LOCAL_PORT –sh-exec ‘netstat -nu | grep
\$LOCAL_HOST:\$LOCAL_PORT | head -1 | cut -c 45-57 > /tmp/out.ip ;
timelimit -t10 -T1 cat > /tmp/out.c2 ; cat /tmp/morig.c2 /tmp/out.c2 >
/tmp/out2.c2 ; ncat –udp \`cat /tmp/out.ip\` \$LOCAL_PORT < /tmp/out2.c2'




This copies the first 10 sec. of a streamed udp transmission to our local host, then plays back a canned message (morig.c2) followed by the stored 10 seconds. The only difficulty is if more than one person connects at the same time, I'm not sure netstat will properly report each persons' IP address. If there is a way to ensure that netstat prints the connections in chronological order, then this script's concept will work. My guess is that I'll have to write this up in a programming language like Ruby to make sure the right connection gets the right message.

The major difference between this concept and the Skype service, is that this using this approach the service will only transmit once transmitted to. This is because plain UDP connections have no way for the server to 'know' that you want to listen to it until you actually transmit. Yes, it is possible to add additional information over the UDP session, but I think it will profit us to keep the data on the net as light-weight as possible, so as to emulate data streaming over radio channels, too.

Comments

Popular posts from this blog

Building and Operating a Transmitter from the Roaring 20s

Defining a 49:1 EFHW Transformer's Losses