Vodia PBX

Just wild guessing here... Many routers have relatively short tables for NAT, for example I have seen devices with just 32 entries. If the number of phones changes the behavior, that could be a point. Keep in mind that DNS and RTP require additional ports. If you can, reduce the number of phones and see if that at least improves the stability. Or if you have another router, maybe try swapping the router out just to see if that changes something.

In any case I would move to 2115. Then a SIP trace would be interesting if the problem is still there.

We tried the upgrade with a stopped process, that worked. Maybe the problem is with running service.

How do you connect via VPN? You mean you have a VPN client running on the Teles box? Whow, I did not know that was possible! What you can try to do is going to the web interface of the PBX and check the system status. Reading that status actually refreshed the IP configuration cache. There you can see what IP addresses the PBX found on the system. Is this what it should be?

So it works now?

Check out http://wiki.pbxnsip.com/index.php/Installi...oftware_updates. After updating to 2084, you should update to 2115 (see http://www.pbxnsip.com/software).

You can manually edit the pbx.xml file and remove the password there (which should be a long hexnumber). After a service restart the password is empty.

Hmm. The attachment from the NOTIFY would be interesting. It is "human readable" and shows what the PBX opinion on the message count is. Also, see RFC 3842.

Well, that is a complicated topic. DTMF depends not only on the connection between the PBX and Exchange, is also depends on the DTMF that has been negotiated on the other side. In the end, a Wireshark trace will show what is the problem. Plus it is still a mystery to me how Exchange can be made to detect inband DTMF. They are able to recognize voice, so they should also be able to detect inband DTMF IMHO. I saw it working in one place, but in other places it did not work and I have no idea why.

Well, regarding the UM trunk there are two settings: The redirect flag and the "Assume that call comes from user". The last one is important if you want to accept trunk-in-trunk-out calls (which Microsoft Exchange does) - then you need to charge an account for that. Someone needs to pay the bill, even in a IP-PBX.

Yes...

Hmm. The only differernce that I can see is the missing tag on the GS. In SIP 2.0, requests must be tagged on the From header. Maybe they are using the old SIP RFC?

Okay, we made the 2.1 version publically available. The release notes can be found at http://wiki.pbxnsip.com/index.php/Release_Notes_2.1.0. IMHO there are a lot of good fixes and also some interesting new features and 2.1 will be a great release! As stated there, there is not reason to upgrade running systems unless there is a good reason in the release notes. If you just want to try the new version, please ask for a demo key and run the trial on a seperate test machine.

Agent groups and hunt groups do not respect redirection settings. Otherwise your office will end up with a lot of redirected calls (and loops). The only way to "redirect" hunt group calls is to use the hot seating to another extension.

Well, with pbxnsip you can. OCS and other products also don't do magic. But you must be aware that the audio quality will suffer and the maximum number of calls on a 4 port FXO will be 2.

Well, what you can do is run a PCAP trace on the phone and see if it is really sending REGISTER packets. Or if you can have Wireshark in the network you will get a "objective" view on where it is failing. If you filter by IP address the actual PCAP trace will not become too big, so that you can run it for several hours. If you are running the phones behind NAT, it would also be very interesting if the packets arrive at the PBX unmodified. There is some equipment out there that tries to behave smart and patches SIP packets in a bad way or randomly changes ports. Just want to make sure we are not burning time on such bad equipment!

I remember that the older versions had a flag that you can switch off in the user interface. But it seems that this flag is not available in the version 8 any more?! I check my phone here, but even the unlocking does not work for me any more... Maybe there are too many Cisco engineers in the IETF working groups and this is their way of making everyone upgrading to IPv6.

If the phone does not register any more, I would recommend to set the transport layer to UDP and use IP addresses (no DNS addresses). If that is not stable, there is something really strange going on. If the DNS does the trick, check out the availability of the DNS server. If the UDP does make a difference, there msut be something with the stability of the TCP connections in this setup.

You don't have to restart the service for that.

Well, whenever an IP interface becomes unavailable the PBX has a problem because the internal routing tables don't fit any more. Is there any way you can stabilize that VPN connection on the PBX? For example, have another server doing the VPN and just send the traffic there (in a different IP segment)? Then the PBX IP config never changes and the PBX does not get confused.

Then it is not a Aastra-specific problem... Must be something else, maybe a permission problem. Or just move to the latest and greatest 2.1. If you register a trunk then that should be possible (maybe you just create another trunk for this purpose). The incoming call from PBX1 will be treated like a regular extension call on PBX2 - then you can call whatever you like there.

I verified it here and it worked fine: [5] 2007/10/08 13:36:47: SIP Tx udp:192.168.0.155:5060: INVITE sip:44@192.168.0.155 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.154:5060;branch=z9hG4bK-574d8fa8e8ff00be15c9d675fed0d3d5;rport From: "41" <sip:41@test.pbxnsip.com>;tag=24656 To: "*9044" <sip:*9044@test.pbxnsip.com> Call-ID: f259c65d@pbx CSeq: 10040 INVITE Max-Forwards: 70 Contact: <sip:44@192.168.0.154:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: pbxnsip-PBX/2.1.0.2115 Call-Info: <sip:41@test.pbxnsip.com>;answer-after=0 Content-Type: application/sdp Content-Length: 244 v=0 o=- 56981 56981 IN IP4 192.168.0.154 s=- c=IN IP4 192.168.0.154 t=0 0 m=audio 60508 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv [5] 2007/10/08 13:36:47: SIP Rx udp:192.168.0.155:5060: SIP/2.0 200 OK Call-ID: f259c65d@pbx CSeq: 10040 INVITE From: "41" <sip:41@test.pbxnsip.com>;tag=24656 To: "*9044" <sip:*9044@test.pbxnsip.com>;tag=596481733029d22 Via: SIP/2.0/UDP 192.168.0.154:5060;branch=z9hG4bK-574d8fa8e8ff00be15c9d675fed0d3d5;rport Content-Length: 255 Call-Info: <sip:192.168.0.154>;appearance-index=1 Allow-Events: talk,hold,conference Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO Content-Type: application/sdp Supported: replaces Contact: "*9044" <sip:44@192.168.0.155> User-Agent: Aastra 57i/2.0.1.2000 Brcm-Callctrl/v1.7.2.2 MxSF/v3.6.2.5 v=0 o=MxSIP 0 1562308524 IN IP4 192.168.0.155 s=SIP Call c=IN IP4 192.168.0.155 t=0 0 m=audio 3000 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv

The problem here is that the Cisco phone sends UDP packets from a different port than it is listening on. This is extremly NAT unfriendly, and such a phone will never work behind NAT (FYI). There is a setting on the phone called "NAT friendly UDP ports" or so that turns this off. If you toggle this flag the Cisco phone will use the port 5060 for sending and receiving. Cisco is one of the few phones that do this. Practically all other phones use the same port for sending and receiving.

2.1 has more than one personal greeting... Unfortunately it is not so easy to migrate the old prompts to the new prompt style. I guess manual explainations are more complicated than just doing it automatically. so check out http://www.pbxnsip.com/download/pbxctrl-2.1.0.2115.exe - it should migrate those files.

I would suggest to use the logging feature in the PBX. You can set per extension on what log level registration events should be logged. For example, if you set it to log level 1 and set the general log level to 2, you should be able to see when the phone looses it's registration and when it comes back. This feature helped in other situations to figure out what was wrong. In that case there was a router that was changing the NAT binding from time to time and during that switch-over the registration got lost. A replacement of the router solved the problem.