Vodia PBX

It is all in the recordings folder. The files have the name "msg*.wav".

Anything from the service manager? If the PBX initiates the restart, it does restart the whole system...

Plese send an email to support@pbxnsip.com (sorry don't know what the snom email address would be) and indicate what OS you are running.

Yes that can be done. If you don't mind fiddling with raw file in the file system you can do that even per domain. As a stating point, you can go to admin/email/texts and start editing reg_hader and reg_footer to influence the overall design.

Good point, noted. However, you should also be able to get this from the cdre (extension CDR).

In Linux, you can check the syslog for admin login and other important events from the PBX. Also, if you ahve email notifications turned on you should get an email if someone requests a restart.

That makes sense and it is time to put this in. We just need to extend the extension permission by one more option: system administrator.

http://kiwi.pbxnsip.com/index.php/Extension#Registrations explains it, seens the new Wiki does not have this yet...

There used to be a description on the old Wiki http://kiwi.pbxnsip.com/index.php/Inbound_Calls_on_Trunk, seems like the new Wiki is not there on this topic yet.

There can be many reasons according to your description... If you get the phone registered the blacklisting will not be the problem. I would focus on something basic like calling the mailbox to see if the audio path could be established. I guess you have the audio_en (or whatever language you installed) and the audio_moh files installed, otherwise you would experience the "digital silence" experience (the Linux installation process requires this manual installation step). Also you could try to call the mailbox not from behind a router, maybe you have the chance to call on the local link and see if that works.

We changed something in the code and now (with the newer build) it should work. At least it does work now for me, just tested it.

Two things come to my mind. First, just don't use a mailbox! If you have a second mailbox anyway, then it is probably better to stick to this one all the time. The other thing could be to use a static registration, even if it is pointing into the nirvana. This will keep the PBX busy for some time until the request-timeout will kick in, which should be around 32 seconds. This is a little bit dirty solution, but could solve your problem.

It will go immediately to voicemail. If this behavior is not what you want, you can put something on top of the "redirect on not registered" feature for the extension. For example, redirect it to an IVR node that plays back a ringback tone for 20 seconds before it redirects into the mailbox.

If this a SOAP-related question? Then you have to read the DND status from the extension after getting the potential candidates, there is nothing specific for DND. As for getting the numer of registrations, you can use the CountRegistrations SOAP API call: <sns:CountRegistrations> <Domain>test.com</Domain> <User>44</User> </sns:CountRegistrations>

Well, from PBX perspective it looks that "someone" hangs up... A hook switch is that thing that detects when the user puts the handset down. But if it is not related to a specific handset then this should be not the problem. Are you getting emails on disconnect events? The PBX sends out emails (if you set up the admin email account) when the PBX disconnects a call for example because of one-way audio. These emails contain the SIP messages for the call, which should make it easier to find out what is going on. You can test this feature by establishing a regular call and then pull the Ethernet plug out of the phone. If you get those emails, then you should also get emails on other events where the PBX disconnects the call. The other source for trouble that you can check is the trunk. We had cases where the PSTN termination was buggy and the gateway detected a busy tone where there was no busy tone. Maybe there is a similar problem with the provider here. The way to narrow this down is to vary the PSTN termination (e.g. different provider, different gateway). You should also log the SIP messages associated with the IP address of the trunk and write them to a log file, even if it gets very big (make sure you are using the $ in the log file name to have a seperate file for each day). BTW make sure that you dont have the hangup tone detection turned on on the PBX trunk. This could be another reason for trouble.

Well, the PBX received a BYE after 37 seconds: [7] 2010/11/05 13:10:00: SIP Rx udp:10.0.1.21:5060: BYE sip:11@10.0.1.9:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.1.21:5060;branch=z9hG4bK-bae30358 From: "Office" <sip:11@10.0.1.9>;tag=6b78760386b6280ao0 To: "Study" <sip:10@10.0.1.9>;tag=3a2a4e313b Call-ID: 1f329437-b0ed7f66@10.0.1.21 CSeq: 103 BYE Max-Forwards: 70 Authorization: Digest username="11",realm="10.0.1.9",nonce="719cfa3acbaaf7b9c38bb0ce467a6112",uri="sip:11@10.0.1.9:5060",algorithm=MD5,response="7bc669e8becca87f166b785d11fdafbf" User-Agent: Linksys/SPA942-6.1.5(a) Content-Length: 0 I am not sure why the phone would initiate a hangup. It looks very "beautiful" from a signalling perspective. Maybe the hook switch is instable or some other hardware defect causing this issue? Is the problem related to a specific phone?

Right, the account limit should be like 99999 accounts, which should be okay for most cases...

In theory, you should be able to blind transfer that person to 99+ext. The external voicemail mechanism does nothing else than this.

No better dont edit the XML, the PBX may override it any time. It is easier to change the web interface options. Go as admin to the reg_texts.htm page (admin/email/texts) and then edit the reg_access.htm page like this (add the bold line): <select name="blacklist_expires" id="blacklist_expires" class="cCombo"> <option value="60" selected="{ssi rsel blacklist_expires 60}">1 min</option> ... <option value="604800" selected="{ssi rsel blacklist_expires 604800}">7 d</option> <option value="31536000" selected="{ssi rsel blacklist_expires 31536000}">365 d</option> </select>

$ host -t SRV _sip._udp.callcentric.com _sip._udp.callcentric.com has SRV record 20 0 5080 alpha6.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha7.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha8.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha9.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha1.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha2.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha3.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha4.callcentric.com. _sip._udp.callcentric.com has SRV record 20 0 5080 alpha5.callcentric.com. $ for i in 1 2 3 4 5 6 7 8 9; do host alpha$i.callcentric.com; done alpha1.callcentric.com has address 204.11.192.22 alpha2.callcentric.com has address 204.11.192.23 alpha3.callcentric.com has address 204.11.192.31 alpha4.callcentric.com has address 204.11.192.34 alpha5.callcentric.com has address 204.11.192.35 alpha6.callcentric.com has address 204.11.192.36 alpha7.callcentric.com has address 204.11.192.37 alpha8.callcentric.com has address 204.11.192.38 alpha9.callcentric.com has address 204.11.192.39 I would use 204.11.192/24 to play safe.

Okay, go to the domain settings and set the new dial plan as the default dial plan. You are probably still using the old dial plan from that extension.

Yea. Keep in mind that even if this note never shows up anywhere it is still in the system... We have parameter 1..3, by nature also pretty generic fields for each account. Having them available in the web interface should be possible without changing the code. You could even try it out in the admin/email/text pages on your own. I love those changes that don't require code changes.

That information is available in the database and could be displayed. The initial time when the record was created is not available right now, and is more tricky because it can be renewed!

No, no. The blacklisting uses some nice efficient data structures internally. The performance impact of even long lists should be okay. You can also blacklist everything by default (0.0.0.0/0) and only whitelist certain IP addresses or subnets. If you know the IP addresses of your users/customers than that is a real option where you dont have to worry about people scanning your PBX. In this case you also need to whitelist your trunk provider. The black/whitelisting does not support DNS, you you need to look the IP addresses where the service provider might come from.

Thats a good sign. This means that the problem must be somewhere in the trunk/dialplan area. Do you hear "comfort noise" (light hissing sound in the phone)? That would mean that the PBX actually tries to call the destination, but did not get a ringback yet. Did you set up a new dial plan or did you use the default dial plan? In case you set up a new dial plan, make sure that this is either the default domain dial plan (domain settings) or the dial plan for the extension that you are using (extension setting). If it all does not help, check the logging. You might want to increase the log level and even start logging the SIP packets to see how the PBX communicates with the SIP trunk.