Vodia PBX

I guess the problem is that the service provider tell the PBX to send the media to "192.168.1.1". AFAIK that is a private IP address and that's where the PBX will try to send the RTP stream. Are you calling from another device in the LAN?! Does the call go through after accepting the call?

We have the PBX running on the Marvell Armada chipset, which is ARM based and there it works very well. There you can have 10 G.729A transcoding sessions in parallel. Especially because modern codecs like Speex, Silk, RTA are not very DSP friendly, I would not over estimate the availbility of a DSP. This Marvell chipset does not have a DSP subsystem; so thats something that we would have to take care about. As long as there is a toolchain available (and Linux) it should be easy to comiple the PBX for the target architecture. Anyway, for such kind of questions, it is probably better to have such discussions on private; please send a private message to pbx support and then we'll take it from there.

Hmm. So the other SIP account works? Are you using UDP transport layer there as well? I am asking because your firewall might block UDP traffic. What firewall is it? Something "smart"? What confuses me is that the time is not set. What are you using as time server? Maybe we should focus on finding out why you don't get a time; this might be the solution for the SIP problems as well. The m9 has a feature that start the PCAP trace after reboot. If you turn it on, you will be able to see the NTP packets and possibly the responses. Then we might get an idea why the time is not being set.

You cannot search the calls table at this time. Sorry.

Also looking at the timestamp, looks like the m9 was not able to pull down the correct time. Are you sure the m9 goes to the public Internet?

That is actually a phone topic (see http://wiki.snom.com/Mass_Deployment). In short words, "R" means that the user cannot mess with the settings, "RW" means that the user might change the setting locally on the phone.

Well the tz here just means that it is related to the time. If the setting for the time server on the PBX is a number, it put the local IP address there (with the port). Otherwise, it puts the setting ntp_host there.

Well, that means the PBX opens a port so that the phones can get the time from the PBX. This is useful in environments where the phones have no internet access and there is no other time server in the LAN. The time comes from the PBX operating system; the OS can itself use e.g. a time server client to get it from another location or just use the hardware clock (hopefully with battery backup).

Hmm. You could assume that there is no region code, so all numbers are either international or local. That could work on inbound. Then to make an outbound call, you could use different dial plan entries and then use the replacement to fix the 0 that is being presented to the carrier: Prio: 10 Pattern: 00* Replacement 00* Prio: 20 Pattern: 0* Replacement 0045* Prio: 30 Pattern: * Replacement * At this point just an idea. Generally speaking, I am a friend of numbers that you would enter in your cell phone as well. This is easy to explain to end users these days. The prefix from the old PBX days is always confusing ("How many 0 do I have to put in to make an international call???").

I guess Mr X wanted to ask you if you could back up your system, load the latest version and check if the problem was solved...

The next version (4.5) will include a list of popular root CA to make this easier. If you upgrade, you first have to delete all root CA before upgrading, so that the new version installs the new certificates.

I think there is a 8.4.34 coming out (at least in beta available). Hopefully this version combines the best of both versions!

Well the "SIP URI" that the IETF proposed a long time ago did not happen (at least not in the ITSP world). Everything is still pretty much telephone numbers, 10 digits in North America. If you want to use a SIP URI (which is possible with snom ONE), you first of all have to set up your DNS with DNS NAPTR and SRV records (I guess you uderstand why SIP URI did not take off). There was a attempt called "ENUM" where calls can come from any IP address. This has a lot of security problems, so by default the PBX disables that feature. I suggest before you start this adventure, use the search-engine-of-your-choice and do some research on ENUM and SIP URI, DNS. You can also include pbxnsip in your search, there are a few texts on ENUM and pbxnsip available from the old days.

Das geht praktisch nur über Plug and Play. Dann einfach im Web-Interface der PBX die Buttons eintragen. Das sollte dann sehr einfach gehen.

Is there any way snom ONE can figure this out? I mean are the numbers somehow looking different to the PBX? I am not the biggest Sangoma expert...

The new release will come with a new license key for snom ONE free anyway. Maybe just give it a try: bWFjOiANCjNwcjogMTANCmFjY291bnRzOiAzMA0KYmFyZ2U6IHRydWUNCmNkcjogdHJ1ZQ0K ZG9tYWluczogMQ0KZXh0ZW5zaW9uczogMTANCmxvd3JhdGU6IGZhbHNlDQpuYW1lOiBzbm9t IE9ORSBmcmVlDQpyYXRlczogdHJ1ZQ0KcmVjb3JkaW5nOiB0cnVlDQpyZWZlcjogdHJ1ZQ0K c2FsdDogMQ0Kc2VjdXJlOiB0cnVlDQpzb2FwOiB0cnVlDQp0b2tlbjogc25vbSBPTkUgZnJl ZQ0KdHlwZTogUFJPDQp1cGdyYWRlOiAwMSAwMSAyMDEzDQp1cmw6IGh0dHBzOi8vdXBkYXRl LnNub20uY29tL3Nub21vbmVmcmVlDQpoYXNoOiBjYzZiMmYyNDAyNzNjY2Q4OTIwNTE2ZWRi YzllZjY2OA0K Plug and play with Polycom will still not work, but I guess that's understandable...

Was this problem solved in the mean time?

Well, the good news is that the important part comes first (41), the rest is not so important. I agree showing the sip scheme is kind of pointless and a waste of valuable display real estate. There is a setting on the phone for that, and if you care you can set it in the provisioning templates (snom_3xx_phone.xml) from the web interface.

It is possible, though not easy. A requirement is that the IP address on the public side does not change. You can configure the NAT router to forward the neccessary ports to the PBX (including RTP), and then use the IP Routing List in the Ports section of the admin settings to have the PBX change the packets that are being sent to the service provider.

I guess you have set the "SNMP Trusted Addresses" on the PBX? Many tools offer simplified configuration for sensors like CPU temperature; because the PBX SNMP is not mainstream you probably have to dig a little bit around in the BPSNMPMon tool to find the screen where you can enter a native OID.

There is a SOAP call "GetRegistrations" which tells you what contacts have been registered for a specific extension. Check out https://wiki.snomone.com/index.php?title=Access_to_the_Database and http://forum.snomone.com/index.php?/topic/4030-get-registered-available-extensions/ for more information. CSTA has IMHO a different focus, this is more like a remote control for the extension.

I guess the message key is programmed to be a Action URL, from a previous automatic provisioning. This is using HTTP, not SIP. What could be is that the HTTP port cannot be reached by the phone. If you can log in to the web interface of the phone, you can check what has been set for MWI.<br><br>The other thing is that 8.4.33 seems to stil have a couple of bugs, so if you can try moving to 8.4.31 or 8.4.34. Make sure that you factory reset the phone, so there is no leftover from previous configurations.

There are still pbxnsip builds available, so you should not loose anything and you should be able to maintain operation and even expand it. If Polycom adds new models, IMHO it is understandable that snom is not very keep on supporting them, at least not with the plug and play.

The trick is to make a backup and then restore it later under a different name.

Well the SIP trace looks actually okay on the trunk side. How stable is your Internet connection? How does the MOS graph look on this trunk? If you get low scores, this looks like there is a problem with the suitability of the Internet access for VoIP calls. If you want, you can also run a Wireshark trace for calls to give you the ultimate answer if the connection is okay or not.