Jump to content

andrewgroup

Members
  • Posts

    615
  • Joined

  • Last visited

Posts posted by andrewgroup

  1. The continuing Service Flag Saga.

    In an attempt to build Service Flags that go set when a desired action IE.

    Mon-Wed-Fri 12:01-7:59 5:00p-11:59p (defines the open hours from 8:00a to 5:00pm) this flag should be set

    on Tues-Thurs-Sat-Sun 12:01-11:59pm (keeps the flag not set during these periods

     

    We are not getting the results we are expecting to see the flag go set on Mon-Wed-Fri during 8:00 to 5:00

  2. Divide and Conquer, keep it Simple and the term "the more the merrier", simply doesn't make sense when it comes the the single most important piece of technology for a business (the telephone). Computers can burp, the internet crash, but interupt the boss on a few telephone calls, and you'll hear about it immediately.

     

    Adding more functionality would only increase the security footprint and decrease reliability. We already have a hundred choices of routers with far more functionality than we can use. Some really terrific routers with full support for NAT, SIP, VPN, PPTP, QOS, SNMP, central management, reporting, many on their umptenth OS revisions can be had for less than $200.00

     

    Our .02 - Cheers

  3. I hope this plan is not being crossed by the license key. Some homework to do...

     

     

    Attention PBXnSIP Sales;

     

    I recall seeing, reading or dreaming that PBXnSIP was moving or had moved to licensing extensions and somewhat abandoning the account limitations. Except for Recording, maybe agent groups etc the professional releases.

     

    Is this true?

     

    If so, for clients with previous license heys that would normally exchaust the accounts if we move to create this more flexible AA and Service flag based plan, how might we apply, obtain, beg borrow or buy a replacement license to increase these service accounts while not expanding our extension accounts?

     

    A post of PM is welcome..

     

    Cheers,

  4. Seems many of us are confused on the functionality and use of service flags. I've read almost every post, every WIKI and it seems we are all working from Scratch as we try and satisfy client needs.

     

    we plan to develop a default setup that meets a wide variety of SMB needs...and based on what I've read and the recommendations posted this should be easily accomplished. (assuming that PBXnSIP is now license by the extension count and not generic accounts that burn when you use them)

     

    A typical small business may or may not have a PC so please don't recommend making someone a domain admin, everything I outline below needs to be from a phone (and it would be nice to dial in for some features)

     

     

    1. Every System needs a Manual Flag for OPEN and/or Closed

    By this I mean in each service flag for that might exist in an automated attendent the business owner can decide at anytime to be open, closed by having a designated extension dial a manual service flag..

     

    I think this might mean that we would preceed any scheduled service flag with these manual flags and designated automated attendants.

     

    for example

     

    AA #70 normal Business Hours Greeting (Scheduled)

    AA #71 Normal After Hours Greeting (scheduled)

    AA #72 Closed (scheduled as in Holidays)

    AA #73 Closed (unscheduled Snow Storm)

    AA #74 Lunch Hour (Scheduled)

     

    Scheduled Service Flags

    SF #80 used for normal business hours

    SF #81 Lunch hour

    SF #82 Holidays

    SF #83 Business is closed

     

    Manual Service Flags

    MF #90 Open

    MF #91 Closed

    SF #92 Unscheduled Greeting Manual Flag

     

    My undertanding is if you define a time range for a scheduled service flag, then the service flag will be unset during designated hours? Right

     

    the following is the plan.

    SF #80 is scheduled M-F 8:00-12:00 12:30p-5:00p

    SF #81 is scheduled M-F 12:01p-12:29p

    SF #82 is scheduled 00:00-23:59 on designated holidays

    SF #83 is scheduled M-F 12:01-7:59 5:01p-11:59p

     

    I'm think the goal is to make every greeting a scheduled time.... This way in the service flag field we preceed the desired AA greeting with all other Service Flags, both manual and scheduled so that the business can make changes by dialing the appropriate Manual Flag and recording a greeting as needed in the unscheduled AA if needed.

     

    The Normal AA#70 greeting would watch all other service flags, and the manual flags would be listed first and the correct AA be listed in the service account...Sending all calls to the main AA would then spawn Holiday, Lunch, unscheduled closures, lunch etc....

     

    Am I off my rocker on this, or made this way to complex? Not month goes by, that we don't get a email request telling us they are going to be open or closed later or earlier and asking us to flip the switch.... (The caller is normally not well informed or knowledgable) or could be a temp, etc...

     

    Dialing a manual service flag from a designated extension to be open later seems a whole lot easier....

     

    there was once talk of resetting manual service flags at Midnight?

     

     

    Creating a proven setup to accomplish this would go a long way to answering the many posts...

     

    cheers,

  5. We were debating to not give the root access to avoid issues like these. What you don't know shouldn't hurt you. :)

     

    Removing Root access would be fine, but wait until the PBX has considerably more features to do the basics that require root access like removing old CDRs, Messages, diagnostics and more.

     

    Cheers.

  6. The CS410 has 3 interfaces eth0, eth1, and eth2

     

    The following is from a CS410 that has the WAN port set to 192.168.1.99 and the LAN port Disabled, NO DHCP....

     

    My question is, why does eth0 have 192.168.192.168 ? and then look at the Route table below...

     

    via root login issue ifconfig and see this listing.....cont

     

    comcerto:~# ifconfig

    eth0 Link encap:Ethernet HWaddr 00:19:15:68:40:4A

    inet addr:192.168.192.168 Bcast:192.168.192.255 Mask:255.255.255.0

    UP BROADCAST RUNNING MTU:1500 Metric:1

    RX packets:0 errors:0 dropped:0 overruns:0 frame:0

    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

    collisions:0 txqueuelen:1000

    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

    Interrupt:22

     

    eth1 Link encap:Ethernet HWaddr 00:1A:1B:1C:1D:1E

    inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0

    UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1

    RX packets:245087 errors:0 dropped:0 overruns:0 frame:0

    TX packets:29175 errors:0 dropped:0 overruns:0 carrier:0

    collisions:0 txqueuelen:1000

    RX bytes:48989618 (46.7 MiB) TX bytes:6292542 (6.0 MiB)

    Interrupt:1

     

    eth2 Link encap:Ethernet HWaddr 00:19:15:68:40:4B

    inet addr:192.168.1.99 Bcast:192.168.1.255 Mask:255.255.255.0

    UP BROADCAST RUNNING MTU:1500 Metric:1

    RX packets:32492 errors:0 dropped:0 overruns:0 frame:0

    TX packets:30379 errors:0 dropped:0 overruns:0 carrier:0

    collisions:0 txqueuelen:1000

    RX bytes:6022647 (5.7 MiB) TX bytes:6845701 (6.5 MiB)

    Interrupt:29

     

    lo Link encap:Local Loopback

    inet addr:127.0.0.1 Mask:255.0.0.0

    UP LOOPBACK RUNNING MTU:16436 Metric:1

    RX packets:133 errors:0 dropped:0 overruns:0 frame:0

    TX packets:133 errors:0 dropped:0 overruns:0 carrier:0

    collisions:0 txqueuelen:0

    RX bytes:30111 (29.4 KiB) TX bytes:30111 (29.4 KiB)

     

    What I don't like and fully understand is the route table....

     

    comcerto:~# route

    Kernel IP routing table

    Destination Gateway Genmask Flags Metric Ref Use Iface

    192.168.192.0 * 255.255.255.0 U 0 0 0 eth0

    192.168.1.0 * 255.255.255.0 U 0 0 0 eth2

    1.1.1.0 * 255.255.255.0 U 0 0 0 eth1

    default 192.168.1.1 0.0.0.0 UG 0 0 0 eth2

    default 192.168.192.1 0.0.0.0 UG 0 0 0 eth0

     

    With LAN disabled, I would have not expected that port exist..and does this route table present potential problems for broadcast packets?

  7. This is fun.

    Why did two of the largest PBX developers in the World Select Linux as opposed to a RTOS? Avaya, Nortel BCM and Nortel Just announce Linux is going into the VSP9000 series equipment. Any guess as to how may installations of Asterisk/Linux are deployed around the world?

    I'm not suggesting that any of these are on par with the long list of superior products you have listed, but it does indicate a trend according to my understanding of statistics. The way I see it, is that PBXnSIP, Linux, and MindSpeed are fully consistent with these trends.

     

    I do hope the replacement unit addresses your problem.

     

    I do think the most common problem with most VoIP installations is a lack of understanding and poor diagnostic skills. Of course things must be configured to leave traces to indicate the problems too. this is where managed devices and monitoring systems come into play.

    Cheers,

  8. A realists reply to a RANT.

     

    Crack one open and you'll find the following http://www.mindspeed.com/web/product/categ...;trail=562,1039 A Single chip (no stand-alone Realtek), designed and in use by hundreds of thousands of OEM devices around the world. This isn't a 2-bit organization building a clone on a chip, but an internationally recognized leader in voice processing. See their line-card http://www.mindspeed.com/web/download/down...jsp?docId=30526

    The have an embedded release of Debian 3.x and core technology to support their integrated analog gateway and LAN interfaces. It's really a matter of PBXnSIP working with their provider to further expose capabilities to the development team without making a code that would be specific to the CS410.

     

    As the the rest of the commentary on T1's etc, OK.

     

    Cheers

  9. The OEM technology behind the CS410 is made by http://www.mindspeed.com/web/home.html they are perhaps one of the largest manufacturers of this type of technology that serves as the basis for many different PBX platforms. Technically 10/100 BaseT L1/L2 stacks have been around for a very long time and I do not arbitrarily agree without some very strong evidence the chipset is to blame. For the most part all previous bugs or features within PBXnSIP have been addressed by the PBXnSIP development team.

     

    However, Since PBXnSIP has offered such a product onto the market they need to create clearly understood documentation and setting recommendations for use on a wide variety of Analog Lines. They are competing with traditional PBX systems that have operated on the same analog lines that continually take much of the blame in many posts. well over 1,000,000 Lucent Partner phone systems have been sold and installed throughout the world and I'll guess 75% may still be in use today and they are on the same crappy analog lines.

     

    So the challenge is to make the system tolerant of a wide range of potential issues and to know them ahead of time as to prevent problems for customers considering PBXnSIP.

     

    Cheers,

  10. The problem and solution to this old topic http://forum.pbxnsip.com/index.php?showtopic=1194

     

    Was the user had a DLINK or LINKSYS firewall router with PNP enabled... for some reason the Linux OS within the CS410 apparently was getting hammered by PNP traffic or something to that affect.

     

    We have a remote CS410 installation and we are seeing a LinkSys SRW business series switch having errors with PNP overload entries in the database. (Gee, if the Switch is seeing these packets, it's likely the CS410 maybe seeing these also)

     

    The LAN switch shows no layer 1/2 errors,

     

    Things I'm going to guess may be happening...

     

    A local windows PC has Internet Gateway Device Discovery and Control Client installed and it may be doing something to the system.

     

    More as I discover and analyze this problem...

     

    I'm starting with http://www.upnp-hacks.org/upnp.html

     

    Disabling PNP has been referenced in other posts and configs are going with TFTP only

     

    More on this as I progress.

  11. I haven't tried this yet, but thought it would be worth a post until I can test this...

     

    Rather than flipping scheduled service flags send all calls to a main AA that monitorings three service flags.

     

    The first two are labeled

    400 OPEN

    401 CLOSED

    402 SCHEDULED

     

    The AA Monitors them in this order....

     

    400 sends you to a normal business hours AA 800

    401 would send you to a closed business hour AA 801

    if neither 400 or 401 are set then 402 sends you to the normal business hours AA 800

     

    Then by allowing an extension to flip 400 or 401 you would affectively be allowing the PBX to be either open or closed whenever you wish...

    Could it be this simple? Of course you burn more accounts, and does the new licensing policy (EXTENSION) apply to CS410 to get extra accounts?

     

    Will try this later...

  12. With no direct method to flip a scheduled service flag, I keep kicking around ideas that would first check a manual flag before processing..

     

    Perhaps inverting the logic of the service flag to show the closed hours vs the open hours...

     

    but then during normal hours a manual flag could indicate to be closed..

     

    My head gets dizzy, as the realization from clients that then would want to control this from their home or cell phone...

     

    A 20+ year feature on common PBX's from Avaya, Panasonic, etc seems to be an insurmountable obstacle and a thorn with every installation we have to date...

     

    Any Hope for PBXnSIP every having flippable scheduled flags as discussed on numerous previous posts over the last 24 months?

     

    Cheers.

  13. when the CDR folder consumes the remaining space on a CS410, (15,000+ calls) the CS410 simply stops recording....

    Using DF and DU while logged in as the root user we see the trouble and deleted the many cdr files...

    Have we overlooked provisions in PBXnSIP to prevent or limit the growth of these or other folders?

    If not I suppose I'll cron a job to get these values and mail the output to our ticket system.. (Maybe Grep for a certain value) then mail to manage the exceptions.

     

    A better solution would be adding a new SNMP variable that goes from 0 to 100 that would represent either used or available space.

    I'll post that on SNMP too...as a reminder.

  14. Today we had a client PBX with park orbits and low or easy SIP passwords get remote registrations from a Canadian IP address and the clients PBX was making outbound BANK CARD scam calls.... Caught it early but the lessons are clear and a few best practices are coming from the experience and perhaps a feature request...

     

    Lesson 1. Complex Passwords are a must - No longer can we make it easy for the users

    Lesson 2. Park Orbits will not enherit a default dial plan

    Lesson 3. enable more logging an email notifications on extensions

     

    Possible Feature requests - (optional allowable IP Address ranges on an ext Basis for phones to register from.

     

    Cheers, and learn from the experienced.

  15. Just for right understanding: Is the way you are describing a "should work", a "hint for the developers" or a "working solution"? For the last: How to enter the Equation in the service-flag fields?

     

    Best regards,

     

    Lucas Hummig

     

    No - since resetting a scheduled service flag hasn't made it to production during the last year, I was brainstorming if it might be possible to make a Rube-Goldberg method to accomplish the same think using several manual service flags. The idea of putting a Manual Flag ahead of a scheduled flag would work, but it would never reset... (I'll post a feature request to allow manual flags to be reset at Midnight)

     

    I hope the development team revisits this in earnest. For several clients it's a huge issue and they have nobody on staff that could login and reliably change dates, or reset flags.

×
×
  • Create New...