License: CC-BY-NonComercial

Being in Girona for a few days this was my second time, and last opportunity, to get to get the image. The previous time the image just didn’t quite have the right light.

This day we had been outside town during the day and I had planned to return in the evening to get this photo, but the travel took longer and I was late..

.. rushing to setup I quickly get the frame right (had decided that last time) and wanted to take a trail shot. To my horror there were a huge dust spec on the photo, the light is fading (well it is too dark to actually do much camera cleaning) and time is getting short. What to do? Well, I have up .. walked back to the hotel to clean the camera.

This image is the test shot (I removed the dust) and the best image I got from Onya river. I’m really pleased with the picture, but I should have continued to shoot and accept the flaw. A dusty picture is better than none.

–
Image used:
- portlandvelospain2013.com

But I guess when things are too good to be true then that is exactly what they are – too good to be true. I found that files were corrupted on copy. At first I thought I was wrong – the date and file size was all right, but the files could not be read. This happened on large files and  by far not for all files.

I contacted Jumping Bytes and they are not understanding why it can happen as they use a standard file copy API in Windows. Now I truly believe them and can feel their frustration they must feel, but lots of my files were corrupted. TotalCommander (good old friend) helped me fix this by using binary compare – I almost could have copied them all again.

Before contacting Jumping Bytes I did a test to verify the size of the problem and here is what I wrote them:

I copied the same 61 files to the local disk (c:\temp\) and this time
I get 11 errors (Explore and Binary compare agree). On local disk I
then did a “Synchronize Selected files” to Folder 2 of the 11 failing
and this time the binary compare gives me 5 failing. This time I do
the same with the 5 and I get 2 failing. Next time 1

Today it is 3 weeks since I contacted Jumping Bytes and there is no update on the issue. I’ve deinstalled PureSync and I guess I’ll be a bit more careful about what I use next time.

I don’t know what it has to do with net neutrality, but what made me stop was a picture we took in New York when we were there in 2008. Sure it is NY and anyone can post a picture which TC can used, so it is maybe not really that unlikely, but I still find if funny that they happened to use the same motive.

Not the same angle, but if this is not the same sign I’ll be more than amazed.

PBXes has done it and there is talk that Asterisk 1.8 will do it

I’ve not tried any of them, but it sure sounds good ….

Some of you might already know it, but I use to have a Windows 3.1 program and a Win32 library for sending SMS messages from a Windows machine to a GSM cell phone, using gateways provided by the different telecoms.

Due to many factors, I’m not able to keep the work on these programs up to date, and due to the use of (customized) AsyncPro components, I can not make (the full) source public. Instead of providing source, I will try to describe the very simple process of building and sending the messages.

UCP / ERMES / ETS 300 133-3

The protocol used for sending messages via a dial-up link is actually a subset of the ETSI specification ETC 300 133-3[1][2]. This specification covers a protocol that is (was?) a part of the ERMES pager network. In the specifications there is a sub section covering a so-called Universal Computer Protocol (UCP), which is what actually is used for this simple communication.

The protocol is basically a very simple ACK/NAK protocol, where the initiator (you) sends a message and receive a response informing you the request was accepted or not. The initiator does not have to be the one actually dialing up to the service center (or gateway), but in this type of applications this is usually the case.

At this point, you will need to establish a modem (or ISDN) connection to a service center using 8 data bits, No parity and 1 stop bit (8N1). How to do that is outside the scope of this document.

The messages in UCP have the great advantage almost only to consist of readable characters, which make debugging significant easier. There are two control (non readable) characters – the STX (Start of TeXt or 2 hex) and ETX (End of TeXt or 3 hex) characters – which are used to frame each message. When creating a message, each field inside the message is separated with the separator character, the forward slash '/'.

When building messages, all messages will have the following blocks:

 STX   HEADER   MESSAGE   CHECKSUM   ETX 

Header

The header consist of the following fields:

 TRN   LEN   O/R   OT 

o  TRN - Transaction Number

The transaction number is a unique id generated by the sender. The value must be in the range of 0 to 99. It should be transmitted as two ascii character (e.g. '20').

o  LEN - Length

