Is there a scenario, where even BYE from UA on the dialog does not result in deletion of the dialog?
If so, can you please give an example for such scenario...
If you use RFC3265 the reception of a BYE for a call having pending subscriptions will not terminate the dialog. See RFC 3265 Section 3.3.4. Dialog creation and termination
If a UA doesn't receive the BYE, then of course it cannot know that the remote party has gone.
In that case, there are a few ways for it to realise that the dialog has in fact been terminated: it can use session timers, or watch what happens on the media plane - did those TCP connections terminate? have the RTCP reports stopped arriving? - or other mechanisms.
But otherwise, for the UA sending the BYE, the dialog has immediately terminated.
Related
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.
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.
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
I'm gonna use jainSIP in a softphone and I wonder somethings.
For events like hang up the call, hold, resume, cancel, reject the call, How the call Id can be pulled up to the softphone ? I know during an answer, it's the request.getHeader which provide call Id but for these events ?
Thank you in advance !
JAIN SIP gives you raw access to the message, you will have to build the functions of the SDK yourself ie call, hold, resume, cancel, reject.
is it possible to notify a SIP client when there is an incoming call on another phone?
I know that there are the SUBSCRIBE and NOTIFY commands but I have found no event package for signaling incoming calls.
Background: for a SIP-capable telephony system, I would like to provide an application that displays information about the caller (e.g. name, address, contracts, etc.) when the phone rings. The phones are external to the PC; they are not soft-phones.
-Frank
The dialog event package (RFC4235) is what you're after. The key realisation is that dialog's get established when the first non-100 response is received on an INVITE transaction.
A dialog is in the early state until the INVITE is answered with a final response but that doesn't matter as the dialog event package is designed to send notifications for early dialogs just the same as for answered dialogs.
Finding servers or providers that supprt the dialog event package is another matter. The best softphone that I have come across for SIP events is the Bria, as far as servers go sip2sip and my own sipsorcery have some level of support for the dialog event package although I must admit I have left out early dialog notifications.