Jump to content

Jack Russell Racing

Members
  • Posts

    30
  • Joined

  • Last visited

Posts posted by Jack Russell Racing

  1. Sounds like it's trying to transfer and the call is put on hold? Can you post the siptrace when you call into VM, we tried it here but could not reproduce it. Thanks

     

    Also there are some new feature in 8.7.3.10

    that could impact your experience on the phone.

     

    http://wiki.snom.com/Settings/disable_blind_transfer

     

    http://wiki.snom.com/Settings/retrieve_xferred_call_on

    http://wiki.snom.com/Settings/release_xferred_call_on

     

     

    Ahh... might be the blind transfer. I'll look at it today. Thank you!

  2. I'm struggling to get firmware 8.7.3.10 installed on Snom821 phones (we're migrating from firmware 8.4.31) in a SNOM One environment.

     

    The problem is simple, but its driving me bonkers! When a user goes into their voicemail to retrieve messages, they could normally just hit "7" to delete an ongoing message and either return to the menu or listen to the next message. Now, with 8.7.3.10, the phone seems to initiate a "HOLD" and put the voicemail connection into hold, and there's no way to even get back to the call.

     

    Any ideas on why the keypad doesn't seem to properly control the voicemail like before?

  3. Unplug the power, press and hold the "#" key and replug the power and release the "#" key after 10 seconds. This should start up the rescue mode which helps to reset settings to factory defaults or reflash the phone.

  4. Having lived with 'the other vendors' products for too many years, I cannot possibly imagine going back to *anything* branded with their name. I'd rather carry a SNOM hardphone in my travel kit, than deal with the other supplier's software. It was a constant refrain of: STUN this. Tunnel that. Proxy these. Update here. Downgrade this. Patch mine. Uninstall yours. It was a headache that never ended. Actually, I think the Verizon tag-line "Can you hear me now?" was the corporate mantra of the other vendor.

     

    End-to-End SNOM solutions work across our somewhat complex network -- and that's all the proof I need to stay happily in the SNOM family with 821, 320, and Bria deployed on a Windows 2008 server.

     

    Your mileage may vary. :D

  5. I am having the same issue with two of my SOHO's, the common issue between them is the ASUS router with Tomato USB. The SOHO is getting the google IP but cant reach it. I think the router is having an IPv6 issue. If I manually assign the IP of smtp.gmail.com (173.194.77.109) it works, at least until the IP moves :)

     

    Is there a way to only request the IPV4 address through DNS until I can get the IT person that installed the routers out there?

     

    Thanks guys!

     

     

    Same issue here... we "lost" about 2 days of backed up voicemail before we realized what was going on. Rather than mess with Gmail, we switched over to a legacy non-Gmail account and it all flushed through.

     

    In the meantime, I was seeing all kinds of Gmail errors about the CNAME records.

  6. A follow-up post, with a big THANK YOU to "pbx support" here...

     

    Using Vonage as a SIP provider, the settings that worked are (in Trunks->Number/Call Identification):

     

    Prefix: empty

    Trunk ANI: xxxxxxxxxxx (where xxxxxx is our 10-digit Vonage telephone number)

    Remote Party/Privacy Indication: Custom Headers

    Request-URI: Let the system decide

    From: Based on incoming call

    To: Let the system decide

    P-Asserted-Identity: Other "xxxxxxxxxxx" <sip:xxxxxxxxxxx@{trunk-registrar}> (where xxxxxxx is our 10 digit Vonage number)

    P-Preferred-Identity: Don't use header

    Remote-Part-ID: Don't use header

    P-Charging-Vector: Don't use header

    Privacy Indication: Don't use header

     

    :) All works great now.

  7. We ran into the same issue. Actually after the upgrade we couldn't make outgoing calls at all. After about 20 mins of playing with it we figured it out. We're using custom headers, which is a pretty cool feature because it allows you to set the caller-id to whatever want. The settings will need to be modified to match your SIP provider's requirements - since we are our own sip provider it was pretty easy. The problem more than likely lies in the Remote-Party-ID: portion. We set ours to "Based on incoming call" that way when a call comes in and the system reroutes it to a cell phone, we get the caller id of the incoming call rather than our office number. That way you can determine if you want to accept the call or not... uh I mean if you don't answer it in time, you can call them back :D.

     

    Hope that helps!

    Brian

     

     

    Uggg... I've tried a bunch of different variations, but cannot seem to find the magic bullet. Our incoming caller ID's are fine.... it is simply out going ID that shows on destination (people we're calling out to) as "Unkown". We're on Vonage, if that might help anyone point us in the proper direction.

  8. So finally I was able to try it out. I installed sipdroid (which was not installed yet), and essentially followed the setup for sipdroid. It was working within a minute. The biggest problem was telling the device to keep the WiFi connection alive, so that it would be possible to call the device even after the display has been turned off.

     

    So now I have a WiFi SIP phone for essentially 130 USD, and it even has a camera for scanning bar codes (apps make it happen).

     

    Were you able to get sipdroid working from 'outside' the SnomOne's network? Mine works fine within the network itself, but once I'm on another WiFi network or over the cellular network, it fails to register. (Yes, I have opened the IP access restrictions to ensure the new IP is permitted).

  9. Well, since idle hands really are the devil's playthings.... I went ahead and updated to 5021 and the new 5033. Everything works great and the LED is now dead :)

     

    http://<<PHONE IP>>/dummy.htm?settings=save&led_call_indicator_usage=PhoneHasCallInStateRinging%20PhoneHasCall

     

    Once again, I cannot express how great SNOM One is compared to our previous platform. Thank you.

  10. Feature comparisons are difficult. Both products have a longlist of powerful features. Cell phone IVR support might be better with snom ONE(especially with the latest), 3CX scores with their integrated soft phone onvarious platforms, including iPhone. But I believe the main point is that whenthere is trouble, snom has to fix the problem no matter if the problem is onthe phone or one the PBX. 3CX has no desktop phones, so customers are alwaysconcerned about the proper interworking inside the office, especially withfuture software updates. snom ONE also works on other platforms like variousLinux flavors and MacOS, FreeBSD and embedded devices such as the GuruPlug (notonly Windows), which can save significant amount of money.

     

    snom ONE free has no limits on the number of calls that you can make, up to tenextensions at an unbeatable price ("free"). Even the licenses formore than 10 extensions are an unbelievable bargain. At the end of the day,snom’s business model is to make money with the phones, and the PBX's job is tomake it easy to use them. 3CX business model is different; they need to makemoney with the PBX business andthere is no cross-subsidizing.

     

     

    Our company switched from 3CX to SNOM One about a month ago. It has been the happiest, most stress-free month I can recall, regarding our phone system. And yes... we did have a lot of experience with 3CX, having used it for about 5 years.

     

    3CX was constant drama between their crazy proxy/tunnel, STUN, reboots, BLF's locked up, etc. etc.... not to mention new releases that introduced new problems.

  11. Our company is still somewhat new to SNOM One (we are ex patriots from 3CX). I have to admit, I do not understand the 821 screens, and how to use them. These two shots are from my 821 phone that auto-provisioned from SNOM One (firmware is 821-8.4.31. We are not on the .32 firmware because of BLF bugs).

     

    So.. picture #1 (below)... what is it indicating to me? And why is the layout so wonky when our BLF buttons are supposed to be over on the right side (red LEDs)

    post-15635-0-94822700-1320412773_thumb.jpg

     

    Picture #2, the overlay (when another person is on a call) is very confusing to see through the transparency. Is this normal?

    post-15635-0-36364000-1320412824_thumb.jpg

  12. OK, so we have made the long awaited switch from 3CX and are happily running SNOM One now. We have all SNOM 821 phones deployed, all of which are considered 'external' to the PBX because it is hosted elsewhere. On 3CX we were obviously victims of SIP hacks on earlier releases of their software. With strong passwords, it diminished greatly, in conjunction with new releases. SNOM seems to have security considerations from the ground up. (thank you)

     

    Some basic questions about security:

     

    1) When we bind to MAC addresses on the PBX, does that mean absolutely no other devices can register to that extension, even if they hacked through the password? The MAC is the MAC, and that's all ? Right now, all our SNOM phones are 'MAC defined' in the PBX. Is this safest practice available?

     

    2) We use 8-digit mixed case random passwords. Sufficient?

     

    3) Limit registrations per extension is set to "1". Right?

     

    4) The fixed public IP address of our external phones are white-listed. Should we blacklist everyone else on earth? What is the syntax for this?

     

    5) What else can we do to 'hide' the PBX from things like sipvicious? In playing with a sandbox deployment, I turned logging all the way to maxi-detail. Within 24 hours, that sandbox environment was pounded with sipvicious probes. I assume our production system is getting the same beating.... does the IP blacklist prevent it?

     

    Thanks in advance!

  13. And that my friends, is how SNOM (in my use thus far) smokes 3CX.

     

    Zero fuss, zero mess. Made the modifications as shown above (thank you!) and whammo.... it works perfectly. I fully expect to relinquish our 3CX licenses in the next 30 days, based on all of our testing and beta-use.

     

    I can see a light at the end of the tunnel. The drama of our old system may soon be a distant memory. :) And mind you... we're not new to 3CX. We lived with it since early V3 versions as a registered/licensed account.

  14. Don't use the dialog-state BLF, this is very difficult to get working and you get another subscription for each button you have (not many in the case of 821, but a design misconception). You should just use buttons, which you can conveniently setup from the PBX web interface and then PnP to the phone.

     

     

    Can you elaborate on this a bit more?

     

    I created a button list at the domain level:

     

    NAME: 101

    TYPE: BLF

    PARAMETER: <sip:101@nnn.nnn.nnn.nnn;user=phone>

    LABEL: Mary

     

    NAME: 102

    TYPE: BLF

    PARAMETER: <sip:102@nnn.nnn.nnn.nnn;user=phone>

    LABEL: Steve

     

    and so on.

     

    I designated the Accounts (extension 101, 102, etc) to use that Button List. The phones are PnP (all are SNOM 821) The button list does not seem download or have any effect on the phones themselves. I suspect I am doing something incorrectly.

     

    PnP must be working properly, because the phones autoprovision fine, the firmware downloads from our server, the address book works fine, etc. etc.

×
×
  • Create New...