Vodia PBX
-
Posts
11,110 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
We will include the email files in the next version.
Check out http://www.pbxnsip.com/download/email_203.tgz and http://www.pbxnsip.com/download/email_203.zip for timebeing.
-
WOW. Respect!
-
We do that on the CS410. But in Windows so far not.
You can buy overhead speakers, e.g. CyberData. Those are very simple to integrate.
-
"Also, from our experience dynamic IP addresses will cause a lot of random instability and problem searching."
SIP is not HTTP...
-
Do you want to write something up for the Wiki?
-
You can use Dialogic cards.
There are rumors that Sangoma also comes out with a SIP-capable software API for their cards, but we have not seen anything working yet.
There are tons of external gateways available in all price categories.
-
I don't think that the Xlite is the problem here.
It would be interesting to see what the IVR answeres in the 200 Ok, especially the SDP. It should indicate what codec it is using as RFC2833.
-
Well, first of all check out http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses and http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems.
Also, from our experience dynamic IP addresses will cause a lot of random instability and problem searching. When the IP address changes you will have "blind spots" where the PBX is not connected to the remote phones. Also, we learned that our ISP likes to do service windows at times when we didn't expect it. Needless to say, that if the ISP does not support QoS routing and/or does not use a session border controller, you will sooner or later end up with choppy audio. Our sad experience is that when an ISP also provides (TDM-based) telephony services, they have zero interest to respect QoS. Just setting expectation levels - you get what you pay for.
-
Overlap dialling and SIP - ouch... We know this problem very well. Cell phones work (the do not do overlap dialling), regular ISTN phones don't get through.
But I believe you can still address the problem by using the whole number and then send it either directly to the extension or to an auto attendant.
-
Is this the first packet that the SPA sends? In T.38 the end point first needs to establish a G711 call and then after the fax tone detection switch to T.38.
-
There was a bug in the SRTP. Make sure that you either turn SRTP off or use version 2.0.3 on pbxnsip and 6.5.9 or higher on snom (see http://www.snom.com/wiki/index.php/Snom360.../Beta_Versions).
-
Well, in most countries is it quite normal that the From header contains something anonymous - typically if the caller does not want to reveal the identity. However in this case the To-header is "anonymous". I don't get the use-case here. Does the caller not want to say which number he wants to talk to?
Maybe you can make the gateway send the whole "DID" number (don't strip the prefix) - then we are able to route it somehow. Might be a kind of workaround to get it working with the current version, then later we might have to think about routing calls without extension numbers.
-
In the end, only a PCAP trace (either from the phone or from the PBX) helps. snom phones support making PCAP traces right from the phone. Then we see if it gets media at all, and we can see if someone in the middle is blocking the traffic. There are also other possible problems like wrong SRTP MAC, which also result in one-way audio. The PCAP trace will help to hunt them down.
A very simple way is also looking at the statistics in the BYE packets. Both the PBX and the snom phones sends a Rx/Tx statistics. You can match them and see if there must have been a significant packet loss. That would help to find the problem even without having PCAP traces.
If we find the problem, we can later say if it was "trivial" or not :-))
-
One thing that you can check is if the route on the host is preferring the public interface. In Windows, the default is to use the fastest interface, no matter if it is using a public or private IP address.
Also, you need to make sure that the port forwarding does not introduce NAT. The firewall should transparently forward the packets to the public interface.
-
Use the pattern E for this purpose (see http://wiki.pbxnsip.com/index.php/IVR_Node).
For example: Put "!E!100!" into the DTMF match list to route a call to 100 after the end of the file has been reached.
-
Ehhhh....
I would say the PSTN gateway should know which number is being called. There must be something in the gateway that should be configured in order to do this. There is nothing like an "anonymous destination"...
Alternatively, you can try the pattern "!(.*)!\1!t! 25" (see the space between the two party of this pattern). Then the PBX should route the call to 25 if the pattern resolution does not come up with a match.
-
Incoming calls on Telco1:
Set in the "Extension" field of the trunk: "!(.*)!\1!u!25!" (see http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk). If your operator sends the extension in the To-header, choose "!(.*)!\1!t!25!".
Outgoing calls:
Create two dial plans. Make Plan1 your default dial plan for the domain (http://wiki.pbxnsip.com/index.php/Domain_Settings#Default_Dial_Plan), and assign Plan2 to the fax extension. Both plans just use the star as the pattern (no replacement) and route to the Telco1 and Telco2, respectively (see http://wiki.pbxnsip.com/index.php/Dial_Plan).
If you want, you can use a pattern like 0* as a prefix for the dial plan. However, my suggestion is not to use any prefixes. Just make the numbers diallable as they are - on a cell phone you also don't use a prefix to dial a number. That makes the address book much easier and you can call back missed calls.
-
No, my understanding is that PBXnSIP does not *have* STUN so I don't have a STUN server to use.
The trunk may use STUN to allocate a public IP address. This is very unreliable, therefore we strongly recommend not to use this feature. However, there are stupid marketing people who believe that if that feature does not show up in the datasheet the product is inferior. We all know that this is bulls*** and STUN is just creating huge support problems.
When an extension registers, it should just point the outbound proxy towards the PBX. On the snom phones, you can use even use TCP (or TLS) transport layer. Just use an outbound proxy like "sip:2.3.4.5:5060;transport=tcp". Then the NAT problems should also disappear, because even crappy routers support TCP connections. Of course, do not use STUN on the phones as well.
-
I'm not sure that I understand the part about mailbox readout. Can you clarify?
When a user receives a new voicemail, the PBX calls the users' cell phone and reads out the new message.
Further, I think that the PBX's dependece on CID to support for mobile caller's access to the system is a big flaw.Of course Caller-ID is not secure. That's why you must enter a PIN e.g. if you want to go to "your" mailbox or place an outbound call. A good reason to choose a different PIN than just "1234".
-
It is really hard to say. The numbers in http://wiki.pbxnsip.com/index.php/Hardware_Requirements are really just a "rule of thumb". It depends on the packet length, the codec, the I/O subsystem performance, OS-related jobs like packet routing (ipchains & Co), cache size, usage of features like call barge in or call recording, and other factors. Also the performance depends a little bit on the used version, as we constantly try to improve the performance.
Fortunately, the PBX has a feature that constantly measures the performance and then stops accepting new calls when it is getting into a dangerous zone.
-
Hmmm... I think it is sometimes hard to say if something is a bug or just a configuration problem. And even if it is a bug, it is probably still better to post it in the right forum, so that other users experiencing the same problem can search that forum first. If we make a general "bug" forum then it will be hard to find something there "IMHO".
-
Well, there are simplified dial plan entries available that usually do the job. I don't remember the last time when I needed regular expressions to get something done in a dial plan.
-
Well, can't reproduce it here. But we changed something yesterday in the OOB DTMF processing, so maybe the problem went away by itself... Try pbxctrl-2.0.4.1749.exe is you can.
-
First of all, if you want to turn the feature completely off, change the setting "camp_enabled" in the pbx.xml file.
The camp on is only offered to internal extensions and to cell phone callers (must be somewhere on the list of the cell phones). The number must be dialable anyway, otherwise also other features like mailbox readout are not working either.
I strongly recommend that you have a "default" dialplan that works without any prefixes. It is okay if you have special prefixes for special routes, but you should have always a route that works on standard numbers. For example, you need that feature for callback (*69) anyway.
forward all calls to cell phone not working
in General Setup
Posted
Right. When you call a hunt group the PBX will not call the cell phone. We believe that this would cause a major chaos in most installations. Only direct calls to the extensions make the cell phone ring.