Vodia PBX

Seems that some switched have a problem if the OOB DTMF codec is not the same as they propose. There is a fix available in head; maybe you can get a build (ask Pradeep) and see if that fixes the problem.

Seems that some switched have a problem if the OOB DTMF codec is not the same as they propose. There is a fix available in head; maybe you can get a build (ask Pradeep) and see if that fixes the problem.

Well, you can press any key... * is to stop the annoucement, and 0-9 just starts with the entering on the PIN. Maybe it would make sense that after entering the wrong PIN, the mailbox goes back annoucing the mailbox, instead of asking for the PIN again. Maybe we should just add an option that disables the * function. I don't know, but IMHO the PBX should react to any kind of user input. If there is a use case of someone entering the AA, then pressing just one key and the PSTN gateway doe snot detect ths hangup signal, then we are talking about a case that needs to be addressed. Maybe we should make our life easier and just have a SOAP request that reports ANY kind of input, complete or not and wait for the answer from the SOAP server if the audio should go on or not (and maybe what audio file to play).

Try using the "From-based routing match list", just match anything "!(.*)!\1!".

First of all, all that can only work if you enter the area code in the domain. I assume that has been done. I believe the JavaScript is currently too dumb to perform this job. But internally the number should be stored in the right format (check the xml file in the extensions directory, check the last one written). I just checked it and it did it this way.

I would try something external; sending something local will not be visible on the usual network interface as most OS treat the loopback interface seperately. If you already have Wireshark on the system it will be easy to see if the PBX does something. Also check the log messages. You should see that the PBX tries to send something out.

I agree. The CS410 is a little bit picky when it comes to signal quality. Cheap phones seem to be better. We had a case where the amplifier really made a difference.

Well, how would you let the user log into his mailbox, for example when calling from a PSTN line into his mailbox? There needs to be a way to stop the annoucement and ask for the PIN authorization. You mean when the IVR node did not consume the extra input? The timeout is used to deal with callers that don't have DTMF (grandma telephones). When the user presses something, the timeout gets a lot longer, as there was a "sign of life". The user can always press star to correct the input and start all over again. Yea, for pure annoucements that can be annoying. The PBX pay attention to user input, even if it may not do so in certain situations. The workaround is to use the input and move on to the next IVR node, just to avoid the annoyance. There is a setting for this on the domain level, just above the camp on flag. If has the meaningful name "Mailbox Explanation Prompt".

Did you try to assign the alias 01144xxx to the account? Then the account should have right name. If you set the trunk up properly (regardning number interpretation), then it should work.

Sounds like a problem with the dial plan. Can you attach the dial plan here (text form is fine)?

That's the interesting part. So the FXO gateway has the simple impression the line starts ringing, then it stops ringing and starts ringing again. The caller-ID is transported between the NO_RING and the RING. There is simply nothing, no caller-ID. I guess in order to trouble shoot this problem we need to amplify the line or get some measurement. We already had cases there the line volume was too low, and regular PSTN phones were able to read the caller-ID. Maybe we have the same situation here as well. There are cheap line amplifiers available, that's why that would be my first choice. The second option is to employ a tool that measures the line. I am not sure if a digital oscilloscope can do to that job. But we need to see what is going on on the line between those two rings.

Sorry, forgot to mention that: check if the sipfxo executable has the "x" permission. Use: cd /pbx chmod a+rx sipfxo

If it is always the same number, you could black list it. Otherwise the only thing I can think of is to screen all calls (user must say name then press enter). The solution with the IVR node does not sound like a solution to me; way too complicated. But it could be a good idea to accept the "F" as a "DTMF" tone also in the agent group. Though this will be a 4.0 feature.

What version are you running? 3.3.1.3177 should be doing this. You can also try the "BLF" mode, just to see if anything changes. There was a problem history when you changed names in the domain because that could break the links in the button definition; however that should also be fixed in 3.3.1.3177. Maybe you need to hit the save button again on the button web page to update all links.

Even if you have one number that is rolling over, the carrier has a DID number assigned to each of the FXO lines. You can put these numbers in (they are sometimes visible when you place outbound calls, depending on your carrier uses them). I am not sure if the Patton has a problem if you assign the same number to all lines. That might also be worth a shot. Some carriers signal not only the Caller-ID also the called number. Maybe that is a problem here and we have a kind of "interop" problem on the FXO side. Though I would give this only a low probability.

Yea, this is a known problem. Because of this, we introduced the domain password. I am not sure what the status on this subject is right now; but we have another issue with the phones... If the user decides to factory reset the phone then all those nice parameters are also gone. We also need a solution for this.

I wish we had wireshark for FXO. The only thing we can do is try to nail the problem down with a couple of gateway builds that give us more logging information (will probably take a few loops). If you can, please load a special build from http://pbxnsip.com/protect/sipfxo-cid-1, and load it into the /pbx directory of the PBX (e.g. using psftp.exe), move the old sipfxo away (e.g. mv sipfxo sipfxo.old.1), then rename sipfxo-cid-1 to sipfxo and restart the box. There should be more logging available that tells us where it sets the caller-ID to Anonymous.

I would really try to nail it down at the To-header that leaves the gateway. There is no way the gateway can have a To-header "anonymous" in the PSTN world (in the SIP world, it would be possible). Maybe you just need to assign a DID number to a port and you accidentially forgot it. And the gateway right now just falls back to "anonymous" because it has nothing better.

At the beginning of the trace there is a packet received by the PBX from 192.168.10.240 where the To is already set to "anonymous". The PBX just "happily" passes that on. Check the gateway, maybe there is the DID number setup missing or somehow screwed up... In the telecom world, a "anonymous" destination is not possible yet! I want to call you, but I don't want to let you know which number I called .

I would make a Wireshark trace and try to find out when the SIP and RTP packets arrive on the PBX. Maybe the service provider is a little bit slow. BTW this is the reason why the PBX establishes the media path already during the ringback phase. When the media session needs to be set up after the user picks up the phone, there is always an additional delay which might eat the first "hello". But one second is really too long, and there must be something else wrong.

Go to the domain settings, at the bottom you can select the dial plan that should be provisioned (if available for the phone type).

Did you previously provision a dialplan through PnP? If you turn that off later, then the phone will "stick" to the old plan. The only way to get it out of the phone is to either provision another plan or to factory-reset the phone.

Paging is getting into the focus. We are already setting our office up like a typical shop with background music (the whole day) and messages in between. Currently that must be done locally on the device itself.

The first service flag one corresponds to the first one number, 2nd to 2nd and so on. The PBX takes the first "active" service flag and moves only on if the flag is not set. It is not very obvious, agreed! http://wiki.pbxnsip.com/index.php/Auto_Attendant has something on the night service, just one sentence , but there is also an example.

Eh - you are right. button_speed_on_idle is the magic setting for this...