The length is the total length, in octets (characters), between STX and ETX. This is including the header, the separators and the checksum field (but not including the STX and ETX characters). It should be transmitted as five ascii characters, prepended with zeros as needed (e.g. '00036').

o  O/R - Operation / Result

This is an indication to mark the message as an operation (e.g. a new message being send) or as a Result (e.g. the answer – ACK or NAK – from the other side, telling if the message was accepted or not). It should be transmitted as the single ascii character 'O' or 'R' (upper case).

o  OT - Operation Type

As in any other protocol, UCP can have multiple message formats (or message types). It should be transmitted as two ascii characters (e.g. '30').

Checksum

The checksum is the 8 LSB (least significant bits) of a simple addition of all octets (note that a message type '30' is two octets with the values 33 hex and 30 hex) following the STX character and until the checksum field. Note that all separators will be included in the checksum, but the STX, checksum and the ETX will not be included.

Example

Before we continue to the message format, let’s look at a simple request for sending the message ‘Hello World’ from ’87654321′ to ’12345678′.

 [02]01/00064/O/30/12345678/87654321////////48656C6C6F20576F726C64/C2[03]

We can see from this message, that the transaction number is 01 (I have avoided to use zero, but it’s not said that zero is illegal). Further we can see that the message is 64 octets long – this is excluding STX ([02]) and ETX ([03]) – it’s an operation and the message type is '30'. Finally we see that the checksum have been calculated to be C2 hex or 194.

Before we continue

As always every implementation should be prepared to send certain standard error messages. For me this proved it’s value when the German mobile phone provider Mannesmann (now Arcor) changed their implementation from “rev. 1″ to “rev. 2″. Since I responded in the expected fashion with an error message saying that I didn’t recognize the message, they would fall back to “rev. 1″ type messages.

Acknowledgements

An acknowledgement, positive or negative, does always contain the same operation type (OT) and transaction number (TRN) as the message which it’s responding to. The operation type (O/R) is always set to 'R' (for response).

For negative acknowledgements the format is almost always the same. In some cases of “rev. 2″ messages, the format is, like the positive acknowledgements, dependant on the incoming message, but the “standard” error message is always the same.

 NAC   EC   SM 

o  NAC - Not acknowledged (Mandatory)

Always the 'N' character

o  EC - Error Code (Mandatory)

This is an error code, transmitted as two ascii characters. The one saving me was '03' – Operation not supported. Two other very interesting ones: '01' – Checksum error and '02' – Syntax error. The rest can be found in the ETSI standard.[1][2]

o  SM - System Message (Optional)

A system message containing alphanumeric letters, encoded as IA5 (see later) characters.[3]

If we look at the following example below we see that it’s a response to the transaction '01', it’s negative and the error code is '03', which is ‘Operation not supported’, and the message have been truncated for display purpose.

 [02]01/00098/R/30/N/03/534D53657276 ... 74797065/0B[03]

Message Transfer Operation (30)

When you want to send a message, you should use the message type '30' called “SMS Message Transfer Operation”.

 AdC   OAdC   AC   NRq   NAd   NPID   DD   DDT   VP   AMsg 

o  AdC - Address Code, Recipient (Mandatory)

This is the phone number of the receiver. Normally this would be the number as you dial it on the phone (note that the number is as the gateway expect to see the number). As an example I can mention the number of a German mobile phone, reached via a Danish gateway. Here you must display the number as ’00491724504232′. Note that ’00′ is the international access code from Denmark. ’49′ is the Germany international code. ’172′ is the “area code” (excluding the leading zero) for the German network, and ’4504232′ is the phone number. If you want to use a French gateway you should most likely use ’019′ as the international access code from France! Usually you can leave the international stuff away if you want to reach a phone local to the gateway (use ’01724504232′ if you want to reach the above phone via a German gateway). Note that this number scheme is use all places where we referee to a phone number or address.

Only numeric “characters” are allowed – to ‘+’ is also not allowed!

o  OAdC - Originator Address Code, Sender. (Optional)

This is the phone number of the sender. My experience shows that the providers treat this field transparently, and the number is used on the mobile phone to display the sender (a random code could be used!).

