Vodia PBX
-
Posts
11,111 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
ACK. This is something we need to look into.
-
Okay, sorry if the response was not very clear. The 7.2 version had a feature called buttons (see http://wiki.pbxnsip.com/index.php/Assigning_Buttons), and because 7.2 is still not out snom put the support for buttons also in version 7.1. Therefore, there is no more need to wait until 7.2 is out. 7.1 is also fine now.
-
You can use the dial plan to block certian numbers (see http://wiki.pbxnsip.com/index.php/Dial_Plan). Just select the "Not Allowed" option in the dial plan.
-
Well, that is a famous problem.
Check if your service provider or gateway supports RFC3325 - that is the standard that can be used to indicate the original caller-ID.
-
I'm assuming the PBX sends NOTIFY's or something to tell the phones what extensions to watch? I ask because suddenly after rebooting the PBX, the BLF on our bigger polycoms have started working again (without them pulling a new config etc. from the server).
Is this correct? In which case, if we see BLF failing at a client, is there a way to push the NOTIFY's back out to the phone, as simply re-registering doesn't seem to do it.
Rebooting the PBX is not an option...
To track this problem down, maybe you can set the log so that the PBX watches the IP address of the phone and writes only those messages into the LOG - then it should be possible to see if hte NOTIFY to the phone still make sense.
What version are you using on the phone?
-
Maybe there is a matching problem with the leading 1 (in NANPA area). Check the dialplan scheme of the domains.
-
Any update please on timeframe for v.7.20? Thanks, Fred
At the moment I don't see a need for that - 7.1.x seems to do everything that we can dream of...
-
Well, UDP packets have a maximum size. In Ethernet networks, thqat is usually 1492 bytes. If the packet gets bigger, the lower networking layers split the packet up into several packets, that is called UDP fragmentation.
Unfortunately, the support from embedded operating systems for this feature is poor. Therefore, if you try to send a message longer than this magic number, you might get only the first fragment of it - and the rest missing.
Maybe you can try to use TCP layer (see http://www.polycom.com/common/documents/su...39;s_guide.pdf). If you are running version 2.1, you can automatically provision TCP transport layer by using the below settings:
-
Well, this is the dust cloud around the caller-ID presentation when doing an external call.
It looks like it would be a good idea to use the original number also when the call gets diverted (even if internally). If you like, please try the following build (raw executable): http://www.pbxnsip.com/download/pbxctrl-2.2.0.2415.exe.
-
As far as I know Polycom does not support the Reason header yet:
CANCEL sip:42@192.168.9.227 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.206:5060;branch=z9hG4bK-3c72e22ec1814c8612b6c6085db54721;rport
From: "Hunt Group (41)" <sip:41@localhost>;tag=39657
To: <sip:72@localhost>
Call-ID: 7898709d@pbx
CSeq: 20811 CANCEL
Max-Forwards: 70
Reason: SIP;cause=200;text="Call completed elsewhere"
Content-Length: 0
Answer:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 192.168.0.206:5060;branch=z9hG4bK-3c72e22ec1814c8612b6c6085db54721;rport
From: "Hunt Group (41)" <sip:41@localhost>;tag=39657
To: <sip:72@localhost>;tag=F833CB16-42D3D563
CSeq: 20811 INVITE
Call-ID: 7898709d@pbx
Contact: <sip:42@192.168.9.227>
User-Agent: PolycomSoundPointIP-SPIP_550-UA/2.2.0.0047
Content-Length: 0
-
Well, this setting is neccessary to tell the PBX which dial plan to use (and which acconut to charge) for a call that is initiated by that trunk. Background is Exchange, because that does do that.
-
Okay, let me try to understand: You are calling the AA, punch in the number of the extension and then the pbx starts the timer and starts saying "calling extension this-is-a-very-long-name-please-wait-a-while"?
If that is the case, would it be a workaround to set up a specific redirection time for that account?
-
In 2.1 - yes. Take a look at the spool directory, there the PBX puts everything that needs to be sent out. It even survives a restart of the service. The file system is something beautiful!
-
Anything from Wireshark? This is how it looks when the firewall blocks the traffic. Looking at the cable should be able to tell if the computer really tries to open a TCP connection to that location.
-
Maybe you can use the dial plan's feature to send a call to a registered extension?
-
I think the trick here is that the new logo must be located in the html/img directory.
-
After changing the port you need to restart the service. You can use the netstat command to see what ports the PBX really uses.
-
Can you please advise if there is current workaround with 3rd party solution and/or your timeframe for implementing.
I guess we have to look at OCS in more detail. Just adding a feature here and there is not a good strategy. CSTA is not trivial, and it will take months to get it stable. Therefore I would not count on it. TAPI could be a workaround, there is a lot of TAPI stuff available. But I have no overview if there is soemthing that could convert CSTA into TAPI!
-
OCS client doesn't register with pbxnsip. Is it possible to force a manual registration or denote the SIP address of the OCS client in pbxnsip, to permit forking?
You can add a static registration in the registrations tab of the extension. Maybe that solves the problem?
-
damn. whats the timeframe? i have a customer sold EXCEPT the Random distribution killed it.
We could give you a beta image...
-
I guess you are using CO-lines on a trunk? Then those lines are all in use!
-
The first time when a user call the mailbox the PBX asks him to record his/her name.
Later, a user can record the name by going into the mail menu of the mailbox and record the name with '3'.
-
did this get added into 2.1?
No. But it will be in the next beta version (probably a 2.1.1.x).
-
Sounds like a bug on the phone to me... thought that was fixed a long time ago!
Cell Phone Integration
in Extension Setup
Posted
Well, the original problem is how to present numbers in a "canonical" format on you server. There are different conflicting styles: 1xxxxxxxxxx, xxxxxxxxxx, and +1xxxxxxxxxx. In the end, the PBX must make a string comparison to get a match. Ideally, all connected devices talk the same way. The dial plan "workaround" puts NANPA numbers into a internal canonical format, so that the comparison works.
If you are living outside of the NANPA there is no other choice than getting all connected trunks straight.