How is a "SUBSCRIBE" request can terminate a SIP dialog ?
You should find all your answers in rfc6665. You may take a look more precisely at Section 4.2.1.4. Refreshing of Subscriptions and Section 4.4.1. Dialog Creation and Termination
Quoting some text of the rfc:
Here is the way to request the end of the dialog from subscriber side:
Clients can cause a subscription to be terminated immediately by
sending a SUBSCRIBE request with an "Expires" header field set to
'0'.
And the final NOTIFY that really terminates the dialog:
A subscription is destroyed after a notifier sends a NOTIFY request
with a "Subscription-State" of "terminated", or in certain error
situations described elsewhere in this document.
Related
I'm implementing a Handler for the DISCONNECT Intent, and by reading the online documentation https://developers.google.com/assistant/smarthome/reference/intent/disconnect, I see that it is no such response format and it is not a reference in case of fail event, when for example we return an error in event that we didn't properly handle the disconnect or Google API did not reach our server. Does Google Assistant implement some sort of automatic retry logic so that in event of error it automatically resends the requests for a certain amount time. In other words is it a way to tell to the google assistant to retry or return some error to the user that made the DISCONNECT request?
There is no response format for the DISCONNECT intent in the https://developers.google.com/assistant/smarthome/reference/intent/disconnect documentation because nothing is returned when the action.devices.DISCONNECT intent is executed (eg. Google does not retry based on your response status code). You can find more information on this at https://developers.google.com/assistant/smarthome/develop/process-intents#unlink
After an action.devices.DISCONNECT intent is sent, the Assistant stops sending any more intents for the user who has just been disconnected, and the associated cloud service also stops calling Home Graph APIs (Request Sync and Report State) for their devices and a SYNC request is triggered.
I have a bot running well receiving messages through the Facebook message webhook event. Everything works well when the user sends messages through the messenger app.
But When a user replies to the page story, it generates an incoming message as if it was a standard one and it's not possible to handle this context which is completely different form a user initiated conversation.
Any idea how to receive to differentiate a "standard" message from a "reply to page story" one ? Thx
There is no way to differentiate between these two entry points/sources. Both will trigger a regular message event with no specific attributes added that would allow you to differentiate the source/entry point.
I am dealing with a Private caller case where the Privacy header is only passed in the initial INVITE but not in the subsequent mid-dialog requests (e.g. CANCEL).
When the Privacy header is present, my downstream expects me to send them another header.
For the most part, I was able to deal with this by using dlg module to keep track of state within dialog so that the mid-dialog requests will know about the Privacy header's presence in initial INVITE.
However, a problem i have is that just for the CANCEL request, I am unable to add any headers to the SIP request relayed to downstream.
I've read in other posts (dated years back) that an option would be to use stateless CANCELs downstream. Another potential option would be to start a new transaction at my level.
I am wondering if there are other alterantives to this. I would've recommended my downstream to use $avp but it seems like even though initial INVITE and the CANCEL are supposed to be in same transaction, the $avp value stored in initial INVITE is not accessible by the CANCEL.
There are other tricks that can work. Such as using the Record-Route as a data store (that can be security issue) or asking downstream to use dlg module, which can be a big performance cost to the,.
I am wonder if any of you have solved this problem already.
Instead of dialog module , i prefer that using htable to store transaction until get ACK. It is faster than it . After getting ACK , stored transaction can be removed.
In addition , You can look at TM module and TMX module that has features about Cancel.
I have followed the steps to setup the Facebook Messenger platform. The verification GET web hook request work perfectly, as does the subscribe but when I submit the chat I keep getting the follow Developer Alert:
Hi Norah,
We've noticed that your Webhooks subscription for callback URL https://{domain}/v1/webhook has not been accepting updates for at least 16 minutes. Please verify that your callback server is functioning so you may continue to receive updates. If you need to update your callback URL, see https://developers.facebook.com/docs/messenger-platform/webhook-reference#webhook_setup
If your callback URL continues to fail to accept updates for 8 hours straight, we will disable your subscription. To reactivate the subscription, make a POST request with the same parameters, and it will be reactivated.
My post request works through POSTMAN.
Please can someone help me! This is driving me nuts!
Do you have logs on your server for that post requests?
Facebook requires you to return status code 200 for the post request, so they know that you successfully received it. When they havent, they try it again and if that still fails after several times, they will give you this alert.
Maybe facebook uses another content-type or message content than you used with postman.
Your server logs should give you more insights about that.
Depending on what Webhook events that you have subscribed for a page, there will be callbacks for those events, and more, on the url you have specified in the Web Hook set up.
If you had subscribed to the message_deliveries event, every time a message is sent, whether from a user to your page or from your page to a user, there is a, maybe more, calllback with a Message Delivered json object. The Webhook Reference has an example of the Message Delivered json object, but no specification or explanation on what the fields mean.
Occasionally I find that an undocumented Read callback is received, sometimes. The undocumented json data for this is like:
{"object":"page",
"entry":[
{
"id":"1722858134648129",
"time":1465407550812,
"messaging":[
{
"sender":{"id":"1131485883560113"},
"recipient":{"id":"1722858134642218"},
"timestamp":1465407550868,
"read":
{
"watermark":1465407548057,
"seq":428
}}]}]}
Essentially, you must code your callback to handle ALL types of json data gracefully, including unknowns, even though you may not be ready to process them further. For those that you are not ready to handle or uninterested in, return nothing with Http status code 204 (in fact every callback should return 204 as the type is void).
If you handle only those types of json data you are interested in, any unexpected json data will most likely raise an exception in whatever language your web callback code is written in and result in a 500 server error returned to Facebook. It is this 500 error that is causing Facebook to make that complaint in your question.
Twilio has provision for configuring callback URL while sending SMS, which is notified of events relating to changes in the delivery state of SMS.
What happens if my application misses one of these callback events? Say for example when my server is down and the callback request encounters a 502 or 500 response.
Does Twilio retry the callback?
If yes, how many attempts are made before abandoning the event notification?
Hope this thread isn't SUPER dead...
I set out to solve this problem myself by making twiliq.com. Disclosure: I'm the dude that made this thing.
You set it as your backup URL endpoint and it'll replay the message as often as you configure until your server recovers.
Twilio developer evangelist here.
Twilio webhooks (for SMS or phone calls) do not make retry attempts to the same URL if your application fails to respond with a 200 response.
However, you can supply a fallback URL that Twilio will request with the same parameters if your primary URL fails. We recommend that this fallback URL is not part of the same application so that if your main application is down, you can recover and continue the conversation, save the errors for later or return an error message to your user.
There is more detail on how best to use fallback URLs on the Twilio site.
Since an answer was posted for this Twilio has added support for retry attempts on webhooks. By default it will retry once on TCP connect or TLS handshake failures, but the type of failures it retries for can be adjusted and the number of retries can be set anywhere between and including 0 and 5.
Documentation can be found here:
https://www.twilio.com/docs/usage/webhooks/webhooks-connection-overrides