[sip-comm] Good sip account provider


#1

Hi,

What are some reccomended sip account providers to use with
sip-communicator? Through bluejimp, I found ippi.fr. However, I'm
looking for those that work well, good enough as a reliable sip provider
for normal voice/video comms.

I searched the archive and found
https://sip-communicator.dev.java.net/servlets/ReadMsg?list=users&msgNo=705,
but it seems no one answered the original question.

Thanks.

···

--
Andrew
web: http://lewman.com
xmpp: andrew@lewman.com
pgp key: 31B0974B

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#2

На 23.04.10 03:53, andrew@lewman.com написа:

Hi,

What are some reccomended sip account providers to use with
sip-communicator? Through bluejimp, I found ippi.fr. However, I'm
looking for those that work well, good enough as a reliable sip provider

Out of curiosity, does that mean you had any problems using ippi.fr as a
regular SIP provider?

Cheers,
Emil

···

for normal voice/video comms.

I searched the archive and found
https://sip-communicator.dev.java.net/servlets/ReadMsg?list=users&msgNo=705,
but it seems no one answered the original question.

Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#3

I am using sipphone.com, which works well for me, but for the last
several months, they have not been accepting new subscribers (ever
since Google bought them).

I also use iptel.org, but sipphone.com had more services when I
started using VOIP, so more people call my sipphone number than the
other.

···

On Thu, Apr 22, 2010 at 9:53 PM, <andrew@lewman.com> wrote:

What are some reccomended sip account providers to use with
sip-communicator? Through bluejimp, I found ippi.fr. However, I'm
looking for those that work well, good enough as a reliable sip provider
for normal voice/video comms.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#4

On Fri, Apr 23, 2010 at 08:02:16AM +0200, emcho@sip-communicator.org wrote 0.8K bytes in 28 lines about:
: Out of curiosity, does that mean you had any problems using ippi.fr as a
: regular SIP provider?

I didn't try them yet. I'm hoping to get a list of a few that people
are using successfully.

Alternatively, I may just setup opensers and run my own.

···

--
Andrew
web: http://lewman.com
xmpp: andrew@lewman.com
pgp key: 31B0974B

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#5

would it be possible, that SC reconnects automatically after the connection is broken (e.g. change from WLAN to LAN or connecting via VPN: always with different IP address) with the SIP and Jabber accounts?

Some of my friends (who want to switch from skype to SC and are just "users") are very irritated about this pop-up windows and that the connections have been activated again "manually"

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

На 23.04.10 14:33, andrew@lewman.com написа:

On Fri, Apr 23, 2010 at 08:02:16AM +0200, emcho@sip-communicator.org wrote 0.8K bytes in 28 lines about:
: Out of curiosity, does that mean you had any problems using ippi.fr as a
: regular SIP provider?

I didn't try them yet. I'm hoping to get a list of a few that people
are using successfully.

You may also want to try iptel.org (we even have a native wizard for
them in SC) or sip2sip.info.

Hope this helps,
Emil

···

Alternatively, I may just setup opensers and run my own.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#7

На 01.05.10 17:29, Mr Smith написа:

would it be possible, that SC reconnects automatically after the
connection is broken (e.g. change from WLAN to LAN or connecting via
VPN: always with different IP address) with the SIP and Jabber
accounts?

Yes, this is indeed on our roadmap.

Here's the corresponding issue:

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=464

And previous discussions where this has already been discussed :wink:

https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=8352

https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=7881

https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=5121

https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=4644

I guess this leaves little place for doubt regarding the popularity of
the feature. Hopefully it won't be long before we handle it.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

This is the normal behavior for Jabber clients.

Peter

···

On 5/1/10 9:29 AM, Mr Smith wrote:

would it be possible, that SC reconnects automatically after the
connection is broken (e.g. change from WLAN to LAN or connecting via
VPN: always with different IP address) with the SIP and Jabber
accounts?

--
Peter Saint-Andre
https://stpeter.im/


#9

На 03.05.10 05:03, Peter Saint-Andre написа:

···

On 5/1/10 9:29 AM, Mr Smith wrote:

would it be possible, that SC reconnects automatically after the
connection is broken (e.g. change from WLAN to LAN or connecting via
VPN: always with different IP address) with the SIP and Jabber
accounts?

This is the normal behavior for Jabber clients.

Just saw Section 4.5 in 3920bis, so I guess that's what you were
referring to, right?

We'll take this into account. It would probably even make sense to
follow the same recommendations for our other protocols.

Thanks for the pointer!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi all,

I've just finished work on a reconnect plugin for all the protocol
providers. How it works :

