I’'m installing a system on a 10.100.100.0/24 network that also has traffic locally from 10.100.200.0/24 and local traffic from 192.168.1.0/24 (different building)
I have put all three local networks in the asterisk sip settings but I’m having some odd inter-office dropped calls.
In my network settings should my subnet reflect these three various subnets or can I just go with the 24 standard subnet? Thanks
Are the inter-office dropped calls coming from the other building?
Do you have QOS set up on your router between the buildings?
Are there any firewall settings on the router between the three subnets?
… it doesn’t really sound like a phone system issue as much as a networking issue. If you’ve got a lot of traffic happening, QOS or some other sort of traffic-shaping would need to prioritize voice traffic over regular network traffic.
Ehhh… QoS rules don’t kick in until the Router is mostly bogged down anyway, so that may not be your problem.
My suggestion would be to set up a VLAN of a totally different subnet for just the phones. This is still a kludge, but it will at least somewhat segregate your VoIP traffic from your regular network.
Better still, get the phones & all things VoIP on a different physical-layer network (cables, switches, routers, everything) & kiss your bandwidth-contention problems goodbye.
You’ll need to look at WHY the calls are dropping. The reason will be in /var/log/asterisk/full but almost always this is because something is getting in the way and trying to do SIP ALG. Maybe the phones are trying to say they’re on an external IP Address? There’s a router in the middle that’s messing with SIP traffic?
Unfortunately, you can’t really guess here, you need to actually look 8)
On this VLAN question - I’ve seen lots of people do this, and it almost always ends up with one weird bit of stuff that doesn’t let it work seamlessly. I’ve tried several different VLAN installations myself, and I always end up backing out and either installing a real LAN (drop a new switch in and don’t share the address space + set up routing rules so that the new network can talk to the Internet) or learn to share the address space (use the 10.10.x.x/16 network and put everyone in their own zone).
The frustration about this is that it “almost” works every time, but there’s always one thing that screws with you. Everyone agrees that it should work and would be awesome, but we’ve had lots of posters here (me included) that just can’t get it to light reliably.
Looking through the logfiles today it all appears quite normal with the phone leaving the simple bridge first for no apparent reason
[2018-07-30 10:51:01] VERBOSE[10782][C-00000886] app_dial.c: Called SIP/138
[2018-07-30 10:51:01] VERBOSE[10782][C-00000886] app_dial.c: Connected line update to DAHDI/i1/6178642550-681 prevented.
[2018-07-30 10:51:01] VERBOSE[10782][C-00000886] app_dial.c: SIP/138-00000c88 is ringing
[2018-07-30 10:51:07] VERBOSE[10782][C-00000886] app_dial.c: Connected line update to DAHDI/i1/6178642550-681 prevented.
[2018-07-30 10:51:07] VERBOSE[10782][C-00000886] app_dial.c: SIP/138-00000c88 answered DAHDI/i1/6178642550-681
[2018-07-30 10:51:07] VERBOSE[11118][C-00000886] bridge_channel.c: Channel SIP/138-00000c88 joined ‘simple_bridge’ basic-bridge
[2018-07-30 10:51:07] VERBOSE[10782][C-00000886] bridge_channel.c: Channel DAHDI/i1/6178642550-681 joined ‘simple_bridge’ basic-bridge
[2018-07-30 10:51:23] VERBOSE[11118][C-00000886] bridge_channel.c: Channel SIP/138-00000c88 left ‘simple_bridge’ basic-bridge
[2018-07-30 10:51:23] VERBOSE[10782][C-00000886] bridge_channel.c: Channel DAHDI/i1/6178642550-681 left ‘simple_bridge’ basic-bridge
[2018-07-30 10:51:23] VERBOSE[10782][C-00000886] app_macro.c: Spawn extension (macro-dial-one, s, 54) exited non-zero on ‘DAHDI/i1/6178642550-681’ in macro ‘dial-one’
[2018-07-30 10:51:23] VERBOSE[10782][C-00000886] app_macro.c: Spawn extension (macro-exten-vm, s, 20) exited non-zero on ‘DAHDI/i1/6178642550-681’ in macro ‘exten-vm’
Oh, it’s “one thing” for you? Lucky. I guess that’s why you bring in the Big Bucks. 
QoS (highly recommended) isn’t the answer since it only kicks in at high load levels – we get bad calls at 40% utilization sometimes, when QoS rules aren’t close to kicking in. VLANs (also highly regarded) don’t help either, as they all come together at the ISP link, plus everything else you alluded to. Bandwidth alone (the standard suggestion) isn’t the answer if Latency & Errors aren’t under control. Our worst outage to date was when a 3rd-party router, 3 hops up the line just stopped talking & there’s no more “Distributed Mesh” to route around it. I keep hoping to find something useful in the “Bufferbloat” conversation, but it’s still nascent & seems to be going nowhere for existing equipment.
I know this will ruffle a lot of feathers, but I still don’t really like VoIP, if only because it steals from my Network. I still remember the days when a phone call would shut off Data, even if the Data were more important. I’m +1000 on the idea of a separate-but-equal Physical Layer for the phones & PBX. But by the time we’ve spent that money we could go back to “old school” PBXes & there would be no need for VoIP in the first place.
Sorry for the OT rant.
Oh, it isn’t just “one thing”, it’s just “one thing at a time” and it’s a different “one thing” every time, and the “one thing” changes while we watch. It’s always tantalizingly close to working, but I just can’t get it to work reliably in my experience.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.