Pointers for a larger setup from ground up

sorvani · November 3, 2021, 3:11am

it has fwconsole commands to do it all.

Hawkeye · November 3, 2021, 11:21am

Below is one line that would be starting point with100 as first ext. Is it complete enough? If it is, then all I have to do is figure out in VIM how to add 359 more rows and increment ext# by 1 and name by 1. In this example, moved some of the columns so the columns which need to increment by 1 are closest to the left.
Only the headers on row 1 which have values in the .csv file are in this reply.

extension secret name voicemail sipdriver tech port qualify qualifyfreq transport callwaiting_enable voicemail_vmpwd voicemail_options voicemail_same_exten disable_star_voicemail

100,REGEN,100,default,chan_sip,sip,5060,yes,60,udp,ENABLED,5757,attach=no|saycid=yes|envelope=yes|delete=no,no,yes,

BlazeStudios · November 3, 2021, 12:55pm

Why in the world are you using Chan_SIP? You need to start using Chan_PJSIP. Chan_SIP goes away in two years.

Hawkeye · November 3, 2021, 12:58pm

In order to add another 359 lines (extensions) all that needs to be done is this:
open the .csv file using vim editor in your freepbx

go to your first line with the first extension (this assumes you only created one extension but you want 359 more extensions in the .csv file in order to use bulk handler for extensions

once you’ve got cursor on first extension, type the following:
Y359p Geg w (c-v = ctrl+v and same with c-a)
In my case the name was in column 4 so you need to hit ‘w’ 3 or 4 times to move cursor. The press period ‘.’ without the quotes

Now you have 360 valid extensions

Below are a few of what I just created.

.
.
.
360,REGEN,360,default,chan_sip,sip,5060,yes,60,udp,ENABLED,5757,attach=no|saycid=yes|envelope=yes|delete=no,no,yes,

Hawkeye · November 3, 2021, 1:00pm

Blaze, I use chan sip because pjsip doesn’t show the remote RFC1918 addresses UNLESS we have created VPN between client router and DC router.
Ok I will re-do it using pjsip.

Thank you SO MUCH for your help Tom.

Hawkeye · November 3, 2021, 1:44pm

Blaze, you must understand that we have to get to client phones from time to time remotely. If they aren’t use RFC1918 addresses its a real PITA to get to the phones.

In the case where there IS VPN tunnel from client router to DC router, I don’t see what is wrong with pjsip because pjsip show endpoints will give me the RFC1918 address and we are able to get to the phone fast and make whatever changes are needed.

I have changed the new_exten.csv so they are all pjsip now.

BlazeStudios · November 3, 2021, 1:55pm

Why do people need to touch the phones to make changes? There’s over 300 phones as you pointed out so why would you ever want to have to touch each phone for changes? You would use the EPM for that. That is the point of a provisioning server.

This is always a poor excuse.

BlazeStudios · November 3, 2021, 2:05pm

I don’t know who flagged my previous posted about the poor NAT Handling and RFC1918 addresses. I know you may not like what I had to say but what I said was based in actual facts and truth. RFC1918 addresses in Contacts/Via headers and other sections of the SIP message going over the public Internet should never happen. SBCs/Proxies and other SIP systems would tag those messages as requiring NAT Repair, i.e. they would trigger error flags. It’s never 100% and you can’t rely on it as a method for managing remote phones.

I know people don’t like to hear these things but it doesn’t change the facts behind it.

billsimon · November 3, 2021, 2:57pm

I wouldn’t recommend taking such a strong stance on it.

Server-side NAT handling of endpoints is often better than whatever you can do on the NATted endpoint network. I have cases where telling the endpoint its own external IP causes problems, but letting it just know its internal IP works fine because Asterisk’s NAT handling takes care of the SIP and RTP routing.

Contact headers can legitimately have RFC1918 addresses. Route/Record-Route headers can take care of getting messages to these contacts if they’re operating through a proxy.

It seems like you have a certain way of doing it which works, but server-side NAT handling works well too, so maybe allow for “there’s more than one correct way to do it.”

BlazeStudios · November 3, 2021, 3:50pm

Well let me try this another way. There have been numerous cases where people have registered their FreePBX to a provider and then have issues getting inbound calls or audio from the provider. When the debugs are looked at the first thing pointed out is “Private IPs are being sent. Can’t send requests to private IPs over the Internet”. Clearly the other side got the request and knows it came from a public IP but they didn’t do any NAT repair and accepted things as is. So since the Contact Header gave a RFC1918 for location services, that is the URI being used for new requests. Since the top Via has RFC1918 all responses will be sent to that.

I have a small amount of sites that I have to deal with each time devices send a REGISTER to my Kamailio systems. I have to check the top Via and Contact header for RFC1918 spaces and then tell the system to use the received IP and then I rewrite the contact header with that IP. Kind of like how rewrite_contact for Chan_PJSIP does it. When SDP is detected it does the same thing, checks it for RFC1918 and replaces it with the public IP. Doing NAT checks and repair has been a SOP at any of the LECs/voip companies I’ve been at.

There was a point in my carrier where I was managing over 25K+ devices between ATAs, FXS gateways and IP phones. Everything was managed by provisioning servers. We had a lot of residential as well as business accounts. Many of them didn’t have static IPs or any way to do real remote access. RARELY did I have to use some sort of remote access software like VNC or TeamViewer to get access to the users network to get into their devices. Any modifications or updates to their devices was done purely through the provisioning profiles and servers. Same thing at LECs or other places where there were thousands, if not tens of thousands devices out in the field. Rarely did we have to get into devices directly for things and at that point it was purely troubleshooting and usually resulted in the device being replaced.

It is due to working at multiple carriers and providers which, oddly, seem to follow the same practices and methods albeit geared towards their business needs but overall the policies and procedures were the same at their core. So this is all based on experience and how I was trained and educated by others. Not only that if someone joined the company from someplace like Verizon or another LEC/carrier they were already familiar with things and a lot of the time is was “Oh you use X here. We used Y at my old place” but the core knowledge was same.

I know and accept there can be multiple right ways to do something. I just didn’t realize that manually logging into 100’s of phones to make changes versus a provisioning system was a right way. Everyone seems to be focusing on defending that RFC1918 space is perfectly acceptable to have in contact locations, etc. but seem to be missing the point of manually touching phones to make changes/updates when there are way easier and better ways of dealing with endpoint management.

Like I don’t deploy PBX systems, that is not what I do. I have some deployed but it’s not what I do overall. I have managed high volumes of devices remotely for almost two decades, it’s kind of the only way I can. So when I say there are better ways than this method I say it with a lot of experience and wisdom of that experience.

system · December 4, 2021, 3:50pm

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.