Vodia PBX

It's not the only thing. We also need scheduled playback (company wakeup call)...

Sometime I don't know what Exchange wants... Redirect a call to a DNS name, and no username? I guess that does not go through the dialplan and then PBX does not know what to do with it...

On the out capture, there is no traffic (at least I did not find anything) that shows the PBX being involved... Maybe that is the problem? Did you set an outbound proxy on the ATA that points to the PBX? Maybe the ATA tries to go directly to the service provider. The other thing that I can think of would be that there is a operating system service performing the forwarding of incoming traffic to port 5060 to the service provider address. The whole setup looks a little bit strange (but not necessarily wrong) because the PBX seems to have one public IP address but has a route into private IP addresses. Maybe something went wrong there.

It would be definitevely interesting to see the trace (please send it to support@pbxnsip.com).

I guess we are talking about a message like this: [7] 20091216115340: SIP Rx tcp:192.168.4.104:63483: SUBSCRIBE sip:48@pbx.company.com:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 192.168.4.104;branch=z9hG4bK4f6fee11C361DAE6 From: "Fourty Eight" <sip:48@pbx.company.com>;tag=7712E03B-A6163748 To: <sip:48@pbx.company.com> CSeq: 2 SUBSCRIBE Call-ID: 988c379c-477f92d5-f3ce2f5a@192.168.4.104 Contact: <sip:48@192.168.4.104;transport=tcp> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER Event: dialog User-Agent: PolycomSoundPointIP-SPIP_550-UA/3.1.3.0439 Accept-Language: en Accept: application/dialog-info+xml,application/rlmi+xml,multipart/related Supported: eventlist Authorization: Digest username="48", realm="pbx.company.com", nonce="1c874d174e18bb301d88f28b73213a33", uri="sip:48@pbx.company.com:5060;transport=tcp", response="a2d1469c8fdfb96d958eed462613d910", algorithm=MD5 Max-Forwards: 70 Expires: 120 Content-Length: 0 The PBX answers with: [7] 20091216115341: SIP Tx tcp:192.168.4.104:63483: SIP/2.0 404 Not Available Via: SIP/2.0/TCP 192.168.4.104;branch=z9hG4bK4f6fee11C361DAE6 From: "Fourty Eight" <sip:48@pbx.company.com>;tag=7712E03B-A6163748 To: <sip:48@pbx.company.com>;tag=1f8da3cef2 Call-ID: 988c379c-477f92d5-f3ce2f5a@192.168.4.104 CSeq: 2 SUBSCRIBE Retry-After: 3600 Content-Length: 0 The problem is that the phone retries after a few seconds, not one hour (see http://www.ietf.org/rfc/rfc3265.txt). That's okay for small installations; however for large deployments a pain in the neck. What you can do is setting the "Watch the calls of the following extensions " for the extension to one extension (better don't use star because in large deployments, this will create an even bigger mess), then the phone respects the duration and will happily show the status on that extension. Not sure if a firmware update solves that problem or there is a setting available that slows down the retry (there are a lot of parameters in the xml configuration files). We will investigate if there are more feasable workarounds for this problem.

Can you get a SIP trace? I would like to see who is initiating the disconect. If the PBX initiates the disconnect, then it includes the reason for the disconnect. We have had cases where the gateway disconnected because it tought there was a busy tone. Just want to make sure that we are not having this problem.

Well, this is one of the major cleanup areas in version 4... Workaround in version 3 might be to monitor the hunt group instead of the extension. Maybe we can see if we can fix that in 3.5.

That might be the problem. The PSTN gateway should not register on the PBX. It should just send the call to the PBX, but no registration. Try turning this off.

Well, that is very strange. Maybe there is a problem with the timer subsystem. Though I did not hear about it for a long time, but there is hardware that has a lot of jitter in the precision timer, so that callbacks in the ms range become difficult. It would explain why the playback would be too fast. Is there anything special about the hardware? Does e.g. a softphone play smooth on that hardware?

Disconnect reasons are: Call duration reached. For example, when the 3-minute demo key is used, the PBX disconnects the call Same thing happens after the maximum call duration, which is by default 2 hours One way audio. That means the PBX does send media, but does not receive anything. Classic is when someone in a conf call hits the mute button and the phone stops sending media (which is obviously a bug). Or when a phone crashed and restarted. Call never connects. This is a nother classic when using analog FXO gateways that have buggy polarity detection and they never connect the call (though media flows both ways).

AFAIK Patton, Vegastream, Quintum, AudioCodes all work well with BRI. AVM FritzBox also works; however the echo cancellation might be a problem there.

It is not a license problem. DNS also works without license. Maybe the Microsoft applications find the email server because of some Active Directory or other Microsoft-specific mechanisms. There are a lot of packets flying around when you look at Wireshark...

No, the PBX always binds the DNS socket to "anything" (0.0.0.0 in IPv4 and :: for IPv6). Was that the question?!

I guess the problem is the UPDATE message. The PBX assumes that the UA supports that method (it does advertize it), but obviously it does not work. There is a setting called "support_update" in the PBX; try setting it to "false" (see https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=413 on how to perform this setting change through the web interface without restarting the service). In later versions than the one you are using, we made the setting default to false. Seems UPDATE is not very well understood in the real SIP world.

So does a reboot make any difference? I still like the idea that you might end up with two media streams so that the network gets congested...

Maybe you should take a look at snom firmware 8.2. Seems that the stability is better there.

Blaming Comcast sounds a little bit too easy for me... I guess usually the file plays at th right speed? Then I would exclude a format problem (8 kHz, 16 bit/sample, mono). What could happen is that there is a congestion on the way to the client so that a lot of packets arrive at the same time. Then it would be understandable that the playback speed varies a lot. However, that should not only happen with music on hold, but also with other cases. The difference might be here, that when the customer holds the call, he has more than the usual one phone call active--the call that has the music on hold also requires bandwidth and that would explain that this happens only when moh is in the game.

Ich wuerde mir mal das INVITE ansehen das an das Gateway geschickt wird. Da muesste eine Nummer drin stehen, die das Gateway darstellen kann. In vielen Faellen muss man im Gateway auch noch einstellen welcher Nummernblock verwendet werden soll. Welches Gateway verwendet Ihr?

The document is dated March 2009--I would say we are up-to-that-date.

RTCP and RTCP-XR are amongst the topics that are addressed in version 4. IMHO pretty cool stuff, will help to locate problems quickly without users involved.

Did anyone had the change to try out Microsoft Hyper-V for failover? I saw an advertizement that stuff like Microsoft Exchange can failover pretty quickly and I think this should also work for the pbxnsip PBX.

How can I agree more... I think you need to open a trouble ticket on snom and report the current clock as "buggy".

It should work. Just make sure that you need to remove these files when you upgrade the version to something that includes the PnP files for snom 870. (All version older than today do support this).

No this will not work. "*" has a hardcoded meaning in the auto attendant. It will be very difficult to change that.

Does it make a difference if you wait a little? maybe the problem is that the call is not connected yet.