Vodia PBX
-
Posts
11,085 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
TLS
in VoIP Phones
I try to make TLS session whit Eyebeam softphone, but pbxnsip server (WIN XP version)disconnect handshake after client key exchange packet. It send Server cerificate corretly
I install server ceritficate and private key whit PEM format.
Server side log do not have any errors only "SIP port accept from <IP address>" message.
Any idea what goes wrong?
The eyebeam is strict with the certificates. You can test if the eyebeam would accept it by doing to the PBX web interface with the Internet Explorer and see if it complains about certificates. You may have to import the root certificate into Explorer. If Explorer does not complain any more, then give it another try with eyebeam.
-
Now all I am worried ...
It is always a good idea before an upgrade to backup the old directory. Then no matter what happens, you can move back.
Apart from that, we try to keep upgrades (even to a possible 3.x version) backward compatible.
-
[1] 2008/03/05 16:29:03: SIP Tx tcp:172.16.1.62:2230:
SIP/2.0 200 Ok
v: SIP/2.0/TCP 172.16.1.62:2230;branch=z9hG4bKb3665a92
f: <sip:+3269669526@ip-pbx.lcs-test.net;user=phone>;epid=370E1B7147;tag=a5116e1362
t: <sip:100@172.16.1.68;user=phone>;tag=2c70c096ce
i: e43582cd-fc5d-47d1-87ac-9576423edebe
CSeq: 8 BYE
m: <sip:Anonymous@172.16.1.68:5060;transport=tcp>
User-Agent: pbxnsip-PBX/2.1.6.2448
RTP-RxStat: Dur=11,Pkt=0,Oct=0,Underun=0
RTP-TxStat: Dur=9,Pkt=120,Oct=20640
l: 0
That means, the PBX does not receive an media from the mediation server. That is really strange. Maybe a firewall issue? Can you run Wireshark on the mediation server and see if it tries to send media? Maybe there is something in the log of the mediation server that says why it does not send any media. Maybe a codec mismatch?
-
Are you running the PBX and OCS on the same server? I remember that was an issue... The other thing is that the static registrations need to be set up as well on OCS, otherwise you have a call loop (visible in the call log).
-
Is that the same issue we are having with the prerilli phones, not stopping to ring?
I would say: most probably!
-
Generally. Or it means people have gotten numb to posting issues. I want to make sure. ;-)
Okay, we found an issue... If the PBX calls a phone that is reacting a little bit slow on UDP transport layer, it does not cancel that call later (for example in a hunt group). This could lead to a lot of phones ringing. It is fixed in 2449. Unfortunately, we at this point have only Windows and SuSE Linux, the other versions will follow soon as the servers are up again.
-
It used to always play music on hold. This is a supervised transfer, where the caller hears hold music while the server dials a new call, waits for confirmation from the called party, then connects the two parties. so it's not strictly a redirect. i was a little surprised that we were getting pbxnsip music on hold from a MSS supervised transfer, but that is how it used to work.
Oh yes:
[6] 2008/03/05 11:32:39: Call hold from trunk
Well, there was a change in functionality. We had a customer that convinced us that it is good practice to treat call hold on a trunk differently.
v=0 o=- 0 0 IN IP4 192.168.54.200 s=Microsoft Speech Server session c=IN IP4 192.168.54.200 t=0 0 m=audio 13440 RTP/AVP 0 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendonly a=ptime:20
If I read RFC3264 correctly, the speech server says "I will only send you media", and the PBX then would just play the music back. It would be very interesting to know if the server really sends some media during that time, and the second question would be if that is actually music. Maybe there is a setting on the Speech Server that defines how to provide music on hold?
-
After upgrading to the latest version of PBXNSIP, we are no longer getting hold music when we do a supervised transfer. As you can see in the call log below, pbxnsip is not attempting to play moh.wav, but it does say "call hold from trunk". We haven't changed anything in our application, just upgraded to the latest version of pbxnsip. Any ideas?
You mean the PBX plays noise after receiving the 302 from the speech server? That sounds perfectly okay to me...? I can't imagine that a redirect would cause music on hold even in older versions.
-
I haven't seen many posts pertaining to the instability of 2.1.6.2448
That is generally good news
-
Did you see http://wiki.pbxnsip.com/index.php/Office_C...ications_Server? Are you using static registrations?
-
If you are already running a 2.x version you can just exchange the executable. See http://wiki.pbxnsip.com/index.php/Installi...Windows#Upgrade
-
I see...basically I just need to create a signup page for our customers to have an account created instantly.
I suppose cURL would be the way to go but I'm not sure what URL params I can pass to the domain setup script, etc
The beauty of curl is that you can just watch the traffic between the browser and the server and then you know what parameters you need to send...
-
The PBX is set to use th MST/MDT timezone, however the Polycom generated sip config file does NOT populate with the proper data as it should have the element indicated to be set as "8" but it is blank?
Well for MDT we have:
<BR> <zone name="MDT"><BR> <description>Mountain Time Zone</description><BR> <gmt_offset>-25200</gmt_offset><BR> <dst_offset>3600</dst_offset><BR> <dst_start_day_of_week>1</dst_start_day_of_week><BR> <dst_start_month>3</dst_start_month><BR> <dst_start_time>02:00</dst_start_time><BR> <dst_start_week_of_month>2</dst_start_week_of_month><BR> <dst_stop_day_of_week>1</dst_stop_day_of_week><BR> <dst_stop_month>11</dst_stop_month><BR> <dst_stop_time>02:00</dst_stop_time><BR> <dst_stop_week_of_month>1</dst_stop_week_of_month><BR> </zone><BR>
That means the daylight starts on the first day of the week, but not on the 8th day of the month. I think that is okay?
-
PBX version is 2.1.3.2316, polycom phones all on 2.2.0.
There were a couple of changes between 2.1.3 and 2.1.6 regarding the codecs, especially in the transfer scenario. I think 2.1.6 is much cleaner there, probably a SW upgrade fixes the problem.
-
Still don't get it. What time zone did you select? What version of the PBX?
-
In other words, there is no built in API
That is not true... There is a SOAP-based API, e.g. for settings extension parameters while the system is running. We don't promote it too much, it is very support intensive and the number of users that really need it is quite low.
-
Well, curl is a good start. There are SOAP requests that make it possible to do anything, but IMHO curl is much more simple and does the job.
-
I am looking for the settings in the web interface of the cs410 that will allow me to set what calls I would like to record. I have a windows version of this software and, I am able to navigate to the page that allows me to choose what type of calls I want to record. I am unable to find these options in the cs410 linux version. Am I just in the wrong spot or does this version not offer the same options for recording calls?
Well the default license for the CS410 does not include recording - we simply suspect this will cause a lot of issues with people turning recording on and then one month later boom! the PBX dies and they ship the device back for repair.
-
The RAM is not the problem here. Recordings are written to the file system. The 410 has 256 MB (minus a few MB for itself), which could keep a couple of hours.
You can also use a sip URI to offload the recording to an external SIP-compliant recording system.
If you want to do serious recording, IMHO you must use a PC. The embedded system is not good in storing large amounts of data and it is not easy to pull the data off the box.
-
Did you see http://wiki.pbxnsip.com/index.php/Recording?
-
should be:
tcpIpApp.sntp.daylightSavings.start.dayOfWeek="2"
Hmm. 1 should be Sunday. Do you mean that for Polycom "2" is Sunday???
-
We don't run it here, but Vista was running great so far. Especially if you use IPv6.
-
Does the White CS410 with a single LAN port accept the latest CS410 OS posted
So far it seems there is a problem with the FXO driver, we are looking into it right now. So I would say better don't upgrade right now.
-
Whow, either that system is heavily overloaded or there might be a problem with UDP transport. Could packet loss be a problem? Of course, Wireshark will be able to point the problem out.
Expired
in General Setup
Posted
Whow, that is a lot. It seems there is a problem with the proper disconnect of the call, maybe a SIP interop problem. Maybe it makes sense to catch the SIP traffic and pick one specific Call-ID. Then it should be possible to find out what the problem is.