Vodia PBX

In Linux you would use something like "awk '{if($4="123")print $0}' < cdr.csv" and you would be all set already...

Klingt nach einem Problem mit dem Dial Plan (auf Deutsch Rufschema). Ich würde mal den Log-Level hoch setzen und sehen wie das System den Call routed.

You mean right now you are receiving the list in HTML format and you want it in CSV instead (comma sepersated values)? Right now it is pretty much hard coded in HTML; you can copy & paste it into Excel and then save it a CSV. No tsur eif you can automate that step easily. The alternative could be to save the CDR in CSV on the system level and then filter out those messages which are for the ACD.

Did you ever try turning "Allow calling accounts on the PBX" on? A service flag is nothing than a account on the PBX...

If the trunk has no outbound proxy set and no "Explicitly list addresses for inbound traffic", then it must assume that the traffic may come from anywhere (e.g. ENUM traffic). If you let that trunk for example use a DISA feature (like you are calling from a cell phone and want to place an outbound call), you have a security problem. Bottom line: Always specify the outbound proxy.

There are two important steps here. The first one is the provisioning of the phone. There it is important that the PBX knows that the phone is in the paging group. This is controlled by the paging group of the PBX, the phone must be list of extensions there. Then when the paging happens, the phone must be running the right firmware. I am not sure about 8.4.31 (there is 8.4.32 out now, see http://wiki.snom.com/Firmware/V8/Release_Notes/8.4.32). There was obviously a critical bug with the paging, so you might have the phone to use 8.4.32 (essentially also a provisioning setting).

I agree with what Steve says. As Steve said, the MAC are only for PnP. Other devices can register if they know the password. MAC are actually not very safe, it is easy to spoof MAC addresses. 8 digits are 100 million combinations, that is actually not too much these days. It would take a few seconds to try all combinations out. Including alphanumeric dramatically increases the number of possible combinations. Or you go for 12 digits, thats at least a trillion combinations, which would take a couple of days to try the combinations out. For good for "top secret", but for regular use it should be okay. IMHO that does not make a big difference. if you have a good password you control pretty well who registers. Limiting the number of registrations is primarily for hosted PBX providers that want to avoid abuse of the extension as a kind of hunt group. You can blacklist everyone else (in IPv4) with 0.0.0.0/0. If you have a envronment where you know all IP addresses, IMHO whitelisting is actually not such a bad idea, considering the stuff going on with friendly scanner and so on. At least that keeps a lot of problems away, and then even passwords with 8 digit numbers can be okay. Well, version 4 has this automatic blacklisting feature and this IMHO keeps tings like sipvicous pretty much under control. We have seen some successful hacks, but there were all because of weak passwords (account name = 100, password = 100) or trunks configured for accepting any traffic and send it out on other trunks without any kind of authentication. When the PBX blacklists an address, it sends an email, and I would st up an email filer that really highlights those attacks. I can sleep well with the automatic blacklisting.

The name of the file is page_begin.wav and page_end.wav and they need to be in the audio_moh directory, as they are supposed to be language independent. Does the standard MoH tarball not contain those files?!

The core question if you want to use the HQ PBX as a pure router. Check if a SIP proxy would do a better job, and especially stay out of the media path to minimize the delay. And this would also give you the possibility to route calls internally for local PSTN breakouts. If you decide to keep the setup, you should try to avoid trunk-to-trunk calls, it is easier to use trunk to extension calls and extension to trunk calls. The trick is to register the branch offices to the HQ: On the branch office you use a trunk, and on the HQ they appear as a extension. Then for incoming calls, you can send the calls to the right branch office by assigning multiple DID numbers (alias names) for the HQ extension. There is a special flag in the domain that tells the PBX not to change the from/to-headers, so that in the branch office you can still use the To-header for routing the call to the final destination. The other alternative would be to forget about the two-tier setup and register all office directly with the service provider. Internal calls can be done through the public network essentially by using the diaplan for the short numbers and replacing them with the right, global routable telephone numbers (e.g. pattern: 55xxx replacement 0203234343*). This setup would work better if the telephone costs for the internal calls are not an issue.

Hmm. I hope we dont have an escaping problem here (always a backdoor for all kinds of exploits). But it seems more like an "over-escaping" problem, which is not a exploit problem but a readability problem. Where exactly is the log? In the web interface?

Oh, I think the version that you use there had a bug with the CSeq numbers. You should try to upgrade to the latest release, which is 4.2.1.4025.

I know someone who uses VMware with great success; but probably also Hyper-V (Windows world) works fine. I dont know the others. MAC is a problem. During the failover it might work for some time, until the next license checkpoint where the PBX would say "ooppsss". I would go for IP-based or just a snom ONE blue/yellow.

Did you also assign the dial plan to the domain and/or to the extension?

Maybe wait for Android 4.0? Not sure how much will change between the versions.

In theory the phones should display anything that is UTF-8; however it guess it depends on the model (e.g. don't expect too much on snom 300).

Das sollte normalerweise gehen wenn die Durchwahl "0" angelegt wird, z.B. als Rufgruppe. Wenn das INVITE vom Gateway mit "sip:0@domain" ankommt, sollte die PBX in der Lage sein, die entsprechende Durchwahl zu finden. Ein bekanntes Problem mit dem PSTN ist das das Gateways selbst wissen muss, ob die Nummer komplett ist oder nicht. Bei ISDN wird das speziell signalisiert; es macht z.B. einen Unterschied ob man auf einem ISDN-Telefon die Nummern langsam nach und nach eintippt oder auf Wahlwiederholung drückt.

Can you include the REGISTER request from the PBX to the server, and the answer? 400 Bad Request sounds strange.

Not sure if the article made it into the new Wiki, but the old one had some information on this topic: http://kiwi.pbxnsip.com/index.php/Linking_External_Application_Server_to_an_IVR_Node. As far as I can see, you cannot change the From or To header at this point. But I dont think it would be too hard to add that functionality.

No, you can also set up the dial plan after the extension, but obviously you need to assign it either on domain level or on extension level.

Well I guess the problem is not callcentric (at least at this point), it is that user 1001 does not have a dial plan assigned. See the last line of the last screen shot.

Probably a problem with the presentation of the caller-ID. Try to change the caller-ID from RFC3325 to "No indication". This is because there are still so many service providers that believe there is a single handset connected to the trunk and they get confused if this is not the case.

Interesting thought if the device can be used from a regular softphone. This is something that we could investigate.

There is a old link for callcentric here: http://kiwi.pbxnsip.com/index.php/Callcentric, it is a little outdated I believe, but probably still useful. You probably have to change the remote party indication, see http://wiki.snomone.com/index.php?title=SIP_Registrations (item #29).

This time it's me starting a topic. Did anybody try the Android 2.3 with the snom ONE. Android 2.3 has a new SIP support, and "in theory" it should work fine. However it would be interesting to hear if anybody ever tried that out.

I would use names that correspond to the function key names (e.g. 1, 2, 3 and so on), and the parameter would just be the name of the extension that you want to monitor (e.g. 48).