Vodia PBX

Thats for the trunk. This is also interesting, but it does not tell you what is going on with your extensions. In the extension settings (Registration), there is a setting "Log Registration Changes", there you can pick "send email to administrator". Then you (the admin) will get an email every time the regsitration changes.

Sorry for the ping pong but can you can turn "Log call messages" on. We need to see the INVITE requests.

That should be okay. However, in order to get the Cisco devices working, you need to put their configuration either on the TFTP server of the PBX or in another TFTP server. In pbxnsip, the PBx was automatically generatng the inormation; now in snom ONE that part is not available any more. But if you google, you will find configuration files for Cisco and can change them so that they also register to snom ONE.

If you are using cheap routers (e.g. DSL routers), there is a chance that this router is screwing up the NAT from time to time or even crash when you have too much ports open on the NAT. I would not be the first time! You can have the PBX send you an email when you loose a registration; I would turn that on (reg_messages.htm, "When a registration status of an extension changes"). If you get a lot of emails you do have a problem with the network. Maybe the first step is to get the registration stable in the LAN and then add more components like a router later.

Sorry, http://wiki.snomone.com/index.php?title=Logging_SIP_Settings shows you how to log SIP packets.

BroadSoft provides SIP technology (www.broadsoft.com), there are many service providers are using their technology. Maybe you service provider is one of them. Looking at the SIP pakcet coming from them will show you if that is that is the case. If you like, please copy & paste it here.

Are they using BroadSoft trunks? We recently found a bug there when BS sends an IP address 0.0.0.0 and asks the PBX to propose a new SDP. Because of the 0.0.0.0 the PBX believes the call is on hold, and that causes issues with the PBX.

Running a PBX on a private IP address is complex topic. You can check http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses, but all in all IMHO the easiest is to run the PBX in a DMZ without NAT or just on public IP.

Is the PBX running behind NAT? Then it would not present the public IP, it would represent it's private IP which is not routable for the service provider.

Sounds like you need a routable (public) IP address to get that service working in a stable way. For outgoing, you might have to check your dial plan again if it is goes to the Gamma trunk.

Right now it is pretty much hard coded. BTW there are many places where dates are being generated. E.g. in the CDR you want a global format, on the web interface you usually want a local format.

SSH runs on port 8722. I guess this is to improve the security of the system by obscurity...

The alternative would be "!44121XXX7([0-9]{3})!\1!u!777!".

If you are okay with star codes, you just set them up on the PBX and dial them.

Well, really hard to say what is the problem here. I would skip it and factory reset the base (from the web interface). The new provisioning should be quick if you are using PnP. The big drawbacks with DECT is that tunneling does not happen on IP level, but must be done on some DECT channels. This makes such features a pain, at least. CatIQ might be a help, but the protocol is not that simple either and it is difficult to keep track on the latest developments there.

That should be okay. Is the m9 in the same LAN like the desktop phone? Any routers in between? This SW should really work flawless. Keep in mind that DECT phones have only 768 KB ROM and typically 64 KB of RAM. This makes it possible to keep them relatively cheap (the handset!) and battery lifetime good.

Port 26 or port 25? AFAIK 25 was for SMTP.

What SW ar you running on the m9? 9.4.12 or later? Then it should work pretty well with the snom ONE. Remember that after upgrading the base, you might also have to updat ethe handset. This works over the air, thats why it is not included in the base SW update. I am a happy every day user, it works well for me. The price seems a little high to me, there should be better deals available... In the cordless world, transfer and park must be done with the star codes. The handset does not have buttons like the snom 360. In my real life, I just physically fork the handset over to where ever I want to transfer the call. Well, if the transfer target is physically in the office.

Well, this a famous problem called "NAT". Most service providers today use a "SBC" (Session Border Controller) to solve it, so that customers dont have to deal with it and all th tricky technical topics and instabilities around it. There is a reason why ACME packet is one of the hottest companies in the VoIP world!

There is a option if those files shoul be generated to the file system or just being logged ("Write PnP generated files" in the PnP section). Maybe it is set to false.

Okay, probably you accessed the PBX with the URL from the m9 from the web browser of the PC. Then you would see that MAC. When you "trust the MAC" in the PnP, the PBX reads out the MAC from the IP table of the host to find out where the request came from. The MAc acts like a token, with a low trust level (that's why there is a flag to control this). Once you start using username and passwords or certificates that contain the token, the MAC layer trust is not needed. I now also dont think that the packet crossed a router; it was probably because the PC did access the PBX directly and the PBX saw the MAC of the PC. The phone switch is a switch, not a router so that also can't be the problem. One more thing that you could check (with Wireshark on the PBX), if the PC has some spyware running trying to steal all traffic from the PC. The RARP attack is one way to relay all traffic through the PC.

I would let the PBX send me an email every time the registration status changes. If you get a lot of emails, there must be something wrong with the network setup of the snom 300.

0019D1 is a MAC from Intel. Is that the PC of the PC running the PBX? All snoms have 000413. If yes, there is probably some routing issue from one interface to another. MAC addresses only change on router level, not on switch level. The m9 should also get provisioned even if it crosses a router. Did you assign the m9 MAC address into an extension on the PBX? Then it should actually verify the certificate from the m9 and ignore what is coming from the interface.

Well actually the default transport protocol is TFTP, so you would have to put the TFTP server port behind the colon if you just want to put the IP address there. Did you change the TFTP port? If you do want to use HTTP, you need to use the form http://192.168.1.63:8080/prov/snom-m9-000413123456.xml.

The PBX has a problem parsing the Call-Info header. You can either downgrade the phone or upgrade the PBX with a fix (we'll supply it shortly--what is your OS?)