joeh

Could it be intermittent packet-loss perhaps? The odd dialogue message lost and retransmitted? You could maybe try the same setup on a LAN, that way you'll know if it is confined to the satellite network or not.

I would say the problem you are experiencing is a combination of the SIP dialogue between the endpoints coupled with the delay over the satellite network. Obviously during an INVITE, the INVITE is then relayed to the remote party, they then negotiate, they then answer, the PBX then tells the remote party they've answered etc etc, you get the picture. If the average delay over the network is 3000ms, then each message is going to take 3s, you can see why a delay is possible during call setup. In terms of fixes - I'm not aware of anything immediately obvious that would speed things up to be honest. The only thing I can think of is to play some kind of media until the remote RTP stream is received to give the impression they still haven't answered.

If a call comes into a hunt group (e.g. 200) with members (100,101,102) - do the CDR logs display who answered the call or just 200? I wrote a program to parse the CDR records and stick them into MSDE\MSSQL only to be slightly confused by it. Could an additional column\attribute be added to include the answered-extension (whether due to the huntgroup or a divert)

I think if people subscribe to the state of the service-flag, and the flag is changed from the web interface - the necessary SIP messages are not sent to the phones to change the lamps.

What's the file?

Just to bring this up again. I am trying to configure custom ring-tones for a customer when a call comes in on a hunt group. The Snom's BellCore's are not massively different. The SIP INVITE to the phone is sending through "Bellcore-dr4" (I selected Custom4 on the hunt group). Is there anyway to change the Alert-Info headers that get sent to the phone, so for instance, I can select a custom WAV on a http server (http://10.0.0.1/my.wav)

We've had a very very weird issue with a customer with Polycom 330s using 2.2.0. They boot fine, download the config from PBXnSIP and generally work without any issues whatsoever. Then... We had an issue where maybe 6 out of the 12 phones froze, they were completely unresponsive and needed a hard reset to kick them back into life. We thought nothing of it, we powered down the PoE switch and they came back up with no issues. 24 hours later, the same thing happens again - this time, all 12 x 330s completely hung. We're in the process of swapping them out rapidly with Snom 360s until we can work out what is going on.

I'll see if I can get WireShark running for a couple of days to reproduce it.

All UDP as far as I'm aware. It also seems to happen in some cases when we enable call divert using the * codes. We dial the star-code, then after performing the divert we are notified of a message. When we log into voicemail, the message left is the system saying "you have enabled call divert to..." Which is odd.

Just happened again today. Verbose logging was off though. Call came in, answered on a Polycom, transferred to me (Polycom) - I answered, talking away for 5 minutes, call cut off and the caller was transferred into my voicemail..

Was this ever addressed? We have a customer with Snoms running v7 and PBXnSIP 2.1 - they no longer see who's calling who, and... they want the ability back!!! Some of our customers don't like it due to privacy, others do like it because they're nosey. Is this an optional feature, or has it simply been removed? Was it a Snom or PBXnSIP thing too?

Whilst SOAP is very flexible - a number of our customers have simply asked for the facility for call logs to be written to date-formatted CSV files (e.g. CDR-2007-10-09.csv) that they can access. I know it's possibe to knock up an ASP page or PHP script that receives the SOAP request, parses it and writes it to disk - but is there any chance 'native' CSV support could be written into the software? e.g. Specify a path on the domain settings, using the $d options for date-formatting, or just use the ISO date for simplicity.

Seconded - we currently have to bodge the Hunt Groups or get on a Snom phone remotely to initiate the dial to disable the Service-Flag...

Strange problem today (Polycom 550\2.1.0.2111) 1) Call came in to a hunt group 2) Colleague answered 3) Transferred the call to me 4) I was chatting away (~5 minutes) 5) Call cut off (I didn't press anything!) 6) The Caller was then immediately transferred into my voicemail!? The SIP Logs suggest that the PBX sent my phone a BYE, then immediately put the call into my voicemail?? I have the logs if you would like to review?

I will do some further testing. The setup in both cases is very different, one is Dell whilst the other is HP with different audio chipsets between the two. I will try updating the audio drivers to see if that fixes it.

Any ideas on how to fix it?

We use ISDN gateways from Parlay and Vegastream, both of which are solid. We stopped using Analogue FXO gateways due to the problems you mention, sometimes we'd get them working, only for echo and problems to occur later. Where possible - we always use ISDN. It is also much easier to troubleshoot than analogue . In terms of phones, we use Snom primarily, although recently we've been using the latest Polycoms (550 etc) and the Linksys 941/962s. My only complaint about the Polycoms is they take an age to reboot following the slightest configuration change. Whilst we had a weird issue with the Snoms whereby if all the lights were subscribed to extensions and all those extensions rang simultaneously it would cause what could be described as a DOS attack. The LEDs would flash randomly for maybe 30 seconds before settling down - I guess because the phone's CPU was trying to process the notify messages\lights etc. The server-load is my main concern, especially when all calls in and out of a hunt group will be recorded. Am I right in thinking PBXnSIP will hold the call in memory or will it write it straight to disk? The first case would require lots of memory whilst the latter would possibly require RAID0+1 or RAID5 if the number of concurrent calls is high. I guess if you reach a point where one server can't cope, or isn't desirable - you could split the company and have two domains - dialling between the two with some dial-plan logic.

Are the log bits fixed in this? Also customer with *87 issues reported they've picked up a calls and got silence... Whether that is because they were too slow (or should they receive a 404?)

Bug report. I was viewing the logfile via the web interface, seleced 'Clear Log File' and the system crashed. It was logging 1000 lines, Level 9. Windows Event Log reported; Faulting application pbxctrl.exe, version 0.0.0.0, faulting module pbxctrl.exe, version 0.0.0.0, fault address 0x0016c030. This is the 2105 Version, Windows XP.

We have a couple of customers who are after a "larger" scale PBX deployment (40+ users). This is larger than our typical deployment and I wanted to quiz people as to their experiences with such a deployment. This one particular customer wants the works, full call recording, CDR reporting, various hunt groups etc. This is going against competing solutions from Mitel etc, so has to work. The network will be high spec, one dedicated for VoIP with a relatively high spec server (Decent CPU, RAID, 2GB RAM etc). Comments and input are appreciated.

I think I will take the chance! Is there a possibility you can let me know what the outstanding tickets are so I can make a risk assessment. For example, If they are issues relating to IVR\Agent-Groups, these are things the customer doesn't use so great. If they are related to call transfers, registrations, trunks etc - then that is a different thing altogether.

How Beta is this? We have a customer prone to the *87 stealing calls from their colleagues. Is it worth upgrading? Or will we be prone to more problems?

One of our customers has asked if it is possible not to increment the "Missed Calls" counter on their phones if someone else in the hunt group answers the call (as opposed to the Caller Cancelling the call) For example; - Extensions 100 & 101 are members of Hunt Group 200 - Someone rings 200, 100/101 both ring - 100 answers. 101 has "1 Missed Call" on her phone. - She returns to the office and rings back the person, only to be told they spoke to 100. This isn't necessarily a problem for PBXnSIP - but more a feature of Snom phones. Now obviously when a hunt group rings and sends out INVITEs, if someone else answers, the system sends a `487 Cancelled` to each unsuccessful phone. These phones increment their missed calls counter. If someone rings the hunt group, and the caller cancels, I guess PBXnSIP sends a `487 Cancelled` and the Snoms increment. Now I am not sure at what point the Snom increments their missed calls counters, I guess after the 487 is received? I think it would be possible to add an additional SIP Header ("X-Cancel-Cause: Huntgroup-Answered | X-Cancel-Cause: Caller-Cancel") - when this is present in the 487 - the Snom knows NOT to increment the missed call counter. Is something like this possible? Is this a common request? It allows the user to differentiate between missed calls to a hunt group and genuine missed calls to their DDI.

To reply to myself. This particular phone had an IP address in the Registrar\Proxy as opposed to a FQDN. If I replaced the IP address with the FQDN it worked fine and the Snom responded to the 401 from PBXnSIP. If I left the IP address in place, it didn't respond - although it recognized it was challenged.

If I manually reboot a Snom 360 - it doesn't RE-REGISTER following the reboot. If I force the RE-REGISTER from the web interface, it works. Looking at the SIP logs, the phone doesn't response to the 401 challenge following the initial REGISTER. Any ideas? These phones are configured manually (not using plug n' play). Is there a particular setting on the phone that is stopping it? (by means of a feature). The Registrar\Proxy is set as the PBX - using UDP.