Search results for query: *

Also check Outgoing Group ID for your trunks. For example, if you have a PRI that is outgoing group 0, but you also have analog trunks configured as outgoing group 0. Something similar to this could be causing the issue.

Check your short codes and ARS routing. It sounds like outbound calls are hitting an ARS table that have trunks Out of service, then the call is failing over to another working trunk?

I had a similar issue on release 9.0 a few years back. In the case I dealt with the customer was able to dial out, but the called party wouldn't accept some of the DTMF digits. I upgraded the IPO to the latest build of 9.0.X and the problem was resolved. BTW it was on DS30 units in my...

Analog, PRI, or SIP trunks?

intrigrant is correct. It's absent message text, and it's a major pain to administer/remove it. I messed around with it years ago when I ran into a similar issue for a customer. Then I promptly never touched it again once I had the resolution needed.

In my experience, SSA showed a lot of packet loss with H.323 extensions as well and likewise I didn't get complaints from customers about bad call quality or dropped calls. The DiffServ settings in IPO Manager I believe are the reason that SSA reflects major packet loss. However I'm not sure...

Based on that information, there must be a shortcode conflict that's causing it to try to hit the trunk (Outgoing ID 10). Have you tried building a shortcode to force extension calls across the SCN? In the case of the monitor trace you sent-- create a system shortcode like this: Shortcode...

and also it is using the trunkline to connect to the extension to site A instead of SCN." Can you elaborate on this for me? What are the outgoing line group ID's for the trunks you have built in Site B?

what hardware do you have in site B's control unit? Are all the extensions in question IP phones? If not: Is there a combo card(s)? Or maybe a VCM card in Site B control unit?

No need to reboot the whole primary server, just find a maintenance window when you can log into :7070 and restart the service. A monitor trace might highlight the issue without a restart of services though, since you can recreate the issue fairly easily. Log into the expansion unit with...

Can you pull a monitor trace of the issue and post it please? Have you restarted the primary call server since adding the expansion unit to the solution? Have you restarted the expansion unit since adding it to the solution?

See this thread concerning your issue https://www.tek-tips.com/viewthread.cfm?qid=1750074

Yes that's normal. Every PLDS host ID has 11 in front of the SD card "dongle" number. What size is the SD card you're upgrading to Rls 11 on? Also, have you checked in SSA to look at how much space is left on that SD card (because I assume it's probably a 4gb card). If it's had multiple...

You need to upload that xml license file to the system with Manager. Under the license heading, click add and select PLDS as the type. If you open that xml file with notepad you can view the PLDS host ID in the text and verify it matches the IP Office you're licensing.

I don't believe WebLM will even work for a stand alone IPO Control Unit. It must be server edition or select.

Check SSA to verify that embedded VM is running? Then check the config to verify that voicemail is set for embedded System>Voicemail tab Also make sure the short code *8101 is still built and hasn't been deleted/removed.

I had something similar a while back and it was a bad trunk port. I found it by digging into SSA and looking at the voltage on the analog trunk ports.

Build the incoming call routes on the Primary server (even though they won't be used for the PRI's), this should allow you to duplicate/copy them to both 500v2 units without having to manually do it. Make sure before the duplication of the routes, that the destination's are set for every DID...

I believe I've seen this error before. If you're pressing the browse button and trying to insert the new name of the wav file into the explorer window of the server then it complains about permissions, but if you just type the name of the wav file into the properties of the edit play list...

If you have a ICR built for each DID and if they outbound line group in the ARS table matches the outbound group on the PRI then the system should inherently display caller ID for each extension when calling out. This is assuming the provider is allowing sending of these DID's and not just the...