Only numeric “characters”.

o  AC - Authentication Code (Optional)

Leave empty.

Characters.

o  NRq - Notification Request (Optional).

Empty or ascii '1'. If set to one, the gateway will respond with a notification message, containing a response, from the system, to the request. This message is usually a text string in the language used in the country where they gateway is present. There will be no numeric codes to translate into “local” languages.

o  NAd - Notification Address (Optional)

Leave empty – honestly this is most likely some kind of address where it can reach you with the notification (which you just requested in the previous field), but I have always kept it empty.

Only numeric “characters”.

o  NPID - Notification PID value (Optional)

This should be a value (only numeric characters) that identifies the notification, but unfortunately we don’t get it back with the notification so just leave it empty.

o  DD - Deferred Delivery (Optional)

Empty or ascii '1'. If set to '1' the message will not be delivered right away, but deferred until later (see next field).

o  DDT - Deferred Delivery Time (Optional)

This is the time at which the message should be delivered. The format is 10 ascii numbers in the format YYMMDDhhmm. It can also be left empty.

o  VP - Validity Period (Optional)

This is the time at which the message will expire. Formatted as the Deferred Delivery Time.

o  AMsg - A Message (optional)

Finally the message encoded as IA5 (see later) characters[3].

So this was the message transfer format – let’s look at the previous example:

 [02]01/00064/O/30/12345678/87654321////////48656C6C6F20576F726C64/C2[03]

We already know that '01/00064/O/30/' is the header and '/C2' is the checksum. ’12345678′ is then the address of the recipient, ’87654321′ the address of the originator and ’48656C6C6F20576F726C64′ the message in IA5 format.

So when we now transmit the above message to the gateway, we must way for the gateway to answer with an acknowledgement – positive or negative. The negative format we already know and in this case the positive acknowledgement have the following format.

 ACK   MVP   SM 

o  ACK - Acknowledged (Mandatory)

The ACK field is the letter 'A'.

o  MVP - Modified Validity Period (Optional)

This is time at which the gateway will expire the message, if it’s not delivered before that. The format is the same as the DDT in the Message transfer.

o  SM - System Message

A system message containing alphanumeric letters, encoded as IA5 (see later) characters[3].

This is (almost) enough to send a SMS message, and to know if the message was accepted for delivery of if it was rejected by the gateway. The state machine used for sending, retransmitting etc. is left as an exercise.

Did that person actually receive the message? Often we would like to know a little more about the delivery, so we often use the Notification Request (NRq) in the message transfer. If we set the NRq flag, and the modem/ISDN/serial connection is still available, the gateway will respond with a call input operation.

Call Input Operation (01)

When you receive the call input operation, the message will have the message type ’01′ and the following format.

 AdC   OAdC   AC   MT

o  AdC - Address Code, recipient (Mandatory)

You know, just like on the message transfer.

o  OAdC - Address Code, originator (Optional)

You know, just like on the message transfer (actually the sender of the SMS message and not the sender of the system message).

o  AC - Authentication Code, originator (optional)

Leave empty, just like in the message transfer.

o  MT - Message Type (Mandatory)

The message type following this message header:

- '2' mean a numeric message. (NMsg)

- '3' a string (AMsg)

- '4' a “transparent data message” (NB/TMsg) (never used this)

NMsg is a sequence of numbers.

AMsg is a sequence of alphanumeric letters, encoded as IA5[3].

Let’s look at an alphanumeric example.

 [02]00/00256/O/01/12345678/00491724504232//3/
 4D65737361676520666F722030303439313732343530343233322C2077697468206964
 656E74696669636174696F6E2039393130313232333231333020686173206265656E20
 64656C697665726564206F6E20313939392D31302D31322061742032333A32313A3335
 2E/72[03]

The header is '[02]00/00256/O/01/' and the checksum is '/72[03]'. The recipient is ’12345678′, the originator is ’00491724504232′, there is no authentication and the message type is '3'. The message itself is an IA5 encoded string.

If the operation isn’t acknowledged, positive or negative, most systems will try for quite a while to retransmit the message, therefore always remember to acknowledge all messages – and the ones you don’t know should be acknowledged negatively with ‘Operation not supported’.

