Amazon done wrong

We sell on Amazon, and for that I'll apologise at the start, but it does provide some convenience to some customers and mostly works.

A few weeks ago we got an email saying we have to upload dome documents or they will close the account, and several ongoing reminders. Oh shit...

The problem is that the staff, including me, have a login to the seller account and can do 99% of things on it, as needed, but we could not do this as it had to be the main seller account. OK, so log in to that. Easy.

Except it wants to SMS a number to one of two numbers. Both were set up (and so worked at the time), but are 01344 (i.e. landline) numbers, and between when set up and now Amazon have obviously fucked up their SMS stuff and cannot SMS either.

The interworking of SMS really is a shit show and needs OFCOM to actually do its job and ensure it works properly.

But they also for calling them with a code - yay - except that also does not work - no clue why. Both numbers valid for SMS and calls, and they do neither.

So I tried the "remove 2FA" and sent pictures of passport, or something. My accounts manager did the same several times. No joy.

Every single chat was just crazy, and got to being daily. I mean I am tempted to publish them - they are so mad. One of them insisted I wait 24 hours after trying before contacting them - I said I had done that - he asked why I did not contact them after waiting 24 hours - and I explained I did - this is me contacting them!! The chats were like that. I don't like to judge people as "stupid", honest, people are only sensible in the areas they know, and that applies to all of us. But really, these chats were "special".

Just to be clear - the only reason I could "chat" at all is I had a working amazon account from which to chat. If not I would be screwed.

I have my case handled and referred to these, all of which did not reply at all!

• Internal escalation team
• Account recovery team
• External escalation team

I finally got someone that insisted that another "remove 2FA" should work, and I tried it, and, well, it did. But the instructions were clear - once done I could log in with just a password.

This was a lie. I logged in, and it said "Enter verification code. For your security, we've sent the code to your phone ***-***-**23" which basically means 2FA, so not removed, but also a number I don't know. Not either of the two numbers before.

Many more chats. No way to progress this. Doing the "remove 2FA" again stalled as it needs the code sent to *23 to get as far as uploading a driving licence even. I kept on, emailed in again, and finally it changed.

Now I have option for OTP by email or by SMS to *23, yay, but then it again does "Enter verification code. For your security, we've sent the code to your phone ***-***-**23" as well. So email and SMS now! (yes, when I got SMS working it wanted email too, so yes, both now needed!).

Had there not been an actual mobile *23 I really think we would be screwed. They have zero way to sort this from what I can see. Removing 2FA is "still do 2FA using a *main* mobile number" which you cannot change until you log in!

Turns out, after some research, checking staff lists, and pestering someone on leave and at a party (really, thank you Mike), I found someone that had a number ending in 23, and they were indeed what was on Amazon. So they let me know the code. Yes, that is being fixed, they should not have been on the main login, really. History from when first set up.

So finally I am in - it took a couple of attempts, but now the 2FA is sorted.

Phew.

So back to step 1. What is it they need.

Well this...

Yep, it is a sort of Farage test I think!

Obviously I click Agree and submit.

And, well, predictable...

So, err...

So another chat, and really, I am at a loss on this chat...

Ok, long winded, but basically no clue why this was an issue "not understandable" somehow, and actually, no, there is no way to upload a screenshot.

Eventually got an email and replied with a screenshot. It is a "don't reply to this" email address, FFS.

Tech: Managing calls

I have just issued a new alpha release of FireBrick, by popular demand, allowing some call filtering based on CLI. Basically you can do a lot more than simple anonymous call reject now. Whilst most people know the FireBrick as a firewall/router it is also a SIP VoIP PABX (phone system).

But one of the things that this highlights is the increasing need to "do something" with calls you receive. Systems like the FireBrick allow you to do all sorts on your own network, making your own "phone system" for VoIP phones. If you look at systems like asterisk the level of controls you have are quite incredible - essentially a programming language for how calls are handled and even allowing recoded messages and DTMF menus and so on.

On a private system you also have means to log things and even manage call recordings yourself.

This is all great for a "desk phone" but what about your mobile?

This is where some of the stuff we sell comes in - and we have customers doing some clever stuff. Recently we have managed to make a few improvements, but basically we have means to have a normal 07 UK mobile number, and a mobile SIM, and put your own phone system (whether FireBrick, or asterisk, or anything else) in the middle.

This means you can have a mobile phone with a SIM card, and do things like log, or filter, or record calls, and texts, either way. The SIP2SIM service looks like a VoIP handset has registered and connected to your phone system, but is in fact a normal Mobile telephone service (i.e. no special app on the phone). This means you can even make internal calls on your phone system from your mobile. (The mobile leg does have call costs even for these).

