Just a quick note to say I’ve updated my Android app for automatically launching a full screen web viewer to be able to use file:// URLs.
This mean you can now store the opening page on the device it’s self.
You can find it on the app store here
So, I thought this would be a lot harder than it ended up being1.
Over the last few posts I’ve been walking through the parts needed to build a super simple miniature ISP and one of the last bits I think (I know I’ll have forgotten something) we need is a way to limit the bandwidth available to the end users.
Normally this is mainly done by a step in the chain we have been missing out, that being the actual DSL link between the users house and the exchange. The length of the telephone line imposes some technical restrictions as well as the encoding scheme used by the DSL modems. In the case I’ve been taking about we don’t have any of that as it’s all running directly over Gigabit Ethernet.
Limiting bandwidth is called traffic shaping. One of the reasons to apply traffic shaping is to make sure all the users get a consistent experience, e.g. to stop one user maxing out all the backhual bandwidth (streaming many 4k Netflix episodes) and preventing all the other users from being able to even just browse basic pages.
Home broadband connections tend to have an asymmetric bandwidth profile, this is because most of what home users do is dominated by information being downloaded rather than uploaded, e.g. requesting a web page consists of a request (a small upload) followed by a much larger download (the content of the page). So as a starting point I will assume the backhaul for our ISP is going to be configured in a similar way and set each user up with similar asymmetric set up of 10mb down and 5mb up.
Initially I thought it might be just a case of setting a couple of variable in the RADIUS response. While looking at the dictionary for the RADIUS client I came across the dictionary.roaringpenguin file that includes the following two attribute types
Since Roaring Penguin is the name of the package that provided the pppoe-server I wondered if this meant it had bandwidth control built in. I updated the RADIUS configuration files to include these alongside where I’d set Acct-Interim-Interval so they are sent for every user.
post-auth {
update reply {
Acct-Interim-Interval = 300
RP-Upstream-Speed-Limit = 5120
RP-Downstream-Speed-Limit = 10240
}
...
}Unfortunately this didn’t have any noticeable effect so it was time to have a bit of a wider look.
Linux has a traffic shaping tool called tc. The definitive guide is included in a document called the Linux Advanced Routing and Traffic Control HowTo and it is incredibly powerful. Luckily for me what I want is relatively trivial so there is no need to dig into all of it’s intricacies.
Traffic shaping is normally applied to outbound traffic so we will deal with that first. In this case outbound is relative to the machine running the pppoe-server so we will be setting the limits for the user’s download speed. Section 9.2.2.2 has an example we can use.
# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540This limits the out going connection on device ppp0 to 220kbit. We can adjust the values for the rate to 10240kbitor 1mbitto get the right speed.
Traffic coming into the device is controlled with ingress rules and is called policing. The tc-policing man page has example for limiting incoming traffic.
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 \
match u32 0 0 \
police rate 1mbit burst 100kWe can change the device to ppp0 and the rate to 5mbit and we have what we are looking for.
Setting this up on the command line once the connection is up and running is easy enough, but it really needs to be done automatically when ever a user connects. The pppd daemon that gets started for each connection has a script that can be used to do this. The /etc/ppp/ip-up.sh script is called and in turn this calls all the scripts in /etc/ppp/ip-up.d so we can include a script in there to do the work.
The next trick is where to find the settings. When setting up the pppoe-server we added the plugin radattr.so line to the /etc/ppp/options file, this causes all the RADIUS attributes to be written to a file when the connection is created. The file is /var/run/radattr.ppp0 (with the prefix changing for each connection).
Framed-Protocol PPP
Framed-Compression Van-Jacobson-TCP-IP
Reply-Message Hello World
Framed-IP-Address 192.168.5.2
Framed-IP-Netmask 255.255.255.0
Acct-Interim-Interval 300
RP-Upstream-Speed-Limit 5120
RP-Downstream-Speed-Limit 10240With a little bit of sed and awk magic we can tidy (environments can’t contain - & we need to wrap the string value in ") that up and turn it into environment variables and a script to set the traffic shaping.
#!/bin/sh
eval "$(sed 's/-/_/g; s/ /=/' /var/run/radattr.$PPP_IFACE | awk -F = '{if ($0 ~ /(.*)=(.* .*)/) {print $1 "=\"" $2 "\""} else {print $0}}')"
if [ -n "$RP_Upstream_Speed_Limit" ];
then
#down
tc qdisc add dev $PPP_IFACE root tbf rate ${RP_Upstream_Speed_Limit}kbit latency 50ms burst 1540
#up
tc qdisc add dev $PPP_IFACE handle ffff: ingress
tc filter add dev $PPP_IFACE parent ffff: u32 \
match u32 0 0 \
police rate ${RP_Downstream_Speed_Limit}kbit burst 100k
else
echo "no rate info"
fi
Now when we test the bandwidth with iperf we see the the speeds limited to what we are looking for.
1 This is a super simple version that probably has lots of problems I’ve not yet discovered and it would be good to try and set up something that would allow a single user to get bursts of speed above a simple total/number of users share of the bandwidth if nobody else is wanting to use it. So it’s back to reading the LARTC guide to dig out some of the more advanced options.
I’ve been meaning to get round to this ever since the Pi Supply Kickstarter delivered my LoRa Gateway HAT and the LoRa Node pHAT.
They have been sat in their boxes waiting until I had some spare time (and I’d finally finished moving a few things around to free up a spare Pi).
LoRa is a long range, low bandwidth radio system that uses the unlicensed spectrum. When combined with the higher level LoRaWAN protocol it makes great IoT platform for low power devices that want to send low volumes of data in places where there is no WiFi coverage and can’t justify the cost of a cellular connection.
LoRaWAN allows you to deploy a collection of Gateway devices that can act as receivers for a large number of deployed devices. These gateways then forward on messages to central point for processing.
A group called The Things Network run a LoRaWAN deployment. They are aiming for as large a coverage area as possible. To do this they allow users to deploy their own gateways and join these to the network. By joining the network you get to use everybody elses gateways in exchange for letting other people use yours.
This was particularly easy. I just had to download an image and flash it to a SD card. Stick that into the pi along with an ethernet cable and some power.
After the pi boots up you point your browser at http://iotloragateway.local and fill in a couple of values generated when I registered the gateway on the TTN site and that was it. The gateway is now up and running and ready to send/receive packets from any devices in range.
In order to test the gateway I need to set up a Pi Zero with the LoRa Node pHAT. This was a little trickier, but not much.
Fist I had to disable the Linux serial console, this can be done using the raspi-config command. I also had to add dtoverlay=pi3-miniuart-bt /boot/config.txt.
That was all that was needed to get the hardware configured, as for the software there is a rak811 python package that supplies the api and utilities to work with pHAT.
I now needed to declare an application on The Things Network site, this is how messages get routed to be processes. Taking the values for this application I could now write the following helloWorld.py
#!/usr/bin/env python3
from rak811 import Mode, Rak811
lora = Rak811()
lora.hard_reset()
lora.mode = Mode.LoRaWan
lora.band = 'EU868'
lora.set_config(app_eui='xxxxxxxxx',
app_key='xxxxxxxxxxxx')
lora.join_otaa()
lora.dr = 5
lora.send('Hello world')
lora.close()
Which can then be seen arriving in The Things Network console.
And I can subscribe directly to that data feed via MQTT:
$ mosquitto_sub -h eu.thethings.network -u 'lora-app1-hardill-me-uk' -P 'xxxxxxxxx' -v -t '+/devices/+/up'
{
"app_id": "lora-app1-hardill-me-uk",
"dev_id": "test-lora-pi-zero",
"hardware_serial": "323833356E387901",
"port": 1,
"counter": 0,
"is_retry": true,
"payload_raw": "SGVsbG8gd29ybGQ=",
"metadata": {
"time": "2019-08-10T15:45:07.568449769Z",
"frequency": 867.5,
"modulation": "LORA",
"data_rate": "SF7BW125",
"airtime": 61696000,
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "lora-gw1-hardill-me-uk",
"gtw_trusted": true,
"timestamp": 910757708,
"time": "2019-08-10T15:45:07Z",
"channel": 5,
"rssi": -91,
"snr": 7.75,
"rf_chain": 0,
"latitude": 51.678905,
"longitude": -2.3549008,
"location_source": "registry"
}
]
}
}
First up will be to get a better antenna for the gateway and to move the whole things up in the attic, from there it should get a good view north out towards the River Severn. After that I want to get a small battery powered LoRa/GPS board, like a TTGO T-Beam and ride round on my bike to get a feel for what the range/coverage actually is.
I’ll also be keeping an eye on the stats from the gateway to see if anybody else near by is deploying TTN LoRaWAN devices.
I have removed both of the apps in the title from the play store.
This is for a number reasons:
For the last few weeks I’ve been getting emails from AWS about Node 6.10 going end of life and saying I have deployed Lambda using this level.
The emails don’t list which Lambda or which region they think are at fault which makes tracking down the culprit difficult. I only really have 1 live instance deployed across multiple regions (and 1 test instance on a single region).
Clicking down the list of regions is time consuming and prone to mistakes.
In the email AWS do provide a command to list which Lambda are running with Node 6.10:
aws lambda list-functions --query="Functions[?Runtime=='nodejs6.10']"But what they fail to mention is that this only checks your current default region. I can’t find a way to get the aws command line tool to list the Lambda regions, the closest I’ve found is the list of ec2 regions which hopefully match up. Pairing this with the command line JSON search tool jq and a bit of Bash scripting I’ve come up with the following:
for r in `aws ec2 describe-regions --output text | cut -f3`;
do
echo $r;
aws --region $r lambda list-functions | jq '.[] | .FunctionName + " - " + .Runtime';
doneThis walks over all the regions as prints out all the function names and the runtime they are using.
eu-north-1
ap-south-1
eu-west-3
eu-west-2
eu-west-1
"Node-RED - nodejs8.10"
"oAuth-test - nodejs8.10"
ap-northeast-2
ap-northeast-1
sa-east-1
ca-central-1
ap-southeast-1
ap-southeast-2
eu-central-1
us-east-1
"Node-RED - nodejs8.10"
us-east-2
us-west-1
us-west-2
"Node-RED - nodejs8.10"
In my case it only lists NodeJS 8.10 so I have no idea why AWS keep sending me these emails. Also since I’m only on the basic level I can’t even raise a technical help desk query to find out.
Anyway I hope this might be useful to others with the same problem.
My post on DNS-over-HTTPS from last year is getting a fair bit more traffic after a few UK news paper articles (mainly crying that the new UK Government censoring won’t work if Google roll it out in Chrome… what a shame). The followning article has a good overview [nakedsecurity].
Seeing the scare stories in the news over the last few days, I offer this up again with no comment… https://t.co/KGlZ1l2O6s
— Ben Hardill (@hardillb) April 23, 2019
Anyway I tweeted a link to the old post and it started a bit of a discussion and the question about the other side of system came up. Namely how to use a DNS resolver that pushed traffic over DNS-over-HTTPS rather than provide a HTTPS endpoint that supported queries. The idea being that at the moment only Firefox & Chrome can take advantage of the secure lookups.
I did a bit of poking around and found things like stubby which DNS-over-TLS (another approach to secure DNS lookups) and also Cloudflare have cloudflared which can proxy for DNS-over-HTTPS to Cloudflare’s DNS server (it also is used to set up the VPN tunnel to Cloudflare’s Argo service, which is also worth a good look at.)
Anyway, while there are existing solutions out there I thought I’d have a really quick go at writing my own, to go with the part I’d written last year, just to see how hard it could be.
It turned out a really basic first pass could be done in about 40 lines of Javascript:
const dgram = require('dgram')
const request = require('request')
const dnsPacket = require('dns-packet')
const port = process.env["DNS_PORT"] || 53
//https://cloudflare-dns.com/dns-query
const url = process.env["DNS_URL"]
|| "https://dns.google.com/experimental"
const allow_selfSigned =
(process.env["DNS_INSECURE"] == 1)
const server = dgram.createSocket('udp6')
server.on('listening', function(){
console.log("listening")
})
server.on('message', function(msg, remote){
var packet = dnsPacket.decode(msg)
var id = packet.id
var options = {
url: url,
method: 'POST',
body: msg,
encoding: null,
rejectUnauthorized: allow_selfSigned ? false : true,
headers: {
'Accept': 'application/dns-message',
'Content-Type': 'application/dns-message'
}
}
request(options, function(err, resp, body){
if (!err && resp.statusCode == 200) {
var respPacket = dnsPacket.decode(body)
respPacket.id = id
server.send(body,remote.port)
} else {
console.log(err)
}
})
})
server.bind(port)
It really could do with some caching and some more error handling and I’d like to add support for Google JSON based lookups as well as the binary DNS format, but I’m going to add it to the github project with the other half and people can help extend it if they want.
The hardest part was working out I needed the encoding: null in the request options to stop it trying to turn the binary response into a string but leaving it as a Buffer.
I’m in the process of migrating my DNS setup to a new machine, I’ll be adding a DNS-over-TLS (using stunnel) & a DNS-over-HTTPS listeners for the public facing sides.
Recently I’ve been playing with how to build a Bluetooth audio device using a Raspberry Pi Zero. The following are some notes on what I found.
First question is why build one when you can buy one for way less than the cost of the parts. There are a couple of reasons:
I’m starting out with a standard Raspberry Pi Zero W. This gets me a base high level platform that includes a WiFi and Bluetooth.
The one thing that’s missing is an audio output (apart from the HDMI) but Raspberry Pi’s support audio using the I2S standard. There are several I2S pHATs available and I’m going to be using a pHAT DAC from Pimoroni. I’ve used these before for a project so I’m reasonably happy with how to set it up, but Pimoroni have detailed instructions.
I’m going to add a screen to show things like the current track title & artist along with the volume. I’m also going to need some buttons to send Play/Pause, Next & Previous commands to the connected device. I have a PaPiRus e-ink display that has 5 buttons built in which I was going to use but this clashes with the GPIO pins used for the DAC so instead I’ve opted for the Inky pHAT and the Button Shim.
I knew the core components of this had to be a problem others had solved and this proved to be the case. After a little bit of searching I found this project on github.
As part of the configuration we need to generate the Bluetooth Class bitmask. This can be done one this site.
This outputs a hex value of 0x24043C which is added to the /etc/bluetooth/main.conf
With this up and running I had a basic Bluetooth speaker that any phone can connect to without a pin and play music, but nothing else. The next step is to add some code to handle the button pushes and to update the display.
The Bluetooth stack on Linux is controlled and configured using DBus. Dbus is a messaging system supporting IPC and RPC
A bit of Googling round turned up this askubuntu question that got me started with the following command:
dbus-send --system --print-reply --dest=org.bluez /org/bluez/hci0/dev_44_78_3E_85_9D_6F org.bluez.MediaControl1.PlayThis sends a Play command to the connected phone with the Bluetooth mac address of 44:78:3E:85:9D:6F. The problem is knowing what the mac address is as the system allows multiple devices to pair with the speaker. Luckily you can use DBus to query the system for the connected device. DBus also has some really good Python bindings. So with a bit more poking around I ended up with this:
#!/usr/bin/env python
import signal
import buttonshim
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(
bus.get_object("org.bluez","/"),
"org.freedesktop.DBus.ObjectManager")
@buttonshim.on_press(buttonshim.BUTTON_A)
def playPause(button, pressed):
objects = manager.GetManagedObjects()
for path in objects.keys():
interfaces = objects[path]
for interface in interfaces.keys():
if interface in [
"orge.freedesktop.DBus.Introspectable",
"org.freedesktop.DBus.Properties"]:
continue
if interface == "org.bluez.Device1":
props = interfaces[interface]
if props["Connected"] == 1:
media = objects[path + "/player0"]["org.bluez.MediaPlayer1"]
mediaControlInterface = dbus.Interface(
bus.get_object("org.bluez",path + "/player0"),
"org.bluez.MediaPlayer1")
if media["Status"] == "paused":
mediaControlInterface.Play()
else:
mediaControlInterface.Pause()
signal.pause()
When button A is pressed this looks up the connected device, and also checks the current state of the player, is it playing or paused and toggles the state. This means that one button can be Play and Pause. It also uses the org.bluez.MediaPlay1 API rather than the org.bluez.MediaControl1 which is marked as deprecated in the doc.
The button shim also comes with Python bindings so putting it all together was pretty simple.
DBus also lets you register to be notified when a property changes, this paired with the Track property on the org.bluez.MediaPlay1 as this holds the Artist, Track Name, Album Name and Track length information supplied by the source. This can be combined with the Inky pHAT python library to show the information on the screen.
#!/usr/bin/env python
import dbus
from dbus.mainloop.glib import DBusGMainLoop
from gi.repository import GLib
def trackChanged(*args, **kw):
target = args[0]
if target == "org.bluez.MediaPlayer1":
data = args[1].get("Track",0)
if data != 0:
artist = data.get('Artist')
track = data.get('Title')
print(artist)
print(track)
DBusGMainLoop(set_as_default=True)
system_bus = dbus.SystemBus()
system_bus.add_signal_receiver(trackChanged,
dbus_interface="org.freedesktop.DBus.Properties",
signal_name="PropertiesChanged",
path='/org/bluez/hci0/dev_80_5A_04_12_03_0E/player0')
loop = GLib.MainLoop()
loop.run()
This code attaches a listener to the MediaPlayer object and when it spots that the Track has changed it prints out the new Artist and Title. The code matches all PropertiesChanged events which is a little messy but I’ve not found a way to use wildcards or partial matches for the DBus interface in python (since we don’t know the mac address of the connected device at the time we start listening for changes).
Converting the Artist/Title information into an image with the Pyton Image Library then getting the Inky pHAT to render that is not too tricky
from PIL import Image, ImageDraw, ImageFont
from font_fredoka_one import FredokaOne
from inky import InkyPHAT
...
disp = InkyPHAT("yellow")
font = ImageFont.truetype(FredokaOne, 22)
img = Image.new("P", (inky_display.WIDTH, inky_display.HEIGHT))
draw = ImageDraw.Draw(img)
draw.text((), "Artist: "+ artist, disp.WHITE, font=font)
draw.text((), "Track: "+ track, disp.WHITE, font=font)
disp.set_image(img)
disp.show()
That’s the basics working, now I need to find/build a case for it and then look at seeing if I can add Chromecast Audio and Airplay support.
Following on from my Alexa Home Skill for Node-RED it’s time to see about showing some love to the Google Home users (OK, I’ve been slowly chipping away at this for ages, but I’ve finally found a bit of time).
One of the nice things about Google Assistant is that it works all over the place, I can use it via the text interface if I’m somewhere and can’t talk, or even from the car via Android Auto.
Google offer a pretty similar API for controlling Smart home devices to the one offered by Amazon for the Alexa so the implementation of this was very similar. The biggest difference is the is no requirement to use something like Amazon’s Lambda to interface with the service so it’s just a single web endpoint.
I’ve taken pretty much the same approach as with the Alexa version in that I have a Web Site where you can sign up for an account and then define virtual devices with specific names and characteristics.
Google support a lot more different types of devices and characteristics than Amazon with Alexa at the moment, but to start with I’m just supporting Sockets/Light/Switches and Thermostats. I intend to add more later as I work out the best way to surface the data.
The other big change is that Google Assistant supports asynchronously updating the device state and the ability for the Assistant backend to query the state of a device. To support this I’m going to allow the response node to be configured with a specific device and to accept input that has not come from an input node.
The node is currently being beta tested, if you are interested post in #google-home-assistant on the Node-RED Slack and I can add you to the ACL for the beta.
I’ll do another post when the node has finished testing and has been accepted by Google.
I’ve been looking for a project for a bunch of ESP-8266 ESP-01 boards I’ve had kicking around for a while.
The following describes a simple button that when pushed publishes a MQTT message that I can subscribe to with Node-RED to control different tasks.
It’s been done many times before, but I wanted to have a go at building my own IoT button.
The code is pretty simple:
In order to get the best battery life you want the ESP8266 to be in deep sleep mode for as much as possible, so for this reason the loop function sends the message to signify the button has been pushed then indefinitely enters the deepest sleep state possible. This means the loop function will only run once on start up.
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#define ESP8266_LED 1
const char* ssid = "WifiName";
const char* passwd = "GoodPassword";
const char* broker = "192.168.1.114";
WiFiClient espClient;
PubSubClient client(espClient);
void setup() {
Serial.begin(115200);
delay(10);
pinMode(ESP8266_LED, OUTPUT);
WiFi.hostname("Button1");
WiFi.begin(ssid, passwd);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
client.setServer(broker, 1883);
reconnect();
}
void reconnect() {
while(!client.connected()) {
if (client.connect("button1")){
client.publish("button1", "press");
} else {
delay(5000);
}
}
}
void loop() {
if (client.connected()) {
reconnect();
}
client.loop();
// put your main code here, to run repeatedly:
digitalWrite(ESP8266_LED, HIGH);
delay(1000);
digitalWrite(ESP8266_LED, LOW);
delay(1000);
ESP.deepSleep(0);
}
By using a momentary push button wake the ESP-01 I bridged reset pin to ground the chip resets each time it’s pushed, this wakes it from the deep sleep state and runs the all the code, then drops back into the sleep state.
Now I had the basic circuit and code working I needed to pick a power supply. The ESP-01 needs a 3.3v supply and most people seem to opt for using a small LiPo cell. A single cell has a nominal fully charged voltage of 3.7v which is probably close enough to use directly with the ESP-01, but the problem is you normally need to add a circuit to cut them out before the voltage gets too low as they discharge to prevent permanently damage them. You would normally add a charging circuit to allow recharging from a USB source.
This wasn’t what I was looking for, I wanted to use off the shelf batteries so I went looking for a solution using AAA batteries. The board will run directly from a fresh set of 2 AAA batteries, but the voltage can quickly drop too low. To help with this I found a part from Pololu that would take an input between 0.5v and 5v and generate a constant 3.3v. This meant that even as the batteries discharged I should be able to continue to run the device.
At first things didn’t look to work, because converter was not supplying enough current for the ESP-01 at start up, to get round this I added a 100uF capacitor across the outputs of the regulator. I don’t really know how properly to size this capacitor so I basically made a guess.
The final step was to use the soldering iron to remove the red power LED from the board as this was consuming way more power than the rest of the system.
I’ve recently updated my local Asterisk PBX. The main reason for the update was that processing the logs in order to set up the firewall rules to block the folk that hammer on it all day long trying to make long distance calls or run up big bills on premium rate numbers was getting too much for the original Mk i Raspberry Pi B (it now runs on a Pi 3 b+ which more up to the task).
As part of the set up I have 3G USB dongle that also supports voice calls using the chan_dongle plugin. This plugin also supports sending and receiving SMS messages (this is different from the MMS/SMS gateway I also run on a separate pi) and they are handled by the dial plan.
My first pass at the dial plan just publishes the incoming message to a MQTT topic and it is then processed by Node-RED, which emails a copy to me as well as logging it to a file.
[dongle-incoming]
exten => sms,1,Verbose(1,Incoming SMS from ${CALLERID(num)} ${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,AGI(/opt/asterisk/agi-mqtt/mqtt,/opt/asterisk/agi-mqtt/mqtt.cfg,foo/sms,${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,Hangup()
This works OK for incoming messages but sending them is a bit harder, as the only way to send them from outside the dialplan (from within the dialpan you can use DongleSendSMS) is to use the asterisk CLI tool which is a bit clunky.
What I was really looking for was a way to send/receive SMS messages like you do with a mobile phone. To make calls I normally use Linphone on my tablet and this includes support for SIP messaging. This lets you send messages between SIP clients and you can get Asterisk to consume these.
You can send SIP messages with the MessageSend asterisk dailplan function
The following is a basic echo bot:
[messaging]
exten => _.,1,Answer()
exten => _.,n,Verbose(1,Text ${MESSAGE(body)})
exten => _.,n,Verbose(1,Text from ${MESSAGE(from)})
exten => _.,n,Verbose(1,Text to ${MESSAGE(to)})
exten => _.,n,Set(FROM=${MESSAGE(from)})
exten => _.,n,Set(TO=${REPLACE(FROM,<'>,)})
exten => _.,n,MessageSend(pj${TO},${CUT(MESSAGE(to),:,2)})
exten => _.,n,Hangup()
Because I’m using the PJSIP module rather than the legacy SIP module I need to prefix the outbound address with pjsip: rather than sip:. This also matches any target extension which will be useful a little later.
To enable a specific context for SIP messages you need to add message_context to the PJSIP endpoint for the SIP user:
[tablet] type = endpoint context = internal message_context = messaging ...
Now if we put the 2 bits together we get a dialplan that looks like this:
[dongle-incomming]
exten => sms,1,Verbose(1,Incoming SMS from ${CALLERID(num)} ${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,AGI(/opt/asterisk/agi-mqtt/mqtt,/opt/asterisk/agi-mqtt/mqtt.cfg,foo/sms,${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,Set(MESSAGE(body))=${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,MessageSend(pjsip:nexus7,${CALLERID(num)})
exten => sms,n,Hangup()
[messaging]
exten => _.,1,Answer()
exten => _.,n,Verbose(1,Text ${MESSAGE(body)})
exten => _.,n,Verbose(1,Text from ${MESSAGE(from)})
exten => _.,n,Verbose(1,Text to ${MESSAGE(to)})
exten => _.,n,Set(FROM=${MESSAGE(from)})
exten => _.,n,Set(TO=${REPLACE(FROM,<'>,)})
exten => _.,n,DongleSendSMS(dongle0,${EXTEN},${MESSAGE(body)},1440,no)
exten => _.,n,Hangup()
The first part handles the incoming SMS messages delivered to the dongle and passed to the sms extension in the dongle-incomming context. This logs the message to the console and via MQTT then fires it off to my tablet as a SIP message. The second is the context for the incoming SIP messages from the tablet, this will accept messages to any extension, logs the message, who it’s to/from then sends it to the number in the extension via the dongle.
