Vodia PBX
-
Posts
11,111 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
Do you already know if you will have a PBX version 2.1.0.2116 that will support this historic on hold procedures again??
Okay there is a 2116 version (http://www.pbxnsip.com/download/pbxctrl-2.1.0.2116.exe), and we did a small change in the 0.0.0.0 detection, but we had no chance of trying it out. Please give it a try.
-
FC-000032-01-11 480i
FC-000040-00-11 480iCT
FC-000046-01-11 9133i
FC-000058-01-11 9112i
Unfortunately, we have only a 57i here... Interestingly, this one uses 0.0.0.0 and a=sendonly in the same SDP.
-
I don't think it is the Replaces. I looked at the SDP, but they all contain the out of band codec. It is wierd.
-
You are missing the point or I wasn't clear enough, I am trying to insert 1914 and replace the 8 at the same time. So when I dial 8 and then local number (for example 2441000), I want the 8 to be replaced (or removed) and then 1914 inserted - So when I dial 82441000 on my phone, I want the PBXNSIP to dial 19142441000.
Oh, okay.
Simple patterns might not be suitable here. I you use the ERE pattern 8([0-9]{7})@.* and the replacement 1914\1@\r;user=phone then it should work.
ERE are not beautiful, but powerful ;-)
-
Well, the Replaces header tells the "other side" what call to drop as a replacement for the new call (initiated by the REFER). Because everything is happening inside the PBX, that logic is programmed without really initiating another call. Doe the replaced Call-ID exist on the PBX? If not, the PBX should log the message "Replaces: Call-ID xxx not found" on log level 5.
-
Yes. Other vendors are welcome to join the team of easy and fast button updates!
-
Did you see the stuff on the Wiki? http://wiki.pbxnsip.com/index.php/Microsoft_Exchange Did it touch that topic.
2.1 has a new setting called "Assume that call comes from user" that is not covered by the Wiki page. It tells the PBX what account to charge if Exchange wants to initiate an outbound call from the trunk.
-
Why don't you use 8* as pattern?
-
Hmm. Maybe it is easier to program around it and support that old style as well.
-
PCMU, PCMA == G.711 ...
If you continue to have problems, it makes sense to run Wireshark in the network to identify the problem.
-
Yea for internal calls that should be okay. It is all about expectations!
-
Well, this is a long story.
I think we can say that we tried almost everything, and the above PPT is the gist of it. One bottom line is: Don't just get a cheap DSL and think that you are all set.
-
Oh yea, they are using the 0.0.0.0. I am not sure if we should still support this more than 5 years old "workaround" - isn't there a SW upgrade for the phone available?
-
Indeed. Workaround is to add another pattern +* with replacement also +*.
Will be fixed in the next 2.1 build.
-
Do you have the SIP INVITE that tells the PBX to hold the call? Maybe the phone is using the old style with 0.0.0.0 (which was obsoleted in June 2002, see RFC 3264)?
-
Well, what you can do already is use SOAP to set the state. If that's an option, we can work out the details.
But it makes sense to control that flag also from the web interface. The next version (2.2) will have it.
-
Version 7.1.23 also does that, and this version is available as beta from the snom web server. If you are using 2.1.0.2115 then PnP should be working smoothly.
For example, you find the snom firmware here (it is not so easy to find on the snom Wiki):
http://fox.snom.com/download/snom300-7.1.24-SIP-f.bin
http://fox.snom.com/download/snom320-7.1.24-SIP-f.bin
http://fox.snom.com/download/snom360-7.1.24-SIP-f.bin
http://fox.snom.com/download/snom370-7.1.24-SIP-f.bin
If you need to upgrade from version 6, see the descriptions on http://wiki.pbxnsip.com/index.php/Snom.
-
There are plenty of gateways available, for example:
AudioCodes
Grandstream
Ericsson
Patton
Parlay
Mediatrix
Teles
Vegastream
-
Works here, using PBX 2.1.0.2115 and Aastra 57i/2.0.1.2000 Brcm-Callctrl/v1.7.2.2 MxSF/v3.6.2.5. Maybe you need to upgrade the PBX to the 2115 build.
-
Could it be that the SIP packet goes to the default IP gateway of the PBX? Seems there could be a problem.
-
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.
-
Strange problem today (Polycom 550\2.1.0.2111)
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?
2.1 release available
in New Features/Versions
Posted
Well, the best solution in this case is probably to use the manual update in http://wiki.pbxnsip.com/index.php/Installi...#Manual_Upgrade. That should work independently from the InstallShield updates.