NOTIFications can only be done on existing TCP connections

[dsandras]

If the TCP connection is down, or if the NOTIFY comes from a redundant server, then it will not work. The phone will not be notified of this, and its subscriptions will have to expire leaving it in an unconsistant state for a while. This looks dramatic to us.

See:
#17

Reporting it here so that everyone knows there is a problem. I suppose that the new async TCP code will allow reverting that commit.

[bogdan-iancu]

As pointed out by Saul, in 95% of the cases UACs are behind NAT, so makes no sense to try opening a TCP conn somewhere behind a NAT.
If connection is down, the UAC should re-open it when sending a re-SUBSCRIBE for the same presentity, from the same location.

Do you have UAC with public IPs ?

[dsandras]

In a company where opensips acts as a PBX.

Moreover, the rfc does not say the ua needs to resubscribe if the TCP connection is down. That means the ua can left one hour thinking he is subscribed when it is not.

Envoyé depuis mon HTC

----- Reply message -----
De : "Bogdan Andrei IANCU" notifications@github.com
Pour : "OpenSIPS/opensips" opensips@noreply.github.com
Cc : "Damien Sandrs" dsandras@seconix.com
Objet : [opensips] NOTIFications can only be done on existing TCP connections (#30)
Date : mer., juil. 31, 2013 21:46
As pointed out by Saul, in 95% of the cases UACs are behind NAT, so makes no sense to try opening a TCP conn somewhere behind a NAT.

If connection is down, the UAC should re-open it when sending a re-SUBSCRIBE for the same presentity, from the same location.

Do you have UAC with public IPs ?

—
Reply to this email directly or view it on GitHub.

[dsandras]

The problem is even worse in redundant setups where several proxies could notify... Perhaps your use case is like ekiga and ekiga.net, but another use case is a company server... The best is to introduce an option, but I won't have time for this soon.

Envoyé depuis mon HTC

----- Reply message -----
De : "Bogdan Andrei IANCU" notifications@github.com
Pour : "OpenSIPS/opensips" opensips@noreply.github.com
Cc : "Damien Sandrs" dsandras@seconix.com
Objet : [opensips] NOTIFications can only be done on existing TCP connections (#30)
Date : mer., juil. 31, 2013 21:46
As pointed out by Saul, in 95% of the cases UACs are behind NAT, so makes no sense to try opening a TCP conn somewhere behind a NAT.

If connection is down, the UAC should re-open it when sending a re-SUBSCRIBE for the same presentity, from the same location.

Do you have UAC with public IPs ?

—
Reply to this email directly or view it on GitHub.

[dsandras]

One last thought, such a behavior should be global : Invite, Message, actually every request relayed through TCP. It seems to me it is currently limited to notify, and it'd non configurable and thus misleading.

I suggest a global variable tcp_no_new_con having a global influence.

Just my 0,02$.

And in Belgium, 80% of routers support sip :)

Envoyé depuis mon HTC

----- Reply message -----
De : "Bogdan Andrei IANCU" notifications@github.com
Pour : "OpenSIPS/opensips" opensips@noreply.github.com
Cc : "Damien Sandrs" dsandras@seconix.com
Objet : [opensips] NOTIFications can only be done on existing TCP connections (#30)
Date : mer., juil. 31, 2013 21:46
As pointed out by Saul, in 95% of the cases UACs are behind NAT, so makes no sense to try opening a TCP conn somewhere behind a NAT.

If connection is down, the UAC should re-open it when sending a re-SUBSCRIBE for the same presentity, from the same location.

Do you have UAC with public IPs ?

—
Reply to this email directly or view it on GitHub.

[bogdan-iancu]

Maybe to have the possibility to control "per subscription" if TCP conns should be open or not for sent NOTIFYs ?

If we see the SUBSCRIBE as coming from behind a NAT (nat tests in script), we can "mark" the subscription not to open TCP conns for NOTIFYs.

Basically it gives you the option to decide from script if new conns should be open or not. And it is up to you as script writer to do it right ;)

[dsandras]

I think that could be the right fix...

Not sure I'll be able to work on that though, but perhaps Saul can have
a look ?

If not, it will be postponed until I migrate Ekiga.net to OpenSIPS ;)

Le 01/08/13 12:06, Bogdan Andrei IANCU a écrit :

Maybe to have the possibility to control "per subscription" if TCP
conns should be open or not for sent NOTIFYs ?

If we see the SUBSCRIBE as coming from behind a NAT (nat tests in
script), we can "mark" the subscription not to open TCP conns for NOTIFYs.

Basically it gives you the option to decide from script if new conns
should be open or not. And it is up to you as script writer to do it
right ;)

—
Reply to this email directly or view it on GitHub
#30 (comment).

[bogdan-iancu]

Damien,
As the fix is not simple and require changes from user perspective too, I postponed it for 1.11 (it will not be part of 1.10). I will work out this fix, not a problem.
If you need help with the migration, just let me know ;).

[dsandras]

Thanks for the feedback !

Damien

[bogdan-iancu]

This will be addressed starting 3.1 by the upcoming "tcpconn_mgm" module