Jump to content

kellenw

Members
  • Posts

    44
  • Joined

  • Last visited

Everything posted by kellenw

  1. Hello, I've got a couple CS410's and about 15 phones (a mix of Snom 320's and 360's) sitting in our "IT boneyard" collecting dust. They've not been touched in about 4 or 5 years at least. The CS410's have some old PBXNSIP firmware on them. Originally, I authorized purchase of them to deploy in a couple small branch offices of ours, but after trying for months and months to get them to function reliably, I made the decision to scrap the project. We encountered constant issues between the PBXNSIP software and SNOM firmware (there always seemed to be a couple of glitches between the two back then). Each time we'd upgrade one or the other to fix a problem, they'd seemingly introduce some other issue. hehe... They've sat in storage ever since. Now present day, a friend of mine who owns a small business said he was looking for a simple cheap pbx to deploy, and I casually said he could have one of the CS410's and as many Snom phones as he'd like if wanted to try them. He'd probably use no more than 4 or 5 phones. I'd have to help him get it all setup and working properly, so I would like to avoid a big time sink if these just aren't up to the task. My questions are: - Are the CS410's still supported? - What are my firmware options for them at this point? - Are the CS410's considered reliable/stable at this point? - Is this worth my time, or should I tell my friend to look for a different option? Thanks for any thoughts, advice or comments. Sincerely, Kellen
  2. I'm having this issue all of the sudden also.
  3. Thanks for the info Alex. I'm not sure what I should do at this point. I may need to just scrap pbxnsip for something more capable. That would be quite a let down considering the amount of time and money we have already invested in it, but if it's not the best route to go....
  4. Okay. I setup an extension (900) on the "HQ" box in the lab, and a trunk on the "branch" box to register to it. Both boxes show the extension is correctly registered. Now, how do I go about paging, transferring and using phone lines from one box on the other? I've tried the usual, but I'm stumped. Thanks!
  5. This would probably work out perfectly. I figured I would have to setup "gateway" trunks and so forth. Simple exensions and registrations would be a breeze, if they can accomplish what I'm looking for. I'm going to work on setting this up in the lab between the two CS410's I have, and I'll report back. Thanks pbxnsip!
  6. I have gone through the knowledge base and searched the forums, which shed a little light on this topic, but I'm still having a hard time wrapping my mind around the full concept and setup process. I currently have 2 CS410's running the latest v4 beta in the testing lab that will be placed in the branch offices. I plan to purchase a windows pbxnsip license for HQ. The system needs to do the following: - All users in all 3 locations can intercom each other. - Calls can be transferred from one office to any of the others. - Users can dial out on CO lines of other offices. Things I would like the system to do, but could live without if I had to: - BLF possible for CO lines of other offices. (without registing phone to other office's pbx) - Ability to pickup another office's ringing CO line (also without registering phone to other office's pbx... multiple registrations cause too many issues for me). - BLF for phone extensions of other offices (again, without registering phone to other office's pbx). Is this possible? Am I crazy for wanting to try it? Can someone point me to any documentation that covers this? Thanks for any input or advice!
  7. PNP Buttons setup: I have ext's 40, 41, 42, 43 on BLF for 4 SNOM 360's. I have ext's 651, 652, 653, 654 for park orbits. For example, when I dial ext 42 from ext 41 and answer the page/call, the correct BLF's for 42 and 41 light up (as they should). However, when I place one of the ext's (we'll say 42) into park orbit (on 651), the call parks correctly, the extension that was placed on park (42) hears MOH and the lamp for park orbit extension 651 lights up, but the BLF light for extension 42 that was placed on park orbit goes away. The extension 42 is still actively on a "call", so shouldn't it remain lit? Obviously 41 is not busy at the moment so it should not be lit (and it is not, so that's correct), but 42 should be lit up. It's busy on a call, regardless of whether it is parked or not. I've noticed this with all prior releases I've used as well.
  8. I too am waiting for a fix for this. Seems logical that when you pull a call from park orbit (regardless of method such as BLF or direct star code) that it should display the caller id associated with the party you are pulling from orbit. It's no fun having to ask "who am I speaking with" after they've already told you once before. It can be a little annoying for the caller.
  9. I just tried a demo account with Voicepulse and they support custom outgoing ANI (works perfect), so if PBXNSIP was capable of handing off the incoming caller id as a custom ANI in real time on a forwarded call, it would work like a dream. In the v4 beta, if you include a cell phone in a hunt group (under redirection settings in a user account/ext) and enable "press 1 to connect", the PBX will at least read back the incoming caller id when you answer and give you the choice of accepting the call (pressing 1) or hanging up (which keeps the call ringing to other phones in the hunt group). It isn't quite as you would like, but it's SOMEWHAT of a solution that will be out soon in a production ready release. I actually wouldn't mind having custom ANI on a forwarded call as a feature, though it isn't high on my list.... still would be handy though.
  10. My issue is a little different than shopcomputer's. Caller calls into system. Hunt group phones ring. Cell phone rings. If you answer cell phone, you get dead air... no connection to caller and caller's phone still continues to get ringing because system has not answered their call. If the snom hunt group phones pick up, all is normal. Simply put, the call isn't being connected to the cell phone when the cell phone is placed in the hunt group.
  11. pbx support - CS410 version. Single hunt group with incoming calls on 4 line sip trunk coming directly into hunt group (no AA). Calls are not "answered" by system until someone in hunt group picks up the call. Also single PSTN line on FXO port 1. Both the PSTN trunk and the sip trunk behave the same. Very basic setup.
  12. You could also put them in seperate VLAN's if your routers/switches have the ability to do so.
  13. I have udp as my selected transport method in pnp settings. It shows udp in the web gui. My snom_3xx_phone.xml file in <working dir>/generated/<domain>/<extension> shows: <user_outbound idx="1" perm="RW">sip:64.xxx.xx.xxx:5061;transport=tls</user_outbound> (x's were used to replace actual ip when pasting the line) Looks like it's still an issue.
  14. Two issues... one a possible bug, and two a suggestion for extending the functionality of the hunt group cell phone setup. This function half works for me in beta version 4.0.0.3204. An incoming call triggers the hunt group, and the associated desk phones/extensions ring like usual (good). The pbx calls the cell phone assigned also (good). However, the caller side continues to ring because the call is not being picked up by the pbx in any way (could be good or bad depending on call handling method). When the cell phone is answered, there is nothing but dead air, and the caller continues to ring and so do the other extensions in the hunt group (BAD). When the cell phone is answered the incoming caller should be connected, but instead it just continues ringing. If an extension answers the phone, everything is just like normal (good). Additionally, since this feature functions as a "find me" type feature, there should really be a time period option that can be selected to determine how long the pbx should wait before calling the cell phone (similar to the way the pbx already handles the extension specific "forward on no answer" function). Local extensions in the hunt group should have a chance to pick up the call first IF that is how the admin wants to set it up. The cell phone should be not just an extension but a "failover" for no answer by the hunt group. Scenario: There exists a busy support department (hunt group), and they must leave their desks quite often to address various issues in the field. Sometimes no one is there to answer hunt group calls at their desk, but it is VERY important that someone in their department does answer the call. They don't want ALL calls through the hunt group to ring their cell phones, but they do want them to ring them if no one answers within, for example, 20 seconds. This is the REAL VALUE in having cell phones included in the hunt groups.
  15. I don't have any custom xml files in the html folder at all currently. What firmware are you using on the Snom 360/320 with version PBXNSIP CS410 4.0.0.3204? I am on 7.2.23 at the moment, but I had the same problems with previous firmware also. Strange it's working for you and not me. I'll keep digging and report back.
  16. Totally forgot about that. Works just great now! THANKS!!! By the way, I'm really enjoying the improved web gui on the v4 beta version, and for the most part, things seem to be working quite well.
  17. Fair enough. Just important to keep in mind that many of the competitive IP PBX offerings already have this, and it allows for much easier and less expensive SMB setups.
  18. Example Setups: 1.) DSL Modem ---> CS410 WAN Port ---> CS410 LAN Port ---> Switch/Router with DHCP Turned off ---> Computers, Phones --- OR --- 2.) DSL Modem ---> CS410 WAN Port ---> CS410 LAN Port ---> Router WAN Port ---> Router LAN Port ---> Computers, Phones In theory, both of the above should work assuming the CS410 can act as an internet gateway using the built-in DHCP server. It could really help those folks who are having issues with NAT. Lack of firewall is a concern in #1 though. You probably wouldn't want a ton of traffic on your network either. The CPU in the CS410 isn't exactly beefy, and there is no QOS to speak of. For a small office of 6 users or less, this could be a workable solution though.
  19. Thanks for the reply pbxnsip. I assigned *51 to the "Forward calls to domain accounts" field, and saved and rebooted the pbx as well as the phone just for good measure. Checked the setting in the web gui and it's there, and nothing else is assigned the *51 command. However, when dialing *51 from the phone it states "this feature is not available at this time".
  20. Thought I would just follow up really quickly and let you know this bug still persists with the 4.0.0.3204 beta version. No matter what you assign in the pnp settings (udp, tcp, tls) it always assigns tls during provisioning for snom 360's (and I assume 320's also, though I haven't tried any of my 320's yet).
  21. It would be nice to have a specific forum section for bug reporting, discussion, resolution.
×
×
  • Create New...