lance@YSL

Thanks

Hi, There is a malformed tag <language> when setting the IVR Language in the General settings for extension XXXXX feature. If you leave it on Default System IVR Language then the Language tag is excluded form the SOAP CDR XML and the XML is formed correctly. If you change it to English, the XML tag is malformed as the closing tag does not have the /. If you view the output from the SOAP CDR without trying to parse it you will see: <Language>en<Language>... Obviously this should be <Language>en</Language> I have tested this on two different implementations of PBXnSIP 2.0.3.1715 (Win32).. and both have this problem... Solution... either do not change the default language OR parse the output of the SOAP CDR and "fix" the second <Language> tag before using XML tools. Hope this is or will be corrected in 2.1 Cheers Lance

Hi, As an update to the wiki (http://wiki.pbxnsip.com/index.php/SonicWall) We have succesfully tested SonicWalls latest devices... specifically the PRO 4060 and 5060 with the SonicOS Enhanced... and there are no problems whatsoever... We are able to use the built in SIP support to get snoms and softphones to make perfectly incoming and outgoing calls to each other... It took the technicians about 15 minutes to setup and apparently the latest firmwares resolve all problems mentioned in the wiki... I cannot say for sure, but apparenlty the smaller TZ series devices with the newer firmwares should work as well - please take that with a pinch of salt until someone can confirm or deny it.. Lance

Hi, Just trying to establish some further specifics on how PBXnSIP controls DoS (denial of service)? I.e. what are the criteria at which PBXnSIP assumes a DoS attack and starts limiting connections to compensate... I have found out that the http_rate setting in the global conf xml, but we need further understand of this feature... 1) to know what will trigger it and 2) to see how to set it realistically in a higher than normal call environment.. Cheers Lance

Hi, We are currently testing a server for maximum performance issues... Server SPEC: HP DL380 G4, 2 X single core HT 3.0ghz Xeon CPUs, 3GB ram, 72gb SAS (RAID 0) The problem here is not so much the actual numbers we are getting, but the fact that the server performance seems to be only using cpu 1 thread of a possible 4 ... i.e. we are able to max out a single HT - but the other 3 are virtually idle so we cannot get higher call figures... A simple check in Task Manager shows it very obviously... on a HT system the first thread is idle, the second maxed out, the third (ie.. second processor) and forth (also second processor) is idle... I.e. a 3rd of the processing capacity of the system is idle and does not seem to be possible to get PBXnSIP to use it... I have not had a chance to test PBXnSIP on some DL385 Dual core Athlons so see if the same is evident there, but this is a bit of a concern for us... Any response as to the ability of PBXnSIP to support: Multithreading Multiprocessing Multicore ?? Cheers Lance

Hi, As PBXnSIP only supports a single cert, can this cert be a wildcard cert? (see: http://www.thawte.com/ssl-digital-certific...ducts-wildcard) i.e. *.domainname.net The purpose of this would be to allow separate domains - i.e. pbxnsip domain1 and domain2 to have aliases such as dom1.domainname.net and dom2.domainname.net and have the wildcard cert handle the correct encryption.... I.e. one cert supporting multiple domains on the server... Would this work? Cheers Lance

I am glad that you are happy with your change - I would do the same if I had had your experiences and hassle... I have a few comments... VoIP years before its ready... Hmm... Perhaps in certain aspects it may well be but as a general comment about VoIP I would have to disagree. The key here is that the requirements of a site/customer need to be correctly mapped out and the solution chosen to meet those requirements - if you had requirements that VoIP could not meet, then I would have gladly steered you away from VoIP from the very start and recommended a traditional or hybrid solution from one of the other providers. A well designed well spec'd VoIP solution can work very well... It is important NOT to put force a square plug into a round hole. Seen as though you make a general comment about VoIP - here is a general comment of a live client - We have a client running on a VoIP solution (nonPBXnSIP) with digital ISDN connections and a ITSP connection for least cost calling... They are about 80 people and a 24x7 call centre.... Their call volumes (excluding internal calls) are over 30 000 per month (similar to your call volume) and in that period they have maybe 0.001% call problems of a nature similar to yours (not quantity)... I am sure other readers will have some similar success stories to mention..... The key here is that the system chosen and designed was taken with all its limitations and benefits and it was not compared directly to another traditional PBX... i.e. the client wanted a phone...Tick, the solution did that, the client wanted cheaper calls, Tick, the solution did that.... the client wanted billing, Tick, the solution did that... It did what it was intended to do AND more importantly it did not have to be reworked or patched or linked in a hundred little ways to meet the client requirements.... It was spec'd to handle a specific call rate.. which it does... etc etc. etc... Just looking at your mix and match hardware and software solution and system spec makes me cringe - even if I did not read your problems, I would have put money on the fact that you would have had problems from day one.... We have now moved to PBXnSIP and are using the same approach... If the client wants something we cannot professionally supply, then we simply 1) tell them the function is not available and 2) a patch job to make it work will undermine the solution to you... Everything is properly spec'd and hybrid workarounds to make an old system (like the accountants paper fax machine) work are dealt with and immediately addressed... We have a large amount of faith in VoIP and PBXnSIP and are putting a huge amount of money (read tens of thousands of US$) into setting up a hosted solution for 1000's of users.... VoIP is here to stay.... Anyway... just my two cents on a friday afternoon....

Quality of Service is the main reason for doing this... and this all depends on the use of the network in question. We have a client on a different (nonPBXnSIP) installation that handles about 30k external calls per month on G711 codec running softphones and IP phones on the same network as the rest of the companies data traffic... There is no problem with this configuration and we have no QoS or VLANs in place... The key here is that the 10/100 network is totally underutilised and no single or group of users overloads their network switch or link in any way... Conversely to this, we have a demo client on PBXnSIP with a main office and a separate building 2km down the road with a wireless link between them... Before QoS was installed on the wireless link, they had problems making/recieving calls over the wireless link intermittently - this was 100% attributed to running out of bandwidth on the link and it was not related to phone calls but to people dumping large files over the network link overloading it... with QoS in place, at least the calls improved, but bandwidth remains a problem... We also have a client who runs a media house - doing video and design work - where they regularly transmit 5GB+ size files over the GB network... This site has VLANs and complex network setups to handle this problem and it was decided up front to use a separate routed IP network for the VOIP from the start because there would be no chance calls would be able to compete with the existing traffic on the same network ... The only downside in this entire scenario is that softphones running on users machines had to use the data network, whilst hard IP phones used the dedicated network. Summary - it all depends on the network use.... Hope this helps a little for explaining it in less technical terms...