Vodia PBX

Well, ask you service provider how he wants the original caller-ID presented. IMHO it should be in the "From" header, but that is causing a lot of trouble with service providers that use this fiels for writing the bill. Unfortunately, this area has not been specified well in SIP and every service provider does it differently...

Why don't you use the "press 1 to accept the call" for the cell phones? in this case, don't put PSTN numbers into the hunt group, just the extensions. Then check that hunt groups may also call the extension's cell phone and tell the PBX to wait for the "1" confirmation tone from the cell phone. All set, even if the call goes to the cell phones mailbox it will still for connect such a call.

Well, we are still learning about the MOS stuff... There is already a flag in the CDR emails with an "Alert: true" that shows if the MOS was below a certain value. But I believe it is relatively easy to define an email filter that puts those emails into a special folder.

That is probably the problem. Not sure why you get "for <empty> not available". Are you using an email proxy or something? If it is not too difficult, can you get a PCAP trace so we can take a look what is going on there?

This is what I am using: The settings in admin section: And the certificates. The certificate is shown in the post above:

The PBX knows two types for calls: Objects and Legs. The call license counts objects while other features may look at the legs. So 5 calls in the license should be sufficient.

If you can make outbound calls then that's a pretty good sign already... Can you for example also call *97 (the mailbox)? Points to check: By default, the permissions should allow that anyone can call anyone. However, check if you see "true" or "false" in the permissions; that might cause grief. In version 4, there is no more true/false, now the permissions list the extensions.

There are definitevely people who got this working. Maybe someone can post the sip.conf for Asterisk that makes the magic happen...

Right, the service flags can come to rescue here, especially if there are only few numbers to be programmed. If snom ever opens a university, you got your PhD already

Well then you should use something like "xxx7335300|7335300"? Also, make sure that you specify the country code so that 17177335300 (user input) gets translated into 7177335300.

Seems like the Asterisk now accepts the call; however there must be something on the Asterisk that denies the call. From the PBX perspective, it looks "beautiful" now... Yes also gateway trunks can answer challenges!

Oh, now I get it. The call gets challenged on the trunk side, and the PBX does not answer it. Did you provide a username and a password to the trunk that is sending the INVITE out? Otherwise the PBX cannot answer the challenge. You should see something like this in the log "Answer challenge with username xxx" on log level 8 (SIP).

Well, the PBX does not treat the incoming INVITE above as a trunk call. It cannot find it in the 98 trunks and therefore it challenges it. So the snom also does not respond with another INVITE?! This would be very strange. Blacklisting was not in version 3, we can exclude that. So from a PBX perspective, the PBX says: Okay, extension you want to call a number? Authenticate first, please. And that's the end of the conversation...

That is a known problem with the phone firmware. The PBX sends the SOAP ForwardingEvent event with the forwardingType "forwardBusy"; however the phone obviously treats all formwarding events the same.

Whow 98 trunks is impressive! But that's not the problem here. Also, it seems you are using STUN on the X-lite. Don't do that, this is just another source of trouble (symmetrical NAT). The PBX SBC fixes the problem without the STUN hack. But thats also not the problem here! What is a problem is that obviously the X-lite does not try again to send the INVITE. Are you sure you have a passwort set there? And the right one?

I would use host desking then. Let 771 "hot desk" on the different people, if those people have the PIN for the 771 account they can easily grab the calls from this extension. Outbound calls will appear as 771 as well, not sure if thats a feature.

If you can make it to the other's person's mailbox, you can dial star codes from there. The other possiblity is of course to use the web interface, which also requires that you know the web password. Whats the exact use case? Is it assistant/boss management?

xxx7335300 should do the job (if you are using country code 1) or 7177335300|7177338001|7177336700

Whow, so that means you need a new firmware for the gateway? Or was is a Patton config option?

Hard to say. Can you just enter "route print" in the CMD sell (Windows) and we can see if the routing is okay? If you have public IP addresses there which you don't want to expose, just replace them with 23.34.45.56 or something like that...

The next version has also stats per trunk and per extension. That makes it a lot easier to see where the problem exactly is.

You can share the mailbox. There is a setting called "Allow Access for Extensions" in the mailbox setting for an account.

If the PBX puts the public address in the SIP packet although it is sent in the LAN, then that is not okay. You will have the "hairpinning NAT" problem. You can fix this by changing the route on the server, that's why I was asking what the route on the server looks like.

Oh sorry, use this (the tftp was missing): <file url="{https-url tftp}/snom_320_custom.xml" />

Strange. You never know what kind of libraries are sucked in, obviously... Anyway, good to know!