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