Jump to content

mattlandis

Members
  • Posts

    1,254
  • Joined

  • Last visited

Everything posted by mattlandis

  1. ahem...i just answered my own question. wow.
  2. does this mean lync "coolness" found its way into softphone?
  3. so, the release notes are for the acutal hard-m9. Is that what you meant to link to? so the soft phone is bit for bit the m9?
  4. check it out and if it can be implemented it will be VERY interesting.
  5. No. just that you'll need a https fax provider too. (doesn't need to be the sip trunk provider)
  6. no REFER in that senario. You are good. It might be good if you would work with a reseller as a good one will fill in all these details. Just a tip. ;-)
  7. https works perfect and industry experts seem to agree it is the future of fax. No need to go through the pbx. You can get seperate DID's. Tell me how many trunks and we can get you going.
  8. REFER is usually used in a call transfer situation. So typically it is not an issue for fax, door phones, etc.
  9. it is important to realize that even any ATA ports suppplied by Sangoma/snom Plus are considered 3rd party. But for fax the non-snom limitation shouldn't be much of a problem as the main limitation on non-snom is no SIP REFER and fax extension shouldn't generally need that.
  10. Is there anyway that snom could implement a simple fax via https into snom ONE? This would be incredible. (i am of course not aware of what copyrights, legal this would entail...)
  11. i did not hear of such an initiative.
  12. news to me. (But would be good news though) snom, could you weigh in?
  13. there is no "shared mailbox" in snom ONE. What you can do however is: #1-(as you already know) call that vm and type in pin #2- or, you can register the both physical snom phones (50 and 40) to extension 60 in snom One. Actually snom makes it pretty straightforward to provision this. Just put the mac of physical phone in extension 40 AND their own extension as appropriate. It would be a nice feature and you can help get it implemented by suggesting it here: http://snomone.ideascale.com
  14. snom: could the windows service pop a message that says: "Port xx conflict. Please take these action" and place event log in windows event log if it crashes? http://snomone.ideascale.com/a/dtd/better-indication-of-port-conflict-that-keeps-pbx-from-running/100151-11275
  15. are you using which fw of snom m9? there was a bug in the older fw of m9 that made it so that with snom ONE you can't transfer using REFER. (using *77 ...should work) I don't know what to tell you at the moment, because i think the new fw version that fixes transer, breaks dect.;-) (m9 is in the middle of hard times... patient partners/users have been waiting for the solution for quite a while ;-)
  16. There are tools to show who is on the line : pac, wac v1, etc. Writing a tool like I explained above requires ability to login as a user and collect the info. We are not aware how to do this at the moment. (perhaps we just don't know) Another thing is doing it in a non-traffice-intensive way.
  17. notice the items with the most votes actually were acted on. So either we're thinking the same or it is being watched. ;-) It's cool either way. snom ONE really is a great product.
  18. zaptel drivers are asterisk.
  19. Feature requests: the best UNofficial place ;-): http://snomone.ideascale.com/ I'm not sure what snom suggests for official suggestions.
  20. what about using BLF lights on the snom phones? (or any phone for that matter) Also, checkout PAC v1 or 2.
  21. Multi-core support?!!! on the roadmap?!!!! (we are far enough away from april 1 so that is not an issue...) If this is truly a roadmap item and not pie in the sky this would be very good.
  22. that would be nice. I think some concerns related to posting that is letting competing products know what is coming. But it could be released to partner nda.
  23. i spend considerable time explaining/correcting wrong views/etc about this. It would sure be nice if this artificial limitation could go away and we could get back to promoting snom benefits instead. ;-) Yes, snom ONE will allow a limited number of non snom devices as endpoints. Main limitations: no auto provision and no sip REFER(ie=transfer using phone button, but you CAN use *77[ext#]) The reason for this is to allow things like door phones, wifi sip phones, softphones, fxs etc that snom does not make and to accomodate non snom handsets that already exist in clients possesion till they can switch to snom.
×
×
  • Create New...