lerman
-
Posts
19 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by lerman
-
-
It is not the same problem. In your case, the none of the messages are reaching "216.115.69.144". So this is either network issue or DNS issue resolving to the wrong address.
Thanks for the prompt reply. I can ping sip.flowroute.com (216.115.69.144), and can traceroute to it. I can do a telnet sip.flowroute.com 5060.
What in the log tells you that the messages are not reaching that address? Is it that there are no responses?
Regards,
Ken
-
My snomONE flowroute trunk has developed the same problem. It started yesterday for now apparent reason. Incoming calls work fine. Outgoing calls don't seem to work. Incoming calls DO work.
Log level 7 is attached.
Registration seems to be failing, but I have no idea why.
Ken
-
Are you using "Ad-hoc-Conference" or Schedule conference room?
If you're using Ad hoc you should be able to remove the Moderator Access Code and the
Participant Access Code. Have you tried calling into the conference room to comfirm?
Thank you.
I had just removed the Participant Access Code. I should have realized that if I didn't remove both, it would still ask for one. I can now dial in to the conference from two phones and I can transfer an outside call to the conference. One problem is that when I transfer the outside party to the conference it announces, "Welcome to the conference..."
This seems like an awful lot of effort and intellectual overhead to do something that on a key system is as simple as touching a single button.
Ken
-
Neither *53 or *85 is listed as a * code for SnomOne. In fact, "The codes 00 to 60 are reserved for speed dialing."
I tried transferring the call to a conference account "71" on my system. That disconnected my ext47 and gave the caller a message asking him to enter the access code. That clearly isn't what I want. (The caller gets the message even when the participant access code has been set to empty.)
Any other ideas?
Ken
Anyone?
Thanks,
Ken
-
If the party performed the "conference" hangs up the will hangup (because it is done locally on the phone). Other option is to make use of the PBX. Either park the call(*85) or push the call to a conference(*53)
Neither *53 or *85 is listed as a * code for SnomOne. In fact, "The codes 00 to 60 are reserved for speed dialing."
I tried transferring the call to a conference account "71" on my system. That disconnected my ext47 and gave the caller a message asking him to enter the access code. That clearly isn't what I want. (The caller gets the message even when the participant access code has been set to empty.)
Any other ideas?
Ken
-
I'm using 9.4.12. I'll upgrade when I get a chance.
I just tried conferencing. It worked as far as getting all of the parties on the call was concerned.
When I hung up the handset that first answered the incoming call, though, the call was terminated. That is not what I need.
How can I make the system act like a key telephone set? Ideally, a user could see the "lines" and just pick one up and share the call if there is someone already on it. Either of the two local parties could hang up and the call would continue with the remaining party.
It isn't necessary that the model be exactly the same, but the functionality is useful and necessary.
Regards,
Ken
-
Well the m9 has a couple of advanced functions that might come to rescue here. When you are in a call, press the key below the display that shows "options", then you can hold the call; then make another (internal) consultation call, and then either conference the other party in or transfer the call. If your house is no ttoo big, you can also should and announce a blind transfer; or as well also just pass the handset (phisical transfer). The beauty of DECT, see http://snom-m9.blogspot.com/2011/12/simple-transfer-like-in-good-old-days.html.
OK. So I tried doing this.
I called my number and answered it on ext47. Then I chose option "new call" and called ext72 which is a hunt group that calls all extensions. I picked up the call on ext40. Then on ext47, I chose option "bridge calls" and found that both phones could talk to the caller. Unfortunately, ext47 (the phone that did the original answer bridging) had its display go back to the idle (in-active) state and audio was just one way. That is, ext47 could talk, but it could not hear audio from either ext40 or the outside caller.
Ken
-
I'm building a system with two M9 base stations each with three phones on a Snom One system. I also have a Linksys SPA3102 for incoming calls only. The phones are distributed around the house and office and at any time, there is no way to tell who will be at each phone.
How can I:
1 -- I answer the phone and would like to have my wife on another (unknown) extension pick up the call?
On my present (key) system, I put the call on hold. Then do a general page: "Laura, pick up the call on line 1".
One way is to transfer the back to the hunt group. It will then ring again, and Laura can pick up the call.
Or, I can park the call, then do a page: "Laura, pick up the call parked on 50."
2 -- I answer the phone and would like to have my wife on another (unknown) extension JOIN the call?
I'm almost there with the system. Incoming (on the SPA3102) and outgoing (through flowroute) calls are both working.
Thanks for your help.
Ken
-
I uninstalled snom ONE, installed it again from http://wiki.snomone.com/index.php?title=Downloads, and then tried the following:
- added an IVR
- removed an extension and added it back
- removed an alias and then added it back
- removed a domain completely and then added it back
All my tests were successfull. What am I missing? Can you explain step by step what you are doing?
I don't have a repeatable test. I believe that what I did was try to add an IVR and got a message about too many accounts. So, I removed an account (#49) and then tried to add the IVR. I still had the same problem. So, I tried adding it back and was unable to. I saved my configuration.
I could send you the tar file if that would be of any use.
I should note that the release I'm using is not standard. I took a CentOs64 release, pulled out the executable and installed it on a debian (actually Ubuntu) 64 bit machine. It seems to be working in the sense that I can make and receive calls.
Ken
-
Home | Settings | Configuration | Factory Reset.
Note:backup first as this will reset everything to factory.
Well, backing up does me no good at all. It does no good to back up if you can't restore. So, I backed it up, did a factory reset, and then a restore. That doesn't get me back the account I had deleted. I also can't add it back.
It seems that the system lets you delete accounts, it lets you modify accounts, but once you've deleted an account you can't create another one to replace it.
My next attempt will be to try to understand the XML files, recreate the situation before I deleted the account, and manually create a tar file that I can then restore.
Ken
-
Thanks Matt, I'm sure that will work.
It doesn't answer the real question, though. Does the free version let you configure accounts the way you want them (with some limitations), or are you limited to the pre-configured accounts?
One SPA3102 connected to a landline. That will be used for incoming calls only (and for emergency calls).
One VOIP trunk (flowroute) for all outgoing calls and some incoming calls.
Multiple extensions (the bulk -- perhaps all) on a SNOM M9.
Incoming calls should ring all of the extensions. Ideally, the line that the call came in on would be identified and the caller ID would be shown. If no one picks up the call, it should be transferred to voicemail (email). It is reasonable for all of the emails to go to one account (although it would be best if the called line as well as the caller id is identified).
It should be possible for any extension to page the others (generally all at once as an intercom) and to tell someone to pick up the call. (e.g., Laura, Sandy is on line one).
This is for my home. We run a couple of small businesses -- each with its own line that rings rarely. I don't like shouting up the stairs for my wife to pick up the phone.
=====
My current approach is to have all of the calls come to a single hunt group that would ring all of the extensions. After a minute, the hunt group would go to a dummy extension that doesn't ring but goes right to voicemail.
Can that be done reasonably?
=====
An alternative is to have one M9 identity for each of my incoming lines. All the extensions would be on all of the identities. That would make it easy (I think) to associate a called line with a particular call -- and I could use a different email account for each (although they would all go to the same place).
If I go with that alternative, can I still intercom and have someone else pick up a call?
=====
Lots of questions, I know.
I'd appreciate any help you can offer.
Regards,
Ken
-
lerman,
snom ONE Free limits you to adding 10 extension objects in snom ONE free. You can add as many snom handsets to those 10 extensions as you want. (if I'm understanding correct.)
Another option is if you already have Exchange UM licenses/CALs. You could possibly use them as mailboxes...(i havent dont an exchange integration myself so dont know the issues)
But I have to agree with previous post, likely snom ONE blue is best, simplist and leaste costly option.
I attempted to add an IVR and got a message that I could not add an additional account. So, I deleted account 49 and tried again. I got the same message. I then tried to add account 49 back again. I still get the same message. How can I get back to where I started?
Ken
-
To do that, I'd have to extract all of the files from the .deb without running the installation. That could probably be done. The do the same with the centos file. Finally, I'd have to run the separate parts.
I think that is more work than I'd like to do. That's particularly true since a major attraction of snom One is that it is "commercial". Every time a fix was released for snom One, I would have to repeat the process. That would not be fun.
Regards,
Ken
Well, I did it. Unfortunately, I don't have the details handy. It's something like this:
1 -- Extract the deb package into a temporary directory tree (using dpkg-util -- or something with a similar name)
2 -- Do the same sort of thing with the centos .bin package.
3 -- Move the big executable file from the centos tree to the deb tree. Remove the old executable and fix the symbolic link in the tree to point to the new file.
4 -- Modify the control file so that the arch line says amd64 instead of i386.
5 -- Repackage the deb tree using the appropriate command.
Now its all set to go. Just install the deb package.
A -- It seems to be running OK.
B -- Now I have to learn how to configure it.
I suppose if I have the energy, I should just write a script to do all of the above. (But then someone will probably change the name of one of the internal files and I'll have to play catch up.)
Ken
-
Yea I agree. I think the only way is to start offering 64-bit build fpr other platforms than CentOS. The problem is that there are so many Linux versions out there, it is really not fur to stay up with the latest and build something for them. Anyway, I guess we need to run another VM to make this happen.
I would suggest offering 64 bit versions for every platform that you offer 32 bit. I'll be running this on an Intel mini-itx board that cost about $65. The whole box was less than $200 with a 150gig hard drive (which I probably don't need), and 2 gigs of memory, a power supply and case. A big attraction is that it didn't need a fan. I didn't need a 64 bit processor, but that seems to be what is offered these days (and dual core also).
The hard choice is which OS to support. I tend to use Ubuntu, but Debian seems to be equivalent and installs on Ubuntu (if I understand things correctly).
Ken
-
Hmm. What if you just take the binary from the 64-bit CentoS and the installation stuff from Debian? Just guessing here (not a big Linux guru).
To do that, I'd have to extract all of the files from the .deb without running the installation. That could probably be done. The do the same with the centos file. Finally, I'd have to run the separate parts.
I think that is more work than I'd like to do. That's particularly true since a major attraction of snom One is that it is "commercial". Every time a fix was released for snom One, I would have to repeat the process. That would not be fun.
Regards,
Ken
-
IMHO the CentOS 64 should work. Maybe we should set up a VM for ubuntu64 as well and include it in the list of builds that we provide.
No. I tried it. It doesn't install because of differences in /etc/init.d vs /etc/rc.d/init.d
and other similar stuff
/etc/init.d/snomONE: line 8: /etc/rc.d/init.d/functions: No such file or directory
Stopping : /etc/init.d/snomONE: line 37: killproc: command not found
./postinst.sh: line 34: /sbin/chkconfig: No such file or directory
/etc/init.d/snomONE: line 8: /etc/rc.d/init.d/functions: No such file or directory
Starting snomONE-ctrl: /etc/init.d/snomONE: line 25: daemon: command not found
-
Is there a download for 64 bit (amd64) Ubuntu? A Debian install would probably work.
Most of my recent systems are Ubuntu; not Centos.
Thanks,
Ken
-
We are a volunteer ambulance corps that needs 100 voice mailboxes (one for each member), but will only have around six physical phones. Is the free version of Snom One limited to ten physical extensions or ten total physical plus virtual extensions?
If I were designing such a system, I would limit the number of extension registrations at any one time, but not the number of defined extensions.
How does this system work?
Thanks,
Ken
New Registration Problem Using Flowroute
in Trunk Setup
Posted
I've been using flowroute as my voip provider for many months without problems. Starting this morning, I find that I'm unable to make outgoing calls -- my registration fails.
I logged onto flowroute and found that my sip password had been changed, so I changed it to match on my system. This did not solve the problem.
I then looked at an attempted registration using tcpdump (attached) and sent it to flowroute support. [Note that there are some extra captured records having to do with the m9 phones on the system.]
Flowroute support responded:
================
We have not changed anything in how our servers interconnect with your system. If your SIP credential password was reset, this would have been done thru the Interconnection tab of the Flowroute Manager. You will need to enter this new SIP credential password into your system.
In the captures provided, INVITEs and REGISTER requests are responded to with a 401/407 request for credentials, your system is then resending the original request without credentials. Please correct your system configuration to authenticate via SIP credentials. I am unsure why your system is not sending the requested credentials. You may need to consult your system documentation or contact Snom for support.
=================================
Since I started to write this, the system has magically started to work.
Do you have any comments about the contents of the log? (I'd sure like to know what I should do if this happens again.
Regards,
Ken
Kenneth Lerman
flowroute-register.pcap.txt