Jamulus
Cordless (DECT) Phones disabled on private server's router after session #1367
Replies: 3 comments 11 replies
-
|
How are you doing the port forwarding? Is it to the LAN address of the server only, or to the whole network? |
Beta Was this translation helpful? Give feedback.
-
|
Only the LAN address of the server. |
Beta Was this translation helpful? Give feedback.
-
|
OK just checking that in case there was something to do with incoming UDP packets that was screwing up the phone. This sounds unfortunately like an issue with your particular router. Perhaps it just doesn't like the UDP-ness of Jamulus in some way (which might interfere with SIP in some way perhaps?) |
Beta Was this translation helpful? Give feedback.
-
|
My brother just had a problem similar to this. He does not use Jamulus. I don't have intricate details at the moment, but he phoned his service-provider and reset everything. The problem may be the phones, and/or service-provider-router in his case. |
Beta Was this translation helpful? Give feedback.
-
|
Well, this is a puzzle. if your analog telephone set is plugged into a Tel1 socket on the router, then the router is managing all the "VoIP" functions. If your phone function is disabled after a Jamulus session, the only conclusion is that there is a bug in the router. Have you been resorting to restarting the router after a session to restoring your telephone service? (As a long shot, after a session, you could try unplugging and plugging in your telephone. Maybe this would unwedge the router code.) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the first time this happened I powered the router off and on. That didn't work. Then I reset the base station for the telephones and reregistered all the handsets, and this worked. The second time I started with resetting the base station but this time it didn't work, so I reset the router (losing the port forwarding for Jamulus -- not a big problem) and when this didn't work I reset the base station again at least once and things finally got working again. |
Beta Was this translation helpful? Give feedback.
-
|
What I see from your description is that the router VoIP code is the "dial tone" handling is broken. First reboot the router, this also resets the router's dial-tone state machine. (Now the dial tone state machine is out of sync with your telephones.) Reset the base station, now the analog port will reset and it will try to acquire a dial-tone. Acquiring a dial-tone will now put the router and base station in the same state. Check if your router has a firmware update. Maybe you will be lucky. |
Beta Was this translation helpful? Give feedback.
-
|
It may be that an internal table or process in the router is flooded by the traffic and that affects your VOIP service (also managed by the router). |
Beta Was this translation helpful? Give feedback.
-
|
The provider will deliver a new modem/router next week, but couldn't tell me what kind. |
Beta Was this translation helpful? Give feedback.
-
@DavidSavinkoff
Additionally my brother's intercom connection for entering the building entrance stopped working, and my brther had to speak to the building manager to get this working too. What happened is that someone changed some 'settings that are related to intercoms/internet/telephones in the building', so give your manager a shout too. |
Beta Was this translation helpful? Give feedback.
-
Any help/suggestions for troubleshooting this issue would be greatly appreciated.
A few weeks ago, our a cappella chorus had its first Jamulus session with > 12 participants using a private server on my Mac, and apart from startup/learning issues, it went well. However, when I tried to use my DECT (Gigaset 260) cordless phones after the server had been shut down, I discovered that outgoing calls from any of the phones were no longer possible (always got a busy signal). Several router reboots and a reset of the Gigaset base station eventually restored telephone function, though at a loss of Gigaset phone directories, call history and Caller ID settings.
On Thursday, our choral group had a second, very satisfactory > two hour practice session with 16-17 participants using the same server. Once again, all the phones in my apartment could no longer initiate calls. Conclusion: this is not a one-time fluke.
The server itself performs very well, and doesn't seem to have any problem supporting the 17 participants. I did not update the server to 3.7.0 nor encourage the rest of our group to update their clients, because getting everybody configured and running before the 3.7.0 release took a couple of weeks, and I was not eager to repeat that experience just now; I couldn't tell from the 3.7.0 release notes whether there would be compatibility issues if we had the server at 3.7.0 and most clients still at 3.6.2.
Details
Location: Server and almost all clients in Milan, Italy; one client (temporarily because of lockdown) in Venice
Server Bandwidth (from Fast.com): 520 Mbps download, 92 Mbps upload
Internet Provider: Infostrada/Wind Tre -- FTTH connection
Server and 1 Client: MacBookAir (13", mid-2012) with 8 GByte memory, 1 TB SSD, Intel i7 @ 2 GHz running MacOS Catalina (10.16.7); PreSonus AudioBox iTwo
Additional client on LAN: MacBookAir (Just new enough to make the cut for Big Sur)
Remote clients: 15, Mixture of Mac and Windows
Jamulus: v. 3.6.2 launched in background with:
`#! /bin/bash
timestamp=$(date +"%Y-%m-%d_%H-%M-%S")
/Applications/Jamulus.app/Contents/MacOS/Jamulus -s -u 20 --norecord -l ~/Jamulus/Logs/jam$timestamp.txt`
Overall delay on LAN: ~ 25 ms
Router: Alcatel_Lucent I-240W-Q GPON Home Gateway, port forwarding for UDP 22124
Log attached:
jam2021-03-25_18-04-24.txt
Beta Was this translation helpful? Give feedback.
All reactions