subscription API sometimes works and sometime is an unknown resource - Can't predicte which response I will get.
Any ideas how this can happen?
* Connection #0 to host tapi.telstra.com left intact
* Trying 13.210.2.39:443...
* Connected to tapi.telstra.com (13.210.2.39) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: C:\Program Files\PHP\curl-ca-bundle.crt
* CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=AU; ST=Victoria; L=Melbourne; O=Telstra Corporation Limited; CN=tapi.telstra.com
* start date: Jul 29 02:29:03 2021 GMT
* expire date: Aug 26 00:00:00 2022 GMT
* subjectAltName: host "tapi.telstra.com" matched cert's "tapi.telstra.com"
* issuer: C=BM; O=QuoVadis Limited; CN=QuoVadis Global SSL ICA G3
* SSL certificate verify ok.
> GET /v2/messages/provisioning/subscriptions HTTP/1.1
Host: tapi.telstra.com
Accept: */*
Content-Type: application/json
Authorization: Bearer xxxx
Content-Length: 0
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 06 Jan 2022 22:43:55 GMT
< Content-Type: application/json
< Content-Length: 114
< Connection: keep-alive
< Server: nginx
< Strict-Transport-Security: max-age=15768000; includeSubDomains
<
* Connection #0 to host tapi.telstra.com left intact
Same code, other times I get this:
* Connection #0 to host tapi.telstra.com left intact
* Trying 13.210.2.111:443...
* Connected to tapi.telstra.com (13.210.2.111) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: C:\Program Files\PHP\curl-ca-bundle.crt
* CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=AU; ST=Victoria; L=Melbourne; O=Telstra Corporation Limited; CN=tapi.telstra.com
* start date: Jul 29 02:29:03 2021 GMT
* expire date: Aug 26 00:00:00 2022 GMT
* subjectAltName: host "tapi.telstra.com" matched cert's "tapi.telstra.com"
* issuer: C=BM; O=QuoVadis Limited; CN=QuoVadis Global SSL ICA G3
* SSL certificate verify ok.
> GET /v2/messages/provisioning/subscriptions HTTP/1.1
Host: tapi.telstra.com
Accept: */*
Content-Type: application/json
Authorization: Bearer xxxx
Content-Length: 0
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Date: Thu, 06 Jan 2022 22:28:58 GMT
< Content-Type: application/json
< Content-Length: 156
< Connection: keep-alive
< Server: nginx
< Strict-Transport-Security: max-age=15768000; includeSubDomains
<
* Connection #0 to host tapi.telstra.com left intact
array(3) {
["status"]=>
string(3) "404"
["code"]=>
string(18) "RESOURCE-NOT-FOUND"
["message"]=>
string(62) "Invalid resource. Refer to API docs at https://dev.telstra.com"
}
Hi Mark,
I see from the timestamp that your initial GET subscription returned 404 error and subsequent call was successful.
Usually if you get a 404 while doing GET subscription, it indicate that you do not have active subscription or your subscription has expired. You can perform POST create subscription and try performing GET subscription again, For details please visit, https://dev.telstra.com/content/messaging-api#operation/createSubscription
Same code run 3 times with different results for what gets 404 error each time
CURL POST URL: 'https://tapi.telstra.com/v2/oauth/token'
CURL values: 'grant_type=client_credentials&scope=NSMS&client_id=kmYwIYEEKArp4V7IU0m7Vpj2cl2mTI9G&client_secret=sILe7T36OLSmFLKa'
CURL resp: '{"access_token":"4hDMKhzq9ppiPY0w0wSRxznPcnG1","token_type":"Bearer","expires_in":"3599"}'
CURL GET URL: 'https://tapi.telstra.com/v2/messages/provisioning/subscriptions'
CURL resp: ' { "status":"404", "code":"RESOURCE-NOT-FOUND", "message":"Invalid resource. Refer to API docs at https://dev.telstra.com" } ' array(3) { ["status"]=> string(3) "404" ["code"]=> string(18) "RESOURCE-NOT-FOUND" ["message"]=> string(62) "Invalid resource. Refer to API docs at https://dev.telstra.com" }
CURL POST URL: 'https://tapi.telstra.com/v2/oauth/token'
CURL values: 'grant_type=client_credentials&scope=NSMS&client_id=kmYwIYEEKArp4V7IU0m7Vpj2cl2mTI9G&client_secret=sILe7T36OLSmFLKa'
CURL resp: '{"access_token":"CpPB8dj1aVkdGRdUe5pcMARTLeSc","token_type":"Bearer","expires_in":"3599"}'
CURL POST URL: 'https://tapi.telstra.com/v2/messages/sms' CURL values: '{"to":["0428866728"],"body":"test TSMS via dev TelstraMsg","validity":1440,"replyRequest":false,"userMsgRef":"ACpNM1IQ.jyj_HeWNWedpg"}'
CURL resp: '{"messages":[{"to":"+61428866728","deliveryStatus":"MessageWaiting","messageId":"5AA9091B706FEC6188E0000007005F07","messageStatusURL":"https://tapi.telstra.com/v2/messages/sms/5AA9091B706FEC6188E0000007005F07/status"}],"messageType":"SMS","numberSegments":1,"country":[{"AUS":1}]}'
the 3 runs above got truncated - i'll post a brief example of just the subscription.
You can see the subscription must be valid since it sent a message after the 404 error gettng the subscription.
CURL GET URL: 'https://tapi.telstra.com/v2/messages/provisioning/subscriptions'
CURL resp: ' { "status":"404", "code":"RESOURCE-NOT-FOUND", "message":"Invalid resource. Refer to API docs at https://dev.telstra.com" } ' array(3) { ["status"]=> string(3) "404" ["code"]=> string(18) "RESOURCE-NOT-FOUND" ["message"]=> string(62) "Invalid resource. Refer to API docs at https://dev.telstra.com" }
CURL GET URL: 'https://tapi.telstra.com/v2/messages/provisioning/subscriptions'
CURL resp: '{"destinationAddress":"+61472880165","activeDays":"26","notifyURL":"https://tsmsdev.tursa.com.au/api/telstrasms/"}'
CURL GET URL: 'https://tapi.telstra.com/v2/messages/provisioning/subscriptions'
CURL resp: ' { "status":"404", "code":"RESOURCE-NOT-FOUND", "message":"Invalid resource. Refer to API docs at https://dev.telstra.com" } ' array(3) { ["status"]=> string(3) "404" ["code"]=> string(18) "RESOURCE-NOT-FOUND" ["message"]=> string(62) "Invalid resource. Refer to API docs at https://dev.telstra.com" }
Same behaviour seen on all APIs except for the AUTH endpoint to get token, it is working 100% of the time.
Is it going through a load balancer and one of the target servers isn't working and one is?
CURL values: '{"to":["042xxxxx28"],"body":"test TSMS via dev TelstraMsg","validity":1440,"replyRequest":false,"userMsgRef":"hwSKYo8gXvfzaiFy_CxpIA"}'
CURL resp: ' { "status":"404", "code":"RESOURCE-NOT-FOUND", "message":"Invalid resource. Refer to API docs at https://dev.telstra.com" } '
CURL values: '{"to":["042xxxxx28"],"body":"test TSMS via dev TelstraMsg","validity":1440,"replyRequest":false,"userMsgRef":"ACpNM1IQ.jyj_HeWNWedpg"}'
CURL resp: '{"messages":[{"to":"+6142xxxxx28","deliveryStatus":"MessageWaiting","messageId":"5AA9091B706FEC6188E000000xxxxx","messageStatusURL":"https://tapi.telstra.com/v2/messages/sms/5AA9091B706FEC6188E000000xxxxx/status"}],"messageType":"SMS","numberSegments":1,"country":[{"AUS":1}]}'
Rerunning the same code gets different results, seemingly at random.
This is part of the same sequnce from previous post showing subscription endpoint working/not working on different runs.
There is no correleation between when any enspoint works or fails and the next API call working or failing. They might all fail, or all work, or any combination for working/failing.
I am also getting 404 randomly Mark. Will check both send SMS and GET Subscription with engineering team.
Regards
Vinodh
Hi Mark,
There was a out-of-sync issue in our backend servers causing intermittent 404 errors to many customer. We had investigated this and fixed this issue on 10th Jan before midnight. From 11th Jan onwards, the system is stable, could you please check and let me know if you need any more support.
Regards
Vinodh
Hi Mark,
I am able to reproduce the problem. This is a bug. Will raise an issue with our engineering team to look into this straight away.
Regards
Vinodh
I am also experiencing similar issue, however mine may have a more severe impact upon my services.
A phone number provisioned and used successfully to receive a message yesterday no longer works today.
When I send a "Retrieve messages" request, the response is "EMPTY".
When I send a "Get Subscribption" request, the response is:
"status": "404",
"code": "RESOURCE-NOT-FOUND",
"message": "Invalid resource. Refer to API docs at https://dev.telstra.com"
When I send a "Create Subscription" request, I receive a brand new number and this results in a high impact issue as I no longer have access to the previously provisioned phone number.
I need this issue resolved ASAP, so please advise if I should create a new topic or request with the details.
Thank you
Hi Stephen,
Are you using free trial? Could you please share the following to our email address telstradev@team.telstra.com to investigate this issue:
1. TelstraDev company name / email address
2. API Key(s) impacted
3. Previously provisioned number
4. Newly provisioned number
Regards,
Vinodh
Hi Vinodh,
Thank you so much for taking a look at this.
I am using a Telstra Billing paid account.
I have sent you my responses to your questions via email as requested.
Hi Stephen,
Thanks for sending through the details. We are investigating this issue but have not found the root cause yet (but we will soon). However, running POST create subscription multiple times on a key should not assign a new number if you run them within 90 days of previous expiry.
One thing I noticed was that your activeDays is less than 30 days for all your keys but you can have upto 5 years of validity for your number.
Please run POST create subscription with activeDays 1825 against all your keys so that your number won't expire in near future and you don't have to run POST create subscription every month. We are also working on a new feature wherein the number won't expire at all if you use them once every 90 days.
Regards
Vinodh
Hi Vinodh,
Thank you for looking into this and providing the tip on the activeDays parameter, I will keep that in mind moving forward.
However since this problem is impacting a number/subscription that was created only 1 day prior, we are of course looking at a different situation :)
I noticed today in the FAQ you advise to wait 5 minutes after initially creating a new subscription, followed by re-running the Create Sub POST again to confirm that the phone number is the same - I've never followed this procedure on any prior Subs (including the one with the problem) and I will do so from now on.
While I completely understand the need to undertake root cause analysis for this problem, I would like to kindly request if you could prioritise resolving the Client impacts (namely mine) and investigate whether it's possible for you to manually reassign the initially assigned phone number back to me. This can be either under the same Client Key or a new one, I don't mind at all.
If I am able to assist in any way, I'm happy to do so, please just let me know.
Thanks again
Stephen
*Sending copy of this email with sensitive data hidden*
We found that the number (+614****80) previously provisioned was actually assigned to another key during the same time and due to a race condition the number finally got assigned to other key for another company. We apologise for the inconvenience caused and this is a rare event.
On further analysis, found that one inbound message was sent to previously assigned number and no outbound messages were sent from the previously assigned number. I can confirm that +614***25 is assigned to your keys properly and found no issues with it.
My recommendation is to use the newly provisioned number. In order to ensure this does not happen again, you can run POST create subscription with “activeDays: 1825” (please refer to our documentation here) which will ensure that the number is associated with your keys for next 5 years approximately provided there is one message sent every 90 days.
Please let me know if you require any further assistance.
Regards
Vinodh