Liviu, while you are at it (feature deleting record if TLS connection is down), do it for wss too :))
On Fri, Mar 20, 2020 at 2:06 PM johan <[email protected]> wrote: > as for point 3, I will check. > > > On 20/03/2020 11:43, Liviu Chircu wrote: > > On 20.03.2020 12:37, johan wrote: > >> > >> Hence, > >> > >> - when the softphone is registered, a call comes on that DID in udp > >> (we do lookup_location) and we send it to the user in tls (this works) > >> > >> - when the softphone is off for a long time, there is no record in > >> location so then I route the call via the provider to his real mobile > >> number (this works also) > >> > >> - the problem is when the mobile looses his dataconnection, then I do > >> have a record in location, I try to send the call, which will fail. > >> Upon failure, I drop the record in subscriber. And here the problem > >> begins. > >> > >> The invite is adapted at this point already for tls => provider > >> doesn't want it as he is udp. > >> > >> > >> So how can I have the original request back for routing to the real > >> mobile number ? Or how can I check if the user is still connected > >> (aka how can I send options to see if he's alive) before calling > >> t_relay. > > > > Hi, Johan! > > > > 1. this solution of calling remove() after a routing failure is > > nice. Alexey Vasilyev put together a feature request [1] related to > > this problem, where he asks for an automated mechanism of deleting a > > contact whenever its TLS connection is found to be dead. > > > > 2. Did you try to force the sending socket of the INVITE ($fs > > variable) to your "udp:1.2.3.4:5060" listener? I think this should > > work inside a failure_route and should properly route to your provider > > via UDP. Also, I believe Bogdan fixed this recently [2] (but master > > branch only?!), such that "$fs" is not set to the TLS listener inside > > failure_route - might wanna check. > > > > 3. As a long-term solution to this problem, we are working on adding > > RFC 8599 Push Notification support via SIP in OpenSIPS 3.1. The spec > > is still rather new, but I'm curious if your app's SIP stack supports > > it :) Basically, this will allow you to wake up the phone so it > > re-registers whenever you need to deliver an INVITE to it, in a > > standards-approved way. > > > > Best regards, > > > > [1]: https://github.com/OpenSIPS/opensips/issues/1769 > > > > [2]: https://github.com/OpenSIPS/opensips/commit/f73abff9 > > > > [3]: https://tools.ietf.org/html/rfc8599 > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
