Vodia PBX

I would use Wireshark and filter for the IP address of the WIP310. Then it will become obvious why there is no RTP.

The 32047471 is probably not correct. Either enter 032047471 or to make it 100 % clear +3332047471.

I assume the problem is the following: You register the trunk, and the PBX registers the contact xxx20@yyy. Now when the provider wants to send you a call, it sends it to xxx20@yyy, which is absolutely correct and the only way which corresponds to the RFC. Now here comes the tricky question. How can the PBX know which number was called? It cannot be found in the Reqest-URI (which is what the RFC says); instead you'll find it in the To-Header (see http://wiki.snomone.com/index.php?title=Inbounds_Calls). For example, when you use the following pattern, it should take the last two digits from the To-Header and try to route it there, and if it was not found route it to 20: "!([0-9]{2})$!\1!t!20!" (notice the t in between all those exclamation marks which means take the number out of the To-Header URI). ERE are ugly, but flexible and this way it should be possible to have the PBX route the call where it should go.

Hmm. The 820 and 821 models have the same keys and the same functionality, thats why there is no differentiation between them. It should be okay to use the snom_820_custom.xml file to get this job done.

That would be a hack. You could set the snom 320 up in both offices (two identities) and use one identity just to monitor the status in the other domain.

Okay, now you need to extract the destination number from the INVITE. You can see how this works on http://wiki.snomone.com/index.php?title=Inbounds_Calls#How_the_System_Routes_a_Call_to_the_Proper_Extension.

Better dont put those files into the html directory, edit the files in the web interface instead. They override the file-based and built-in templates and that might cause the confusion.

For the softphone market we do have a business model: snom ONE green edition coming up. Connect the softphone you like on the platform you like the most. At least it is a lot easier than trying to beat the vast amount of available soft phones.

We are thinking about using the service flags for that.

The question is not if it is technically doable, the question is if you can make money with it...

The PBX does not perform special checks of the status between calls. The PBX ignored hangup in the hunt group if the hangup comes from an unconnected device from the agent side. This is like the agent pressing the cancel button on an incoming call, the hunt group continues searching other agents that can connect the call. The hunt group also ignores redirection requests from agents (3xx codes). In other words, unless the call is connected the agent cannot cancel or redirect the call.

The PBX does not care if it is VPN, public Internet, private addresses or whatever. The key point is if addresses are routable and from the log above that seems to be the case (no problem). In the example above, you say the PBX is on 192.168.1.60, but the packet is received from 192.168.1.50. Thats why the PBX cannot match the incoming call to a trunk. Simple typo?

Right, you can enter the phone number like this "41 003336612345 00336643321" ("Account number(s)", space between the numbers). This means that the account has the (primary) name 41, and alias names 003336612345 and 00336643321. Then incoming calls can be matched against these names.

Possible reasons are: The phone got blacklisted during the provisioning process, you would see this in the access list. Or the number of allowed HTTP threads is exhaused (increase it). You can see in the PBX that the phone does to connect to port 80 and request the firmware location file (repetition in packet #220), but there is nothing coming back.

Check the permissions (e.g. http://en.wikipedia....tem_permissions) and if the file system is full (e.g. with df, see http://linux.die.net/man/1/df). Don't restart the PBX! Because some file could not be written, the PBX will "clean up" stale links. If you changed e.g. extensions, perform some more changes and hit the save buttons.

One think that strikes out is the number "011-33333". In SIP the "-" is a part of the URI, in other words "011-33333" is not equal to "01133333". That might cause a lot of confusion. The PBX likes to display numbers with "-" in it, but only for display purposes! Internally, the processing goes on without the "-". But when the number comes from a non-human device like the PSTN gateway, then the PBX will take it literally.

If the PSTN gateway supports RTCP, then the score will be already useful. For example, the round trip time can be calculated and the PBX will see how much packet loss it had on it's receiving side. If there is "one-way" RTCP-XR the PBX takes that number and assumes that the other direction performs the same way. This is better than nothing.

Unfortunately, most SIP trunking provider never heared about RTCP-XR or even RTCP. Especially those who don't give too much about QoS...

RIght if the other side does not respond to RTCP, then the MOS is pretty low (1.0 is the minimum value that you can get, not 0.0 as you might think without reading the RFCs...). Anyway, IMHO 1.0 practically means the information is not available and I would not be concerned about quality. If the score is 1.1, I would be concerned

You can look it up at http://www.rfc-editor.org/rfc/rfc6035.txt.

The trunk that you see in the CDR history is probably where the call has been redirected to. Do you have other trunks? You dont have to post them here; just check if they all have the outbound proxy set (or explicity list the IP addresses at the bottom). Also, do you have any warning signs when you list the accounts? Then you might have an account that has no password set, which would also be a security problem.

Check your trunks. If you don't have an outbound proxy set, the PBX will accept calls on such a trunk. This is called "ENUM" and it is hard to tell the difference between an ENUM call and fraud. I would also turn logging to the file system on, so that you can get more information about the caller. There is no backdoor. That will block it, but is very inconvenient. I would try to find the root cause instead.

Okay... Can you try to put a longer number into the ANI field to see if that changes/improves anything?

No snom free also has only ten mailboxes. If you want to have 100, you need snom ONE blue. For 100 mailboxes, still a good deal IMHO and you can redirect calls to cell phones as well (all of those 100 can enter their cell phones and then they become kind of extension as well).

For outgoing calls, you should use the ANI to present the extension's identity. For incoming calls, you can set the alias names for the extension so that the PBX can find the right extension. Redirected calls are a long story as SIP does define how it works (use the "From" header), but most of the ITSP did not get it and use "From" for writing the bill. Sounds nice in the case of redirection, but the call will just not go through ...