The texts can be passed by email or using http/https on your own server where you can do things with them. The latest improvements mean much better handling of unicode characters as well. You can also handle the texts from the mobile. You could just join the dots to make texts or calls, in and out, like a normal mobile, or you could do much more with your own scripts on the way.

We have people doing things like opening doors using calls, and clever tricks with texts.

Obviously we also have services that simply link calls, or texts, or both, in and out between an 07 mobile number and the SIP2SIM service without needing your own phone system. We have options like call recording and logging. But we are happy for you to make your own systems, as simple or as complex, as you wish in the middle.

Of course this also allows mobile on a normal landline style number, but texting to such numbers remains a challenge in the UK, and a lot of companies and web sites will refuse to even try texting what they think is a landline number. So using a normal 07 mobile number does the trick nicely.

We can even port in an 07 mobile number to the service, and if you don't like it, port back out again. No minimum term on the SIP2SIM or VoIP services.

So if you are techie, but want a lot more control of your mobile phone service, it is worth taking a look.

One little trick I do a lot is steal a call, transferring it between my mobile and my desk phone mid call, without the other party even realising I have done it. E.g. answer on mobile, walk to desk, put on headset, switch call to desk phone and work on computer while on the call. All seamless.

💩

 I have been involved with SMS (i.e. text messaging) for a long time. I was even on the ETSI committees that designed GSM (not specifically SMS, sadly), and have been doing things with SMS for nearly 30 years in one way or another, including an SMS->fax/email gateway, and even the ETSI landline SMS module for asterisk. Now, at A&A, we have code to send and receive SMS via a variety of carriers and even a SIP a-law based ETSI landline SMS system.

The specification for SMS is a typical telecoms specification - very different to internet specifications where single bits packed in some small data header can subtly change the interpretation of some or all that follows. These specifications are normally very precise but absolutely horrid, in my view.

But where does the pile of poo come in, and how does it relate to a 30 year old specification for SMS? Well, you may be surprised, but SMS allows for 💩.

SMS are actually coded in the signalling used for calls, and so had limited space. There were actually only 140 bytes (or more correctly octets) of data for the text itself. As you may know SMS allow 160 characters, so this is achieved by packing a 7 bit alphabet in to the 140 bytes.

In fact SMS allows 4 ways the data can be coded, a 7 bit special alphabet, an 8 bit Latin-1 alphabet, and 16 bit unicode (allowing 70 characters). There are also ways to send one longer message in smaller parts. The SMS can also be raw data to be sent to a SIM rather than displayed. Had I written this I'd have used 2 bits to say which it is, but no, the specification uses a Data Coding Scheme which is complicated to say the least. Some times the coding is in 2 bits but others it is implied. It is not fun.

The 7 bit alphabet is sort of ASCII, but does allow some interesting characters - being a European spec it includes some accented characters and even some Greek letters.

Of course this also leaves out some key ASCII such as {, }, [ ], and does not even have € (which was added later). These are coded as two character sequences using ESC.

The 8 bit character set is just normal Latin 1, and the 16 bit is unicode. The unicode allows all unicode characters U+0000 to U+FFFF, but where is pile of poo? It is U+1F4A9 which is too big for 16 bits.

The way this is done is to use a little known trick called UTF-16. There are reserved 16 bit unicode characters U+D800 to U+DFFF. Using two such codes it is possible to encode U+10000 to U+10FFFF.

This means 💩 is actually coded as two 16 bit sequences, 0xD83D 0xDCA9 in SMS!

Why does this matter, I mean, who sends 💩 by SMS? As you can imagine, in the early 90's nobody had heard of 💩, and the best emojis we had were :-)

But we do care, honest, as we use it as a blue* M&M test for carriers we deal with. If they have enough attention to detail to handle a pile of poo they probably have the rest sewn up, technically. We are working with a new carrier for SMS messages, and I am pleased to say the unicode is working. They properly translate to/from UTF-8 coding in the messages we exchange (which is what we use internally). Unlike our previous carrier who could not cope. (* see comments)

We have seen a range of such failures, even the case where one carrier could not handle an @ symbol (presumably as it coded to 0x00 which is an end of string in languages like C). Thankfully that carrier was happy for us to send a raw hex TPDU for SMS, and hence allowing us to code any characters. Our SIP2SIM service has handled pile of poo since we launched it...

The end result is that, shortly, we will be handling a lot more SMS with unicode characters correctly, in most cases, both incoming and outgoing. Watch this space.