Simwood Status
All Systems Operational
Voice   ? Operational
90 days ago
100.0 % uptime
Today
API and Portal   ? Operational
90 days ago
100.0 % uptime
Today
Availability Zones Operational
90 days ago
100.0 % uptime
Today
London   ? Operational
90 days ago
100.0 % uptime
Today
Slough   ? Operational
90 days ago
100.0 % uptime
Today
Manchester   ? Operational
90 days ago
100.0 % uptime
Today
Availability Zones (US) Operational
90 days ago
100.0 % uptime
Today
San Jose (US West)   Operational
90 days ago
100.0 % uptime
Today
New York (US East)   Operational
90 days ago
100.0 % uptime
Today
Operations Desk   ? Operational
90 days ago
100.0 % uptime
Today
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Scheduled Maintenance
CLI and General Condition 6 Oct 10, 00:00 - Oct 11, 00:00 UTC
With effect from Wednesday 10th October we will be implementing the first phase of CLI changes for compliance with the revised General Condition 6 as previously announced.

It is imperative to ensure you are sending valid Caller ID on all calls as outbound calls that do not have any valid Caller ID will not complete after this date.

To minimise impact of these changes we’ve implemented this in a manner that the vast majority of customers will be unaffected, and we will manipulate the CLI to meet the requirements behind the scenes even where only one CLI is present.

For more information please see http://blog.simwood.com/2018/10/gc6-cli-update/
Posted on Oct 8, 14:27 UTC
Past Incidents
Oct 23, 2018

No incidents reported today.

Oct 22, 2018
Resolved - This incident has been resolved.
Oct 22, 20:27 UTC
Monitoring - We are aware of an issue where a very small number of incoming calls may have been transmitted with incorrectly formatted, missing, or invalid CLI.

We believe this has now been resolved but are monitoring the affected interconnect closely.
Oct 22, 17:16 UTC
Oct 21, 2018

No incidents reported.

Oct 20, 2018

No incidents reported.

Oct 19, 2018

No incidents reported.

Oct 18, 2018

No incidents reported.

Oct 17, 2018

No incidents reported.

Oct 16, 2018

No incidents reported.

Oct 15, 2018

No incidents reported.

Oct 14, 2018

No incidents reported.

Oct 13, 2018

No incidents reported.

Oct 12, 2018
Resolved - We are confident that this issue is both very isolated, and entirely outwith the Simwood network, but we do ask that you report any occurrences of it by raising a ticket and we will raise it with the terminating provider as appropriate.

More information can also be found here https://support.simwood.com/hc/en-us/articles/360010440313-08979-Numbering
Oct 12, 08:00 UTC
Update - Further to this, and a few queries we've received, it should be stressed that this is very unlikely - we do just ask that you report any instances of it. So far we've received a handful of reports and they've all been to 'unusual' destinations (i.e. not the major PSTN operators or MNOs, which all work as expected)

We are following the industry-agreed guidelines regarding the changes to Caller ID in General Condition 6 that have been developed over the last six months and fully support Ofcom's approach (you can read more about the underlying reason behind this here http://blog.simwood.com/2018/04/restoring-confidence-in-cli/)

Where an 08979 number is displayed incorrectly this is not as a result of your, or our, configuration but rather incorrectly configured equipment at the destination network and not a 'fault' with Simwood or your equipment.

Of course, we do still encourage proper use of the P-Asserted-Identity header to set your own Network Number where possible, rather than relying on us setting a default. Therefore in the unlikely event it is 'leaked' to the called party, it's still a number that they can call back.
Oct 11, 15:09 UTC
Identified - We have received sporadic reports, following our changes to enable compliance with the revised GC6, that some calls are arriving presenting a telephone number starting 08979 when a number that is not on your Simwood account is used as the CLI.

These 08979 numbers are assigned by Ofcom and intended to be used internally by Communications Providers to facilitate tracing calls. More details can be found here; http://blog.simwood.com/2018/09/mandatory-cli-changes/

They should never be presented to the called party as appears to be happening in isolated cases, and it's likely that the underlying issue is outwith the Simwood network where this is happening.

If you do receive any reports of 08979 numbers being presented on outbound calls, please raise a ticket with our support desk providing examples of calls this happened on (e.g. the date/time, caller ID you presented, and the dialled number)

We strongly recommend all customers use P-Asserted-Identity, and set this to a number that is on your Simwood account for all calls. You can set a different presentation number (e.g. where forwarding calls) by using the From header.

In cases where a valid Network Number / PAI has been set, then in these edge cases the customer will see this number rather than the 08979 which is a better experience (we only resort to using the 08979 if no other number is present)

You may also wish to consider using the Default Network Number option in the Trunk configuration to set a preferred Network Number.

We're confident this is affecting a very small number of calls, but are investigating this and will liaise with any terminating carriers that appear to be displaying the number incorrectly. In each case we are sending both the Presentation Number and Network Number, and they are electing to display the "wrong" one.
Oct 11, 13:25 UTC
Oct 10, 2018
Resolved - Whilst we encourage all customers to use the recognised standard, P-Asserted-Identity, for sending Caller ID information on calls where possible this issue is now resolved, and customers sending valid CLI data in Remote-Party-ID headers will find calls complete as expected.

Please accept our apologies for any inconvenience this caused.
Oct 10, 15:43 UTC
Identified - We are aware that some customers using the Remote-Party-ID header to send CLI - especially where this is not in E.164 format - may be experiencing issues with outbound calls where there is no valid presentation number in the From header following changes this morning.

We're working to resolve this however if you're in a position to adjust your platform to send P-Asserted-Identity (RFC 3325) instead this will resolve it, alternatively if your trunk has a default_cli set this will be used.

Otherwise, please raise a ticket with our Support Team via https://support.simwood.com/ or by eMail to team@simwood.com and we can disable this filtering on your account whilst we investigate.

It's worth noting that Remote-Party-Id was defined in a failed RFC draft eighteen years ago (http://tools.ietf.org/html/draft-ietf-sip-privacy-00) and replaced in 2002 by RFC 3325 (https://www.ietf.org/rfc/rfc3325.txt)

We've recommended use of RFC 3325 P-Asserted-Identity for some time, however historically have continued to support the legacy Remote-Party-Id header, and are endeavouring to have a fix in place for this shortly.
Oct 10, 10:36 UTC
Oct 9, 2018

No incidents reported.