Currently the NetworkAddressManager service scans every 3 seconds for
network configuration changes and fires events if such are found.
The reconnect plugin listens for those changes and take care of
currently available protocols.
- If we are run with no network all protocols providers that came into
state of connection failed are reconnected once the network goes up.
This way we obey the rules for connecting only the protocols which
were not offline last time we run, this is done by the ui, The ui
saves user interactions over protocols(clicking it he drop-down menu
with protocols) and connects them on startup.
- if protocol gets in registered state, the plugin remembers it and
also the currently connected interfaces, so when some of this
interfaces goes down we will reconnect. A simple test case for this is
: registering a protocol when we are connected to wired connection on
the notebook, then we connect the wifi and after that disconnect the
wired. This way the protocol provider connection registered over wired
connection is no longer active so we need to reconnect.
- if a protocol goes into unregistered state it means that user has
request its Offline so we no longer count it for any reconnection.
- if during normal run a network goes down we remember all currently
connected providers, so when network goes up we will reconnect them.
An example of this is standing-by our PC and when we woke it up
everything is reconnected.
- when during run, a protocol provider goes into connection failed
state we try to reconnect it. The first time this happens we choose a
random delay between 8 and 38 seconds which will be the initial delay
after which we will try to reconnect the protocol. It it goes again in
connection failed we try again reconnecting with delay = the previous
delay * 2; And this repeats till we get delay of 5 minutes. After
that we don't stop retrying reconnecting with delay of 5 minutes till
network is up.
And there are no more those dialogs reporting of connection failed for
every single protocol we have, everything goes in the background
silently.

I think that is all. If somebody thought of other case a problem in
currently pointed ones please report it :slight_smile:
And if there is some bug in the currently implemented cases I'll be
glad to hear and try to fix them.

Thanks and enjoy!
damencho

···

On Mon, May 3, 2010 at 8:26 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

На 03.05.10 05:03, Peter Saint-Andre написа:

On 5/1/10 9:29 AM, Mr Smith wrote:

would it be possible, that SC reconnects automatically after the
connection is broken (e.g. change from WLAN to LAN or connecting via
VPN: always with different IP address) with the SIP and Jabber
accounts?

This is the normal behavior for Jabber clients.

Just saw Section 4.5 in 3920bis, so I guess that's what you were
referring to, right?

We'll take this into account. It would probably even make sense to
follow the same recommendations for our other protocols.

Thanks for the pointer!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi Damian,
thx VERY much! This is really great.
I have tried the automatic reconnection by connecting with VPN-client to different IPs.

there are no pop-up windows appearing (as noted), automatic reconnection seems to work nicely! The buttons are turning green again.

the only thing what I have notice on my system (WinXP SP2, SC nb2642) that the contact groups are doubling in the user-interface after the new connection is established.

This disappears if the option "show/hide offline contacts" are pushed few times.

I dont know if this is really important and can be reproduced on other OS, screenshots are attached (sorry for covering the names).

kind regards, MS

UserInterface-doublingOfGroups.pdf (478 KB)

···

Hi all,

I've just finished work on a reconnect plugin for all the protocol
providers. How it works :

Currently the NetworkAddressManager service scans every 3 seconds for
network configuration changes and fires events if such are found.
The reconnect plugin listens for those changes and take care of
currently available protocols.
- If we are run with no network all protocols providers that came into
state of connection failed are reconnected once the network goes up.
This way we obey the rules for connecting only the protocols which
were not offline last time we run, this is done by the ui, The ui
saves user interactions over protocols(clicking it he drop-down menu
with protocols) and connects them on startup.
- if protocol gets in registered state, the plugin remembers it and
also the currently connected interfaces, so when some of this
interfaces goes down we will reconnect. A simple test case for this is
: registering a protocol when we are connected to wired connection on
the notebook, then we connect the wifi and after that disconnect the
wired. This way the protocol provider connection registered over wired
connection is no longer active so we need to reconnect.
- if a protocol goes into unregistered state it means that user has
request its Offline so we no longer count it for any reconnection.
- if during normal run a network goes down we remember all currently
connected providers, so when network goes up we will reconnect them.
An example of this is standing-by our PC and when we woke it up
everything is reconnected.
- when during run, a protocol provider goes into connection failed
state we try to reconnect it. The first time this happens we choose a
random delay between 8 and 38 seconds which will be the initial delay
after which we will try to reconnect the protocol. It it goes again in
connection failed we try again reconnecting with delay = the previous
delay * 2; And this repeats till we get delay of 5 minutes. After
that we don't stop retrying reconnecting with delay of 5 minutes till
network is up.
And there are no more those dialogs reporting of connection failed for
every single protocol we have, everything goes in the background
silently.

