Vodia PBX
-
Posts
11,131 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
What would be the best solution to get PNP working again?
If you changed your pnp.xml file, check the pnp file in this post for changes.
The pnp had to be updated because it was in many cases too easy to get a configuration from any web browser in the LAN or even the WAN.
I know this is a pain for many people who had their own pnp.xml file.
Of course our intention is that there is no need to have any changes in pnp any more.
-
is this possible with PBXnSip?
At the moment: No.
The good news is that we are able to have several prompts, so we need to work only on the assignment of events to prompts.
Something we should consider for the next major release.
-
We made some setup changes to our installation and can't work out why we now have this issue. When we put a call that comes down a trunk from our ITSP it gets disconnected. We can put internal calls on hold fine.
The call gets disconnected immediately or after a timeout? Sounds like a SIP problem on the trunk side... Can you filter the SIP packets to the IP address of the trunk and attach them here?
-
I have a www.didx.net account and they send the call via sip to and extension or to my PBXnSIP so it is seen a a normal inbound call.
The call will be like this: Did Number 1567123456
Ring To 511@209.251.xxx.xxx my public IP address.
You need to have a public IP address to get this working. Set the country code in your domain to "1". Then create a trunk and set the following:
- Only inbound traffic
- No outbound proxy
- Global trunk
- If you have a DNS name, use that instead of the IP address and put it into the domain (otherwise just give the IP address a try)
Then assign the names "511 567123456" as names for the extension/auto attendant.
Give it a try. Set log level to 8 and see if the PBX receives any traffic.
- Only inbound traffic
-
I just set up a set line with callcentric. if I use my x-lite softphone it works fine. However I created the trunk in PBXnSIP to register and it fails with the following error message:
8] 2009/03/18 15:36:00: Trunk 4 (callcentric) has outbound proxy udp:204.11.192.23:5080 udp:204.11.192.35:5060 udp:204.11.192.37:5080
[5] 2009/03/18 15:36:00: Registration on trunk 4 (callcentric) failed. Retry in 60 seconds
What did you put into the outbound proxy, domain, username, account, password? Can you get a REGISTER message from the log?
-
0219185300|copy |3|00|transport error buffer: The requested URL returned error: 401.
That looks like a username/password mismatch to me. Make sure that the username is in the format user@domain and the password is really really correct.
-
I am not getting ringing on incoming calls to the pbx so someone calling in will think the system is dead. I have upgraded to my present level so the past files are under pbxnsip and pbxnsip3. What settings could cause this disturbance?
Is that the same problem as in http://forum.pbxnsip.com/index.php?showtopic=2282?
-
Despite the file being under audio_de callers are not hearing a ringing tone when calling in. What am I to do?
Check if the file audio_de/ringback.wav is there.
Some service providers are using software that is not able to deal with media when the SIP call is not connected yet. On the trunk there is a settings called "Ringback": try chaning it to "Message 180".
-
It is still in BETA fase, right??
It is not under "software download"
Yea... Hopefully we can release it soon. Testing testing testing!
-
works!!!
How do I make PnP with 820 ??
I can see it do not work with the 3xx series PnP
If you use the 3.3 version of the PBX (see the annoucement forum) then PnP should also work.
-
Checked that we have a PNP file defined in /html/pnp.xml and we do??
PBXNSIP: [8] 2009/03/17 16:06:20: Could not identify phone vendor for MAC 0004F20600FC
Remove the pnp.xml file or merge it with the attached one.
-
I am using a SNOM820 - it worked PERFECT yesterday
But today people can not hear me???
I have found out, that if I press: "HOLD" and then "HOLD" again, I have to-way audio.
Other phones work perfect. It is only this one that is causing problems....
Upgrade to 8.1.3.
-
Do you have any experience with placing pbxnsip behind any of the well known commercially available and/or open source session border controllers?
And can you share your experiences with us? how did it go? what works what does not work?
We know a couple of SBC; for example the people at ACME packet know pretty well what they are doing.
The PBX comes with it's own built in "Mini-SBC", which is not exactly what e.g. the SBC from ACME packet is doing. The SBC that are on the market usually address the needs of a typical carrier. Essentially that is NAT traversal for a large number of subscribers, topology hiding, billing (policy enforcement). Essentially the SBC gives subscribes "dial tone" on a SIP trunk. Which is a great thing!
The PBX "Mini-SBC" is pure software and not as scalable as a real (mostly hardware-based SBC). It scales for the registrations that you have on that particular PBX, something around 500-1000 extensions depending on CPU and overall load with calls and so on. The Mini-SBC does not deal with billing; but it cares about keeping the media session alive. That's when a call gets disconnected because the PBX does not receive any media (the famous "one-way audio timeout").
One problem with the carrier-grade SBC is feature transparency. More and more phones do not only use SIP; they also use HTTP and HTTPS to talk to the address book, show what calls are availble for pickup (AJAX and PAC), and maybe one day do stuff like XMPP. I would expect a lot of problems with the SBC and non-standard events on SIP. Maybe REFER works, but dialog-state, check-sync and whatever extensions we are using to provide the features that customers expect from a PBX today might be a headache and we need to explain and justify everything to the SBC vendor.
IMHO the PBX belongs from a logical point of view in front of the SBC. The carrier should have a core that deals with the billing on trunks; the PBX acts like a CPE-PBX; it just happens to be located in the colocation to that the customer does not have to run it on his on power circuit.
I'm somewhat familiar with the process of using OpenSER as an SBC and placing asterisk & other serversbehind it and doing all of the nat traversal/call translations etc in the SBC section of the network.
I'm curious of your thoughts toward eventually employing this type of approach with PBXnsip versus having
50+ pbxnsip servers directly on public IP addresses where pbxnsip is handling virtually all of the NAT and call
routing/translations.
If you want to run 50 PBX you need a SIP proxy, and SER is a good and obvious choice here. If you are running two or three, you can fix a lot of the routing problems with the dial plan. But when you have a farm then the dial plans get so chaotic that you need a central routing instance.
Also, billing is a major issue. The CDR that the PBX generates is not what you want to bill! Customers want to see the CDR for the trunks, and the SER is in the best position to generate CDR for this. You probably need a professional billing software, and pbxnsip is more than happy if the billing takes place on the SER.
Many (most?) of the clients that we have actually run the PBX on a public IP address. And fortunately most of the clients are savvy enough to close ports like NFS, FTP, and who-knows what ports on the server. The case of TCP SYN attack is tricky; In order to prevent this a regular firewall can make sure that the PBX does not get overloaded with these packets. If you clients have a fixed IP address, you can also white-list them on the PBX, so that all other packets get rejected and the PBX is invisible to the rest of the Internet.
Running multiple PBX instances also give you some kind of "no single point of failure". The PBX is supposed to never crash and we take that pretty serious. But if there should be something going wrong, maybe even a hardware failure, then the damage is limited to 1/50 servers = 2 %. Those customers will not be pleased, but the other 98 % will not even notice.
Do you think this approach makes sense? and do you think it would be relatively 'plug -n- play'?Or do you think we'd have a HUGE interrop/development task on our hands before it would work.
Have you ever been through this interrop process with any SBC product?
My thought today would be to put 10-50 pbxnsip servers behind OpenSER and have OpenSER handle
all of the NAT traversal/internal network 'topology hinding' features and place the pnxnsip servers on
private non routable IP space behind OpenSER.. yet still maintain and have ALL of the pbxnsip
features be able to continue to work behind OpenSER. features like BLF intercom IM really all pbxnsip features
that we have today... Do you think they will work behind an SBC like OpenSER? or do you think they
would all break due to interrop issues with an SBC, where pbxnsip no longer has total control of the
public Internet Interface?
Thank you very much for your time and your thoughts!!
I am currently working with OpenSER and will be steadily becoming much more familiar with all the ins & outs
of this software as we move on.
I've also been working on a daily basis with the Stratus ENTICE Softswitch/SBC for about 3 years now.
If you already have a SBC than that is a good start. If you already have customers that use a "soft phone" with your service, then that's even better. Then you can keep things like they are, and connect the PBX like you would connect a soft phone to your SIP trunking service. I know one case very well where the carrier already had a SIP trunking product and just put the PBX in front of it. That approach made a lot of sense. The PBX service is a true value-add to his existing portfolio.
We got a good exposure with SBC - from the "customers" side. We only hear from customers when the carrier does not use a SBC (the cases when the carrier just says "get a public IP or use STUN and try a couple of DSL routers out until it works"). The interop nightmare known from SIP should not happen when a SBC is used! That what SBC are good for.
Saying that this project is a piece of cake would set the wrong expectations. I believe the biggest problems are the efficient management of a large customer base (setting up a new domain, deleting a domain, moving a domain), customer support. I think it is okay to just get started and do the steps manually and then write some scripts that perform steps automatically. Customer support is all about plug and play, and the way the CPE setup is organized.
We recently gave some deep thougths about failover, and that will also be an issue that needs some scripting to make the failover happen automatically and quick.
And the other topic is of course QoS. If you are able to provide the neccessary bandwidth to the customer, your support life will be so much easier. Maybe VLAN on CPE to keep the traffic seperated from the general data traffic. Combined with the whilelist of allowed IP addresses that is a very robust way of providing hosted PBX which is safe against DoS and QoS-Problems.
-
We have made new builds in the version 3 of the PBX:
http://pbxnsip.com/download/pbxctrl-3.3.0.3165.exe (Windows Upgrade)
http://pbxnsip.com/download/pbx3.3.0.3165.exe (Windows Full Install)
http://pbxnsip.com/download/pbxctrl-freebsd7.0-3.3.0.3165 (FreeBSD 7 32 bit)
http://pbxnsip.com/download/pbxctrl-centos5-3.3.0.3165 (CentOS 5.2)
http://pbxnsip.com/download/pbxctrl-suse10-3.3.0.3165 (SuSE10, 32 bit)
http://pbxnsip.com/download/pbxctrl-rhes4-3.3.0.3165 (RedHat EL4)
http://pbxnsip.com/download/pbxctrl-debian4.0-3.3.0.3165 (Debian 4.0)
http://pbxnsip.com/download/pbx-darwin9.0-3.3.0.3165.zip (MacOS)
http://pbxnsip.com/cs410/update-3.3.0.3165.tgz (CS410)
This release has no major changes, just a lot of "smaller" things that we cleaned up or fixed since the 3.2 version. I believe it should be a great version, pretty stable, doing 99 % of what business expect today from an IP-PBX. I know some of you want to see a couple of new features like full video support and attended transfer into anything; we'll do this in a new version 4. Until then it is good to have a stable version 3.
Release Notes are as usual at http://wiki.pbxnsip.com/index.php/Release_Notes_3.3. If you are running 3.2 or 3.1, IMHO it should be an easy upgrade. As always, when you upgrade this is a excellent opportunity to back up the working directory before upgrading and store it in a safe place.
If you are upgrading from previous versions and you are in North America (country code "1"), make sure that the dial plans use the 10-digit notation. For outbound calls, you can also tell the trunk on how the number should be represented. That seems to be the biggest problem with upgrades so far.
-
I will try out 3.2 as well.
[...]
m=message 5060 sip sip:4796@demo.bizfon.com
Interesting concept to send the message in the SDP... Though in the meantime people would probably use the MESSAGE method (SIMPLE) or even better XMPP.
-
I am trying to send an IM from one extension to another. Both are Polycom's running 2.2.2.0084. When I send an IM one of the phones, it rings the phone for a split second and shows up as a missed call not as an IM. If I send the IM from the pbx, it gets delivered properly to the other phone as an IM. In the logs it looks like the sending phone is trying to call the destination with an invite instead of just sending the message. Is this something that is supported through the pbx? Should I be using a different version of software on the phones other than the version that is listed on the wiki?
I would recommend to use the 3.2 version of the Polycom phones. That is much more recent.
Do you have the SIP packets that are exchangd between the phones and the PBX?
-
Didnt't work for me. After adding # the system waits forever for the extension number. So the IVR options (e.g. "For sales press 1 ...) aren't working.
Does a solution exists?
The trick with # works on only direct destinations.
-
They are looking for just 3 way conferencing. Just the caller and 2 office phones. By the way I set up aconference extension here at our office the other day and it was awesome!
Well, 3-way conference should work... Did they try pressing the "conference" button?
-
We operate most phones within our LAN, but I have 2-3 phones at a remote location. Those should ideally connect through our VPN to the PBXNSIP server.
First question: Should this simple configuration work with PBXNSIP? So far it does not.
PBXNSIP server is on IP 192.168.26.130/Subnet: 255.255.255.192
Remote phone (Snom320) is on IP 192.168.26.26/Subnet: 255.255.255.240
Server and phone are using the same DNS: 192.168.26.130
All ports are open within the VPN, but the Snom320 reports: Network Failure.
Second question:
Would it be better to set up a second (smaller) PBXNSIP server at the remote location and connect both servers in order to get this stable?
I am not sure to do from the info I got from the forum so far.
From the PBX perspecitve VPN is just like any other network interface. In the setup above, the different netmask raise a question.
If you are using snom, why do you want to use VPN? You can as well just connect the phone directly through TLS and SRTP to the PBX.
Maybe you can try to set up a laptop with VPN and try to register a softphone first. That is probably a good way to verify that the setup is okay.
-
We have used this very good software for years on our Panasonic (through Audio Jack). RTP can be set up on the software but wont work at all. We only get some terrible noise. Did anyone had sucess setting up this software with pbxnsip?
If you have a audio cable, you can always connect the headset output to the mic input. It is a very pragmatic solution, but it works...
-
Can i please get this for Debian 4.0 as well?
-
I have a rather silly question. I have 9 remote phones they are Snom 370s and the customer is reporting that the conference feature does not work. I am assuming they should just push the conference button followed by the extension and the check mark to send the call. But apparently this does nothing. Any help would be great. They are running the newest firmware that Kevin and I setup on the trip there.
What kind of conference are we talking here? Three-way conference is the business of the phone; if they want more participants they must use the conference server - that setup works completely different (they need to dial into the conference).
-
It seems like the codec that PBXnSIp uses to talk to OCS is not right. In the OCS trunk I do not specifiy and Codec Preference, and at System level I now changed the preferred codec to G.711. but still not.
m=audio 59148 RTP/AVP 18 101
I find the above line all over in the SIP trace and I know it is then trying codec 18 (G.729) which OCS does not seem to like, and then 101, which I do not know what it is.
Thanks
Yes, that means that if offers only G.729 and OCS does not accept that. You must also offer other codecs like G.711.
-
The exact version is: 3.0.1.3023 (Win32)
Oh you should upgrade at least to 3.2. The 3.0.1 probably does not detect Turkish prompts yet. 3.2 even contrains a Turkush web interface!
3.3.0
in New Features/Versions
Posted
Okay, I tried that out here. That setup is what also used and that is what I would also recommend.
For me it worked. I had some trouble with the VLAN setup, the Ethernet switch was a little bit bitchy and I forgot to bind the tftp port also on the VLAN interface. But then it worked smoothly. There is one more thing that could be a problem, it is that the phone may need an extra reboot cycle after receiving the VLAN ID.