Positive acknowledgement is done with a very simple message

 ACK   SM

o  ACK - Acknowledge (Mandatory)

The letter ‘A’ to acknowledge the message.

o  SM - System Message (Optional)

A system message encoded as an IA5 string[3].

IA5

You have seen this multiple times now, the IA5 encoding of strings. IA5 is defined by ETS 300 133-2[3] appendix B2. It’s a seven bit encoding of letters roughly matching the one of ascii characters. The lower 32 characters in the in the IA5 table is used for country specific characters (and don’t expect all countries to use the same tables!!!). Let’s just make it simple and say that ’0′ to ’9′, ‘A’ to ‘Z’ and ‘a’ to ‘z’ are placed identically to where the ascii characters are placed. This result in ’0′ being equal to ’30 hex’, ‘A’ being equal to ’41 hex’ and finally ‘a’ being equal to ’61 hex’.

When encoding these characters in IA5, the 3 MSB is taken and displayed as an ascii value. For ’0′ the 3 MSB of the 7 bit value is ’3′. This rest, the 4 LSB, is ’0′. This gives the output ’30′ in ascii characters.

If we look at the message type '30' we were sending above, the message string was '48656C6C6F20576F726C64'. Let’s decode that one.

The first two characters is ’4′ and ’8′. This gives the hex value ’48′. If ‘A’ is ’41′, ’48′ will be the eights letter … ‘H’. The next to characters is ’65′, which turn out to be fifth lower case letter ‘e’. The complete string can be decoded in this fashion, and much to our surprise the string becomes ‘Hello World’.

Anything else?

This is enough for being able to create, transmit and receive SMS messages via a service center gateway. There are more message types, with more functions declared in both revision one and two. You should especially notice that revision two depend on detecting revision implementations by expecting the implementation to answer with the standard “Operation not supported” NAK message.

Another protocol, called the “Telocator Alphanumeric Protocol”[4], covers basically the same functionality. A large difference between the UCP approach and the TAP approach is the more “protocol like” functionality of UCP and the ability of TAP to run as terminal as well as automatic transfer protocol.

Finally

I hope that this will aid in creating applications using SMS as a media. I created the first program as an exercise for myself as well as to fill a hole. Today the hole seems mostly in aiding developers in using the functionality in automated systems, and not so much in human communication. Good luck.

–

http://pda.etsi.org/pda/home.asp?wki_id=352

http://pda.etsi.org/pda/home.asp?wki_id=2961

http://pda.etsi.org/pda/home.asp?wki_id=348

http://www.pcia.com/WirelessCenter/protocol/tapv1p8/openviro.htm

In the danish newspapers there is right now an article where the stupid (sorry, but I hate that suffix) .nu domain is the official website from the danish government and not the more obvious .dk  domain.

So what is the big deal about you might ask! There are great many things where this is not really a big deal, but NemID is a central key server and login system for all communication with the government. You do your taxes this way, you can change your name this way and it is (or is going to be) the signature system the banks must use for your online banking!

I’m sure that there is a lot of really good people who has been working to make NemID as good and secure as possible and I do not blame them for not doing a good job solving the given task. While NemID does have other small issues I do believe that they have tried to hit a good middle ground between usability and security (disclaimer: I have not been evaluating the system as a whole so my opinion is based on generally available information).

What I find important is that the government assume that we trust their websites, but does not give way to know it is their page. I wish they would wake up

You will need a SIP account to which you have connected your home number … at this point I just assume that you have that.

Getting a US phone number is quite easy, if you do not care about the area code. You can go to phone.ipkall.com where you can get a number and get it forwarded to your existing SIP account (the only issue is that you must use it once month or you will loose it).

To get Google Voice you need an US IP address. One way to get that is to use the Hotspot Shield service to get a “protected” connection before you sign up for Google Voice. After signing up you do not any longer need the US IP address, so you can safely disconnect the Hotspod Shield “protected” connection”.

In Google Voice you now pick the area code of your choice and set it to always call the number you were assigned by IPKALL.

There you go. A US number terminated in your local SIP phone and with a Google Voice interface.