Upgrading Asterisk 1.4 to 1.8

[dspaan]

I have two vicidial servers who have to communicate via IAX2. However i have some issues and after a lot of time troubleshooting i now want to make sure both vicidial servers have the same version of asterisk. Both servers have a very recent SVN release and are running ViCidial 2.8. However one of them has Asterisk 1.4.

How would i go about upgrading that one to the same asterisk version as my other vicidial server? Thanks for the help

[williamconley]

I wouldn't. Honestly. I'd perform a fresh install on a new server and swap it out (leaving you the option to "go back"). But I can honestly say that we have NOT had any problems with 1.4 and 1.8 communicating with each other on any servers. We HAVE had problems with a server that has 1.8 not stating "1.8.x.x.x-vici" as it should in admin->servers and having this cause all sorts of problems. Yes, a reboot is required if this value is changed.

Happy Hunting.

PS: You are NOT new here, but you earned one of these:

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

[dspaan]

Hey Bill,

I don't know what to put in my signature anymore since i run multiple different ViCidial servers....

Maybe i'll start making templates for each one haha.

Also our problem was very specific, i don't think many people use the feature we were looking for. I talked about it sometime before. It involves saving bandwith by using IAX2 trunking. Also i managed to get it to work. Here is what i did:

-I could not do a fresh install on the server that had asterisk 1.4 running, it was too risky and would take too much time do do safely
-The other server was not being used operationally yet so i decided to reinstall that one with ViCibox 3.1.15 found here: http://download.vicidial.com/iso/vicibo ... r/archive/
-Once that was done i made an IAX2 peer carrier on the server that had all the agents and campaigns on it like this:

Code: Select all

[TRUNKNAMESERVERB]
type=peer
username=TRUNKNAMESERVERA
secret=password546
auth=plaintext
host=IP OF THE HOST
requirecalltoken=no
context=default
peercontext=default
qualify=yes
trunk=yes
disallow=all
allow=g729

and dialplan entry:

Code: Select all

exten => _8XXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _8XXX,2,Dial(${IAXTRUNKNAMESERVERB}/${EXTEN:1},,To)
exten => _8XXX,3,Hangup

And on the vicidial server in the local callcenter i made this carrier:

Code: Select all

[TRUNKNAMESERVERA]
type=friend
username=TRUNKNAMESERVERB
secret=password546
auth=plaintext
host=IP OF THE HOST
requirecalltoken=no
context=default
peercontext=default
qualify=yes
trunk=yes
disallow=all
allow=g729

And then on the remote server with the campaigns and users i made phone extensions like these:

Code: Select all

Phone Extension: 8111
Dial Plan Number: 8111
Voicemail Box: 0
Outbound CallerID: 0000000000
Agent Screen Login: remote11
Login Password: remote11
Client Protocol: EXTERNAL

And on the local server i made extensions like these:

Code: Select all

Phone Extension: 111
Dial Plan Number: 111
Voicemail Box: 0
Outbound CallerID: 0000000000
Client Protocol: SIP

Now how this is works is if the agent in the callcenter in our end of the world logs in with phone code 'remote11' on the server that's running at the other end of the world it sets up an IAX2 trunk call with g729 codec to the server in our local callcenter where the hardphone is connected on extension 111.

This first agent uses approx 30 kbps up/down
The next agent uses only 8 kbps up/down
The third agent uses only 8 kbps up/down
etc!

You can imagine this saves a lot of bandwith. I also tested with ulaw codec but then the bandwith saving does not work. You can calulate how much bandwith you can save with this calculator: http://www.asteriskguru.com/tools/bandw ... ulator.php

Our callcenter plans to run 50 agents max. Now normally with ulaw codec and using individual channels this would be:

50 x 64 kbps > 3400 kbps up/down

(in fact on our firewall i saw ulaw even consumed more bandwith)

With g729 and individual channels it would be:

50x30 kbps > 1181 kbps up/down

But with trunked g729 calls the total bandwith consumption is:

1x30 kbps + 49x8kbps = 414 kbps up/down

And since our ADSL line has max 1000 kbps upload bandwith over here in this third world country this is a requirement for us.
I had to make sure both servers were running the same asterisk version otherwise i could setup a call but get one way audio and the call would drop after about 30 seconds.

Anyone who uses this guide post here and let me know if it works. Improvements are welcome.

[williamconley]

I didn't read the entire thing (skim!), but I do have a question for clarity ...

You use IAX2 trunking to save bandwidth (which is recommended by everyone who has ever invoked it as quite cool).

And you modified your system and have Tested to see 8k bandwidth per call on g729 IAX "extra calls" once the trunk is established.

But: Did you test the same scenario with SIP to see what the real-world difference is? Real world savings are always interesting, as opposed to "Look what I learned to do!" which is not entirely scientific. LOL

Having that comparison (where all other things are equal, and all that is changed is SIP/IAX) will probably make you a much more informed IAX/SIP user in the long run. And posting it would probably make this particular thread very useful for many future users.

[dspaan]

Yes, i did test with SIP but it doesn't allow the bandwith saving feature at all. It just adds the same amount of bandwith for each call. The same thing shows if you use the Asteriskguru calculator.

[williamconley]

Yes, i did test with SIP but it doesn't allow the bandwith saving feature at all. It just adds the same amount of bandwith for each call. The same thing shows if you use the Asteriskguru calculator.

Actually posting the results from a real world example (as opposed to "adds the same amount") showing bandwidth usage for 10 calls in one method vs the other ... would go a long way towards helping the next user to see how this works. Incentive to use IAX for trunking will likely result from an obvious "saved bandwidth!" posting showing actual output from something such as iftop with real calls on it (same number of calls, less bandwidth used ...). Anything short of that could always be misinterpreted and/or written off as a mistake.

[dspaan]

But i DID post that. The actual savings with 50 channels was 3 Mbps up/down.

[williamconley]

"the actual savings" is not the iftop output from two (otherwise identical) instances.

You've interpreted this to get your result. Many will ignore that as an error on your part (wishful thinking, oversight ... etc). But iftop results with call counts from both situations ... that's the raw data and everyone reading it can draw their own conclusions (including agreeing with your assessment, based on the data presently being shown).

Just because the little onboard computer from my car says it got 23MPG does not mean I won't cross-check it with actual gas purchases and odometer reading to be sure it's not "propagandizing" me to make the car manufacturer look better.

I only say this because it's a lot of work for some people to set up the test, whereas you Just Did and have this data handy. For some people, they will believe it not worth the effort to bother ... unless they see Real Data. Since you have it, if you post it ... you'll likely make some people happy to see that actual data (as opposed to your interpretation of the results).

[dspaan]

Hi Bill,

Doing a necro-post here but a good one. I was working on this setup again and decided to document the band with savings this time with iftop like you suggested. Here are the screenshots i made":

1 agent:





2 agents:





3 agents:





4 agents:





So with iftop it's even less because it's the specific G729 IAX2 trunked traffic. You see about 25kbps for the first call which is about right. Each additional call ads about 10 kbps.

[williamconley]

You're posting shows the number of agents, not the number of live calls. That's a bit vague. For real world, each of those agents must be on a call to a prospect ... yes? Without actual audio traffic (agent in a silent meetme room), I'm betting the g729 compression reduces the signal to almost nothing. But what happens when you have discussions? MOH? Reality?

[dspaan]

The idea is this.

Location A - The callcenter (in this case an offshore location with very low bandwith)
Location B - The dialer
Location C - The PSTN network where the calls end up

The business case is that you save bandwith for each agent channel between A and B. That's how many G729 licenses you need. In our scenario the dialer in point B is in a datacenter where there is enough bandwith and you can use ulaw codec. G729 would cost more if you used it for outbound calls with ratio/adaptive dialing. We also experimented with G729 passthrough mode a bit but we ran in to problems with audio files not being able to play.