Thankyou. You make a very good point. A phone design feature or a stress design flaw.
I had not even started to consider what next to do to start sorting the phones out.
That is for sure something like the very first thing to try.
I have the registrations set at 15 minutes to save logging in remotely so frequently
just to reboot the phone and also so there is not so long to await for capture data.
I will now also consider it simply just more of a chance for glitches to emerge.
Overnight the remote phone went from IPv4 on line 1 and 2 to an IPv6 address for line 2 and
the local phone dropped using stun, however it is now showing the actual provisioned rtp ports.
I am thinking to have a close look at some Wireshark captures for what is happening with stun.
I am thinking to disable stun on the local phone because I am now getting the correct rtp ports.
Keeping the phones provisioned rtp ports would make configuring a local workaround much easier.
I am in no hurry to reconfigure or reboot the local phone just yet. If it aint broke don't reboot it.
I would like to look at the configuration scripting while it is still showing the right rtp ports.
From: Users [mailto:[hidden email]] On Behalf Of David Villasmil Sent: Monday, 17 April 2017 7:43 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] register phone in same local network as opensips
Could it be the phones don't try as often as they would normally register? I've seen cases where when a registrations fails, the timer for the next attempt is set to something like last period *1.5, so every time the next retry will be done one and a half times later than the last...
On Mon, Apr 17, 2017 at 12:05 PM Alexander Jankowsky <[hidden email]> wrote:
I have started noticing some unusual and perhaps erratic behaviour in the VoIP phones themselves.
When opensips is normally routinely taken offline overnight or for some hours and is then rebooted.
Depending on the phones configuration, the phones do not always register as consistently as expected.
At the moment, I am learning about opensips and bringing up the system with opensips 2.3.0-beta.
So I am consequently also making routine changes to the phone configurations, trying the options.
We have been using these same phones for some time for direct IP to IP calling and they are very stable.
So I really was not expecting the unaccountable port changes that I was seeing in the sipgrep captures.
While I am still learning to configure and make opensips work. You know, if it aint broke don’t fix it!
This goes a long way to explaining the odd behaviour I was attributing to the routers or to opensips.
Right now I am looking at a sipgrep capture that says the routers and opensips appear to be working.
I am investigating this and in one sense it perhaps may have simplified the configuration workaround.