Re: [OpenSIPS-Users] help on failover routing

2020-03-31 Thread Giovanni Maruzzelli
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  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
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] help on failover routing

2020-03-20 Thread johan

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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] help on failover routing

2020-03-20 Thread David Villasmil
I’ve never done it, but I understand there’s a route every time a TLS
socket is disconnected. You can probably use that to remove the contact.

On Fri, 20 Mar 2020 at 10: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
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>www.opensips.org/events
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] help on failover routing

2020-03-20 Thread Liviu Chircu

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

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] help on failover routing

2020-03-20 Thread johan
my systen will be used for aid in this corona crisis (remote diagnosis 
by doctors).


We use a softphone on a mobile phone, this softphone has a DID assigned 
to itself.


The mobile phone has a real mobile number also.

The idea is when a call comes in from the provider on the DID assigned 
to that user, we call the softphone via data connection. If that doesn't 
work, the user should be contacted on his real outbound number



so:

provider receives call on DID that belongs to the user -> provider sends 
call to our system -> we dial the softphone of the user who has that 
DID-> if that call fails or cannot be made, we send the call back to the 
provider as an INVITE to his real mobile number.



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.



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users