Vodia PBX
-
Posts
11,116 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
Does anyone have the lines necessary to add to the provisioning script to auto provision the Linksys SPA962 phones / windows XP SP2 based installation?
Hmm. The PBX generates the files for SPA941. They should be pretty much the same?
-
If I use 501xxx all 501xxx calls will be routed to say trunk1
How to diffrentiate 501110 and 501111 to trunk 1
501112 and 501113 to trunk 2
thanks
You can still use ERE. For example 501([0-9]{2}[01]) will match 501xx0 and 501xx1 (and return the last three digits). ERE are very flexible, though not so easy to read.
-
I am running 7.3.7 guess its not in this build. You need to use 7.3 for the flexor apps.
It will also be in 7.3.
-
When we dail a 6 digit number I want to delete 3 digits and send the remainig 3 digits to different trunks.
E.g 501110 delete 501 and send 110 to trunk1
501111 delete 501 and send 111 to trunk1
501112 delete 501 and send 112 to trunk2
501113 delete 501 and send 113 to trunk2
501123 delete 501 and send 123 to trunk3
Is this ok for trunk1
Pattern 50111([0-1])* Replacement 11*
and repeat similarly for the rest of the trunks or there is a better way to do it.
I would use pattern 501xxx and no replacement. Or use 501([0-9]{3}), no replacement.
-
I have upgraded a phone system from 2.0 to 3.1.1. It use to be that we place a call on hold and another extension will be able to pick it up.. Now on version 3.1.1 this cannot be done, is there some thing I'm missing?
Or we have to use Park Orbit now?
The old behavior was a little bit "dangerous". Yes, a park orbit is much more suitable for that. If you can, better use a park orbit (also called "non-exclusive hold").
-
CS410 crashes whenever I press 5 to hear time/date stamp when listening to messages. This had worked before New Years..
Interestingly enough when I ssh and do a date command, I get
comcerto:~# date
Thu Jan 1 00:08:52 UTC 1970
I am suspecting this is the issue. Can anyone confirm and advise how to fix???
What version? Crash like in process dies??
Apart from that, you should also take care about the NTP. Obviously envelope information without current time has only limited value.
-
I used auto provisioning in order to get the pbx adress book working. This worked, but I have no possibility anymore to change the language of the phone on dutch. The only option is English.
Did i do something wrong or is the only option English ?
Furthermore I would like to know if there is another possibility to use the PBX adressbook ?
You mean the address book XML content which is generated by the PBX web server? IMHO that should have the same language as the web interface language for that account. What audio files did you install? That might be related...
-
I've check the report. During the call, three SIP packets were received by server from the calling phone with a '200' status code. The outgoing IP did not change.
Well, SIP packets don't count for RTP. By receiving the SIP packet the PBX cannot learn the address (especially the port number) of the device.
More over this happened only during the first call(~24hrs gap between the last usage). After that I had 5 calls with intervals of more than 30m, it worked fine.Hmm. No pattern to me...
We are using an LinkSys RVS4000. Is this an issue causing device?Not that I am aware of. There are so many devices in the market. If you have another router, I would just try that other one to see if that makes a difference.
I'm sure we aren't using STUN, how do i confirm this?Check the phone settings. Or check the SIP packets coming from the phone. If they appear to have public IP addresses (while the phone has a private IP address), then there is probably someone messing with STUN.
-
I've Captured some calls using WireShark.
For the call where we do not hear audio. We've found the RTP packets going to the phones IP (an private IP address) instead of the public IP of the firewall, behind which we have the IP-Phones.
The media was coming fine from the trunk provider, but the RTP packets between the server and the IP-Phones was being sent to an private IP address (192.168.1.x).
For the call that work fine, it goes to a socket on the firewall only.
It is okay if the PBX first attempts to send the RTP to a private address. As soon as it gets RTP from another location it will change the destination. It seems that no RTP packet makes it from the phone to the PBX.
What firewall are you using? Maybe all ports are in use? Is it a "low-quality" firewall? We have seen products that just have NAT 32 entries.
Are you using the old troublemaker called STUN on the phones? The problem with STUN is that it is so unstable. 99 % of the cases it works and troubleshooting the other 1 % is extremly difficult. That is why we recommend not to use STUN.
-
So I manually set the phone to not filter and reboot the phone and the PnP setting overwrites it.. so there has to be a setting in the PnP I can modify..!?
Just add a file named "snom_3xx_custom.xml" into the html directory with the following content:
<?xml version="1.0" encoding="utf-8"?> <phone-settings> <filter_registrar>off</filter_registrar> </phone-settings>
That will provision this setting in addition to the settings that are already automatically provisioned.
-
what version am i waiting for?
Something like 7.1.37. There are already builds available, but not released yet.
-
This is true except it worked fine in 3.0.1
Yea, we did make a change in the stared lines. The fix was related to the dial tone which was not played back when the phone seized a line. However, it requires also a new software on the phones. Maybe wait a little with the upgrade until the phone firmware is released.
-
I applied the update (3.1.1.3110) on Windows 2008 Server x64. Whenever my Polycom SoundPoint IP 670's were powered on, they crashed just as they started the SIP application (going into an endless reboot cycle). We have BootROM 4.1.2.0037 and SIP 3.1.1.0137. I switched back to 3.0.1.3023 (Win32) and all is well again (other than the problem we reported with not being able to create multiple CO lines but that was happening in both versions).
Whow. Can you send me the generated files in a PM for plug and play?
-
Ok here is what I figured out the problem was, but need helping finding a way around it
We have the name of the extensions W: Office 1
the termination provider has declined it due to the :, once I remove : everything works good..
Would anyone know how do i send the caller ID in quotations? supposedly that should work even there is a :
Looks like the "TSG_Global_GW" has a little issue with RFC3261:
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
Unfortunately, the PBX just follows the RFC rules; there is no way to perform a special escaping of characters. The best solution if the gateway gets a software update with a fix.
BTW is seems that the audio_moh files are not installed ("Could not open WAV file audio_moh/noise.wav").
-
Some time ago on version 2.0 and with a previous ITSP we had the following feature working fine. An outside caller would dial a DID and the call if redirected to the person's Cell Phone would see the Caller ID of the caller and not their office or extension.
Somewhere in the middle of last year we upgraded that client to V3.x and that feature quit working, we didn't spend a great deal of time to address the trouble, but simply put them back on 2.x
That client has since moved to another ITSP using BroadSoft V14 broadworks, and we upgraded them the the latest 3.x and that old problem reappeared.
If we set trunk the remote party-ID (the calls are not forwarded) RFC3325 P asserted forwards the calls, but we see the trunk caller ID and not the original caller.
The ITSP is quick to wash their hands and lay blame on PBXnSIP, but maybe it's just us and how we have set this up.
We are exciting about partnering with the ITSP in our market, but need to overcome a few hurdles starting with this one....
Any help or feedback from someone on a Broadwords (CBEYOND) with this working as expected would be wonderful....
The standards for presenting the caller-ID are clear, just check out RFC3325. And BroadSoft can for sure support RFC3325.
The root of the problem is that the carriers are simply scared that customers are using this feature for fraud. How can a carrier make sure that you don't put some funny Caller-ID in and let people call you back on numbers that cost a lot of money?
Either the carrier has to trust that pbxnsip software does not do such a bad thing or there needs to be an association between an inbound call and a resulting outbound call. For example if someone calls into the PBX, and the PBX forks the call off to a cell phone, then the carrier could say "okay, those calls belong together" and present the original caller-ID (which is still in the From header).
If we need to present some kind of token that makes this call-association easier and obvious, we'll happily put that in! I am serious!
-
Ummm unless you have a hundred phones
does this include recording? I assume so.
No, recording is not affected. That already runs in a seperate thread.
-
to do what i want...be able to transfer to voicemail of extensions beginning with 1, what needs to be edited?
Well, if you want that people can dial extensions starting with "1", then you can not use the "1" as the prefix for national numbers (11-digit dialling). You can tell customers to use something like "91xxxxxxxxxx" or "9xxxxxxxxxx" (9 would be for "outbound line"). However this will bring trouble with the address book, as address book entries on the phone will not start with "9" in the beginning. And of course you need to change the dial plans The pattern for this would be below.
[1-7]xx|8[1-7]xx|[2-9]11|9,1xxxxxxxxxx|9,011x.|*x.
You can change that in the dialplan.xml file attached above. The comma AFAIK will give you secondary dial tone.
-
ok i have turned that off but possibly in the future it should be an option to be able to write the log files...
We have an idea how to avoid this, but obviously it needs to be offloaded into another thread and at the moment we don't want to bring in any risks (3.1).
-
On the hosted platform with multiple domains is there a way of restricting what values of ANI a domain administrator can set for each extension to prevent them spoofing other customers caller-ID?
Not yet, but that is an excellent point.
-
IP Address Conflict is not a case, we've reviewed the configuration several times. Also, we have Phones, not within a single location or network.
We've not loaded a certificate on the server, but still we'll open the port.
I'll check the Codec Mismatch section. This may be related to us.
Secondly, when receiving a call, the first call has no audio, but the immediate next call works fine. What could be causing this?
It really makes sense to use a tool to troubleshoot this. Try Wireshark, run it on your PBX. This will tell you if the PBX gets media when it should.
Otherwise we are just shooting in the dark!
-
If you do not have this file in html folder already, you can just copy it as is. No need to edit the file.
Well, that is the default file which is already included in the 3.1 build. If you want to have a different behavior than now, then you need to edit it.
-
It is not clear what is causing this. But one potential reason has been identified. When you are logging to the file system, that write/append operation may block the RTP thread. Unless you are tracking something down you should not write log files to the file system. Internal logging to the web interface is fine.
-
I think i posted this somewhere else but wanted to start a new thread.
with 3.1.1 and a snom phone 7.1 or 7.3 firmware. PNP config co1 co2 co3 emulation
press any digit 6 for example and notice co1 LED light up. it also lights up everyone else phone. why?
if you call an internal extension like a conference extension, co1 lights up as well.
hang up the phone and press another digit co2 lights up (and co1 turns off)
this seems to be a bug, which prevents me from rolling out 3.1.1
That sounds like you are using the shared lines on keys. There is actually a newer version available for snom phones (which is not released yet) that fixes a couple of issues with shared lines. Shares lines are still bleeding edge it seems.
-
Simultaneous ring to a mobile phone has one way audio most of the time even with PBXnSIP version 3.1.1.3110. This issue is even worse if you have a virtual number and someone calls the virtual number and you answer on your mobile. In that case you will always get one way audio.
Another issue with PBXnSIP and ViaTalk's new servers is if you have another device on you network like and IP phone or a soft phone directly registered to ViaTalk and you call their support number you will always get one way audio. Calls to other number and your ViaTalk trunks work fine.
Beware ViaTalk is getting very uncooperative if they think they are trouble shooting PBX issues. My last issue they insisted that I shut off the PBX and register my line to a soft phone. Only then would they run a trace or do any testing of my one way audio issue when answering a ViaTalk Simultaneous ring call on my mobile phone. Unfortunately for us they were right. The problem vanished when the trunk was registered to a soft phone.
The problem is that ViaTalk obviously uses the SIP proxy model as interface to the customer. That has a couple of problems. First, you can see the Record-Route headers, which is a open door for DoS of their service and a interop nightmare because of all the devices out there that have problems with strict and loose SIP routing. The next problem is that SIP UDP packets can easily get bigger than 1492 bytes, many routers cut additional bytes of the UDP packet off. Maybe the softphone ignoes that and thats the reason why it works with the soft phone but not the PBX.
I don't blame ViaTalk for being uncooperative. It is simply impossible to troubleshoot such complex problems.
Let me say it again, session border controllers are worth every single cent!
Calls Declined
in ITSP's
Posted
I would just reduce the volume of the noise. Having completely silent line is irritating as users believe the line is "dead". That was one of the findings when they introduced ISDN in Europe. People got confused when they did not hear anything (no kidding).
That is probably why the name is "comfort noise"...