Vodia PBX

Usually Ethernet runs only 100 meters AFAIK.

Well, it means which extension has the permission to see (for example, on the LED button) what calls this extension has. For example, does a regualer employee has the permission to see the calls of the boss? Probably not. So the boss would put something there like only the extension of the secretary "100" if that is the secretary's extension.

Eh... Multiple area codes per domain? Then you must leave the area code field empty; and that also means you loose the value of that field. You can strip the last seven digits out of the Request-URI or To-header of the request in the trunk. For example, when you put something like "!([0-9]{7}$)!\1" into the setting "Send call to extension" of the trunk, then the other digits are ignored on inbound calls. Check the XML files in the user_alias directory if they have the right alias name. It will work if you don't use the country code; it might also work if you don't put in an area code while creating new accounts.

You can put * into the extensions that cannot be dialled; then the PBX stays silent until a timeout and says this extension number does not exist. IMHO that is absolutely reasonable. The timeout is neccessary because customers don't want "directory attacks" where callers try to find out what extensions exist on the PBX. Sorry, but pound has the meaning of "enter, confirm". If we allow that this becomes a direct destination, this will screw a lot of stuff up; and I believe that this would make it confusing the the caller...

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).