I screwed up

[Andrew D Kirch]

First off I'm going to start by saying I screwed up... big time. I should have checked to make sure e-mail was routing correctly out of PBXnSIP after I removed an interface from the box. I'm not lazy, I just forgot. PBXnSIP could have helped me... there could have been a diagnostics page noting that either an hourly (once a minute even) automated test showed that hey, PBXnSIP can't get to your mail server, or your trunk has come unregistered, or something else has gone a bit wrong, such that since I'm unaware of it I'm going to get embarassed later.

 

Also, when PBXnSIP is set up to send voicemail via e-mail and not retain a local copy, should that mail be non-deliverable PBXnSIP loses it. Yesterday my boss lost 48 hours worth of voicemail, and this is not my fault. PBXnSIP needs to ensure that data is retained. It needs to ensure that no matter what's broken it can communicate this to the administrator via a notification e-mail or via some sort of status screen in the PBXnSIP interface. I should be able to go to one page and see how many extensions are configured, and how many are registered, the success or failure or the last several calls out a trunk etc. Really the Status page needs to be expanded from very basic information in the administrator view to being much more extensive. I need to know the health of the system if I'm going to support it.

[Vodia PBX]

Would it be a solution to write the non-deliverable email to the file system?

 

Also, we could add a counter to the SNMP part that lists how many emails were delivered successfully and how many were declined.

[Andrew D Kirch]

Would it be a solution to write the non-deliverable email to the file system?

 

Also, we could add a counter to the SNMP part that lists how many emails were delivered successfully and how many were declined.

I think that both of these would be good, also a warning in the status tab that there is mail in the outbound queue (which should never happen). PBXnSIP should make any problem the system is experiencing as transparent as possible. In places where things can break (which may or may not be the PBX's fault there should be a way to notify the admin)

[Vodia PBX]

Okay, in the next version there are three more SNMP sensors: # of successful sent emails, # of attempts and status (0 = good, 1 = last one failed). Then the SNMP tool can send out SMS, EMails (!) or whatever needs to be done to alarm the administrator.

 

Also, we will have several attempts to deliver the email - up to one hour. I am a little bit concerned that there could be a lot of emails piling up and eating the memory. But the alternative would be loosing a lot of emails, which is also not very appealing.

[joeh]

Also, we will have several attempts to deliver the email - up to one hour. I am a little bit concerned that there could be a lot of emails piling up and eating the memory. But the alternative would be loosing a lot of emails, which is also not very appealing.

 

Could you not emulate the SMTP server\agent model whereby a seperate process or thread polls a directory for queued messages. That way, the PBXnSIP process simply drops an EML or whatever in a spool directory - while a seperate process sends them (you could use the native IIS SMTP server on Windows) - that way, if there's files in the directory, they're not being sent.

[Vodia PBX]

That is a very good idea! I think this way, we can keep a lot of messages and even after a restart the PBX will be able to deliver emails.