I think that is all. If somebody thought of other case a problem in
currently pointed ones please report it :slight_smile:
And if there is some bug in the currently implemented cases I'll be
glad to hear and try to fix them.

Thanks and enjoy!
damencho

On Mon, May 3, 2010 at 8:26 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

На 03.05.10 05:03, Peter Saint-Andre написа:

On 5/1/10 9:29 AM, Mr Smith wrote:

would it be possible, that SC reconnects automatically after the
connection is broken (e.g. change from WLAN to LAN or connecting via
VPN: always with different IP address) with the SIP and Jabber
accounts?

This is the normal behavior for Jabber clients.

Just saw Section 4.5 in 3920bis, so I guess that's what you were
referring to, right?

We'll take this into account. It would probably even make sense to
follow the same recommendations for our other protocols.

Thanks for the pointer!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Mit freundlichen Grüßen
Mr Smith
mailto:mr.smith476@googlemail.com


#12

Hi,

Hi Damian,
thx VERY much! This is really great.
I have tried the automatic reconnection by connecting with VPN-client to different IPs.

there are no pop-up windows appearing (as noted), automatic reconnection seems to work nicely! The buttons are turning green again.

Great, thanks for the report.

the only thing what I have notice on my system (WinXP SP2, SC nb2642) that the contact groups are doubling in the user-interface after the new connection is established.

This disappears if the option "show/hide offline contacts" are pushed few times.

I dont know if this is really important and can be reproduced on other OS, screenshots are attached (sorry for covering the names).

kind regards, MS

I think this is a known issue and is connected actually to the GUI and
latest modifications about filtering contacts.

Thanks once again for the report
damencho

···

On Tue, May 18, 2010 at 11:28 AM, Mr Smith <mr.smith476@googlemail.com> wrote:

Hi all,

I've just finished work on a reconnect plugin for all the protocol
providers. How it works :

Currently the NetworkAddressManager service scans every 3 seconds for
network configuration changes and fires events if such are found.
The reconnect plugin listens for those changes and take care of
currently available protocols.
- If we are run with no network all protocols providers that came into
state of connection failed are reconnected once the network goes up.
This way we obey the rules for connecting only the protocols which
were not offline last time we run, this is done by the ui, The ui
saves user interactions over protocols(clicking it he drop-down menu
with protocols) and connects them on startup.
- if protocol gets in registered state, the plugin remembers it and
also the currently connected interfaces, so when some of this
interfaces goes down we will reconnect. A simple test case for this is
: registering a protocol when we are connected to wired connection on
the notebook, then we connect the wifi and after that disconnect the
wired. This way the protocol provider connection registered over wired
connection is no longer active so we need to reconnect.
- if a protocol goes into unregistered state it means that user has
request its Offline so we no longer count it for any reconnection.
- if during normal run a network goes down we remember all currently
connected providers, so when network goes up we will reconnect them.
An example of this is standing-by our PC and when we woke it up
everything is reconnected.
- when during run, a protocol provider goes into connection failed
state we try to reconnect it. The first time this happens we choose a
random delay between 8 and 38 seconds which will be the initial delay
after which we will try to reconnect the protocol. It it goes again in
connection failed we try again reconnecting with delay = the previous
delay * 2; And this repeats till we get delay of 5 minutes. After
that we don't stop retrying reconnecting with delay of 5 minutes till
network is up.
And there are no more those dialogs reporting of connection failed for
every single protocol we have, everything goes in the background
silently.

I think that is all. If somebody thought of other case a problem in
currently pointed ones please report it :slight_smile:
And if there is some bug in the currently implemented cases I'll be
glad to hear and try to fix them.

Thanks and enjoy!
damencho

On Mon, May 3, 2010 at 8:26 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

На 03.05.10 05:03, Peter Saint-Andre написа:

On 5/1/10 9:29 AM, Mr Smith wrote:

would it be possible, that SC reconnects automatically after the
connection is broken (e.g. change from WLAN to LAN or connecting via
VPN: always with different IP address) with the SIP and Jabber
accounts?

This is the normal behavior for Jabber clients.

Just saw Section 4.5 in 3920bis, so I guess that's what you were
referring to, right?

We'll take this into account. It would probably even make sense to
follow the same recommendations for our other protocols.

Thanks for the pointer!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Mit freundlichen Grüßen
Mr Smith
mailto:mr.smith476@googlemail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net