Andrew D Kirch Posted June 8, 2007 Report Posted June 8, 2007 I'm getting an RTP timeout after putting calls on mute for between 2.5 and 3 minutes on PBXnSIP version 2.0.3.1715. Would others please confirm if they're seeing this. After the timeout the call obviously drops. This was discovered by a user listening to a conference on mute. Quote
jholland Posted June 20, 2007 Report Posted June 20, 2007 I have also noticed that when a caller is placed on HOLD for more than 2.5 to 3 minutes that the PBXNSIP will hang up the call. I believe there is some kind of timeout within the software that drops calls that are not transmitting two way audio. I'm getting an RTP timeout after putting calls on mute for between 2.5 and 3 minutes on PBXnSIP version 2.0.3.1715. Would others please confirm if they're seeing this. After the timeout the call obviously drops. This was discovered by a user listening to a conference on mute. Quote
Vodia PBX Posted June 20, 2007 Report Posted June 20, 2007 There is a difference between mute and hold. In mute, there is no signalling and there is (for the PBX) no difference in pulling the plug. That is why the PBX also pulls the plug relatively quickly. In hold, the PBX sets that timeout to a long value like one hour. If someone is on hold longer than one hour, well then the PBX will also finish this call. IMHO the right way to implement mute is to send silence indicator RTP packets every couple of seconds (because the stream is silent!). Then the connection will stay alive. Some phones are doing this. Quote
cfcs Posted August 9, 2007 Report Posted August 9, 2007 I'm having the same problem with call dropping if muted longer land 2.5 minutes. I'm using Snom 320 phones with latest firmware. We really need to have mute availbe for confernce calls. What's the best way to make it so it does not drop the calls. Quote
hosted Posted August 17, 2007 Report Posted August 17, 2007 you know what would be nice is to have a page dedicated to timers.. so we can set these timers ourselves. Quote
Model12 Posted September 20, 2007 Report Posted September 20, 2007 We have the same problem and it is hurting us. The call park blackhole has caused our users to start using HOLD instead. But ... after 2 minutes and 2 seconds the call is dropped. I thought they were crazy ... but ... we tried it ourselves and blame ... no more caller. We're using Polycom 430s and only one release down from the latest PBXnSIP ... We'd be on the latest greatest but for some reason when we drop in the newest exe the webpages in PBXnSIP don't draw correctly. Any idea how to stop a caller from being disco'd while on hold for 2 minutes? Quote
Vodia PBX Posted September 20, 2007 Report Posted September 20, 2007 Version 2.1 has global settings called "timeout_hold" and "timeout_connected" which can be manually edited in the pbx.xml config file. You can set it to any value bigger than 10 seconds. Depending on the phone and the software version, the phone should send some kind of keep-alive traffic during mute. Silence does not mean there is no RTP! Quote
Model12 Posted September 21, 2007 Report Posted September 21, 2007 When we drop in the new version exe (no real installation) ... the webpages no longer draw correctly. We can't admin the box anymore cause there is little to click on. What is the correct way to upgrade from v2.0? (sorry for such a simple question) PS: We have an "aftermarket" html directory added to our 2.0 install for a 4 digit North American dialplan. Maybe that is mucking something up with the webserver? Quote
Vodia PBX Posted September 21, 2007 Report Posted September 21, 2007 Well, 2.0 had hand-crafted images for the menus on the top. That was obviously not very smart and has been replaced in 2.1 with a simple html interface that just uses a few background images (some people were asking if we can change the color and the answer was "ouch"). F5 is your friend now. If you use your own design, most of the logic should still work, but just make sure that the cor_xx.gif images and the main_*.gif stuff is moved away. Sorry, but in this case it is really hard to stay 100 % backward compatible... Quote
phsean Posted September 24, 2007 Report Posted September 24, 2007 I can't explain it, but I know what the problem is that Model12 and I have been encountering with the web interface. We had a lang_en.xml file provided by our reseller in the html directory... we put it in there when we were messing with adding a 4-digit extension dialplan. To be honest, we don't know exactly what the custom lang_en.xml does that the built-in one does not, so we might have hurt some stuff without knowing it. But we can see the web interface buttons at the top to nav around the new version, now. Hope it helps. Quote
Vodia PBX Posted September 25, 2007 Report Posted September 25, 2007 Yea if you are moving to 2.1, check the html directory... If you really need to modify content, it is now time to merge in changes. Before that, make a backup... Quote
Model12 Posted September 26, 2007 Report Posted September 26, 2007 The only thing we utilize in the html directory is the dialplans.xml file and we've changed one or two setting in the polycom_sip.xml file. I would love to merge content but all I can do at the moment is replace the 2.0 exe with the 2.1 exe. Is there a 2.1 "installer" that will give me all the new content so that I can find the xml files and merge some of the diff? Thanks! Quote
Model12 Posted September 26, 2007 Report Posted September 26, 2007 I guess what I'm asking is this: To merge content ... I'd expect to be able to find a file such as: dialplans.xml in the new 2.1 version. Compare the differences between my PBX\html\dialplans.xml and begin to fixup differences ... after making a backup ... {;-) Is it just that simple? I cannot find these xml files on the 2.0 version ... Are they simply embedded in code but now seperated as independant files in 2.1? Quote
Vodia PBX Posted September 26, 2007 Report Posted September 26, 2007 If you only have those files there should be no problem. These files have nothing to do with the appearance of the web interface. Apart from the browser's cache. Usually pressing F5 should solve that problem, maybe you need to explicitly delete the cache. Quote
Model12 Posted September 26, 2007 Report Posted September 26, 2007 The files we have in that directory also included: lang_en.xml lang_de.xml But we didn't modify those ourselves ... <edit> With the lang_en.xml file in the html dir the web interface won't work correctly with version 2.1 Without it the web interface looks fine but the time is off on the phones. <end edit> But ... with that file removed then phones display an incorrect time. I think that file was given because of the following entry: <file name="dialplans.xml"> <item id="domdef">Domain Default</item> <item id="enter">User must press enter</item> <item id="usa4">North America (4-digit extensions [2-7]xxx)</item> <item id="usa3">North America (3-digit extensions [2-7]xx)</item> <item id="usa2">North America (2-digit extensions [2-7]x)</item> <item id="europe4">Europe (4-digit extensions [2-7]xxx)</item> <item id="europe3">Europe (3-digit extensions [2-7]xx)</item> <item id="europe2">Europe (2-digit extensions [2-7]x)</item> </file> Some nice fella at PBXnSIP gave us an option in our dialplan.xml file for a 4 digit ext which is great cause that is what everyone was familiar with. Any ideas what we should do ... is there a "newer" lang_en.xml file for the 2.1 version that we could use to incorporate the 4 digit dialplan we need or do you simply think that clearing th browser cache and reinserting this file would work? PS: Thanks sssooo much for the help! Quote
Model12 Posted September 26, 2007 Report Posted September 26, 2007 I said something wrong in the above post and then realized I could edit the post ... Quote
Vodia PBX Posted September 26, 2007 Report Posted September 26, 2007 The 4-digit dial plans should be also there in the latest lang_xx files, so it should be okay to move them out of the way. Quote
Model12 Posted September 26, 2007 Report Posted September 26, 2007 I also edited the dialplan.xml file to give the polycom phone a different dial plan as follows: [2-6]xxx|7xxxx|[2-9]11|91xxxxxxxxxx|9[2-9]xxxxxxxxx|*xx[2-6]xxx|xx.# Basically ... just so they don't have to press send. So ... I don't think I can drop the dialplan.xml file until I'm smart enough to know how to put that into the phone so they can be lazy ... {;-) Currently ... here's what's in the html directory: polycom_sip.xml - I've modified a few settings to persist volume and what not ... dialplans.xml - As stated above this was given to us to facilitate 4 digit plans but I also changed the default vendor pattern lang_de.xml - prolly not needed since we're silly American's (we can't help it) I had the lang_en.xml file but had to rename that so that the web interface would draw. The by product of that was the phones now read GMT time even though in the System Settings it says Eastern Time Zone. Right now the phones should say 4:00pm'ish but they show 8:00pm'ish. Quote
Model12 Posted September 26, 2007 Report Posted September 26, 2007 Ok ... here's what I did ... I noticed that lang_en.xml referenced a file named timeszones.xml ... so ... I made one of those in the html directory as follows: <?xml version="1.0" encoding="utf-8"?> <timezones dict="timezones.xml"> <zone name="EDT"> <description>Eastern Time Zone</description> <gmt_offset>-14400</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>4</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>1</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>10</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>Last</dst_stop_week_of_month> </zone> </timezones> After restarting the server ... only two timezones showed up in the web interface GMT and the one above. But ... the phones would not stop reading GMT time. So ... I hacked the polycom_sip.xml file by taking out the following params: tcpIpApp.sntp.address="{TZ NTP-Adr}" tcpIpApp.sntp.gmtOffset="{TZ GMT-Offset}" tcpIpApp.sntp.daylightSavings.enable="{TZ DST-Enable}" And hardcodding them to the following (please hold you're boo's until later): tcpIpApp.sntp.address="pool.ntp.org" tcpIpApp.sntp.gmtOffset="-18000" tcpIpApp.sntp.daylightSavings.enable="1" This worked ... So ... the only answer I have is that possibly the {TZ NTP-Adr}, {TZ GMT-Offset} and {TZ DST-Enable} are no longer the correct replacement params? Any idea what the heck I'm saying? Quote
Vodia PBX Posted September 27, 2007 Report Posted September 27, 2007 Hmm. Probably a problem with the case. The TZ parameters must be lower case, better keep the whole parameters lower case. Quote
Model12 Posted September 27, 2007 Report Posted September 27, 2007 Wow! Of course I didn't make that file ... so ... I have no idea if there are newer "replacement variables" added/changed/deleted. Is there any way you could be so kind as to point me to the latest polycom_sip.xml version that PBXnSIP is utilizing? Right on! PS: Thanks much! Quote
Model12 Posted September 27, 2007 Report Posted September 27, 2007 Here's what I think will help out alot: If someone at PBXnSIP could provide me with the latest polycom_sip.xml file that matches up better than my current version ... Then we can "sync" our couple changes with your version. Afterwhich ... I think we can eliminate the dialplans.xml file by hardcoding this value in the new polycom_sip.xml file ... Truthfully ... I don't see a problem with replacing your parameter with a hardcoded value for our phones dialplan. All that should be left behind in the html dir is the polycom_sip.xml file used to provision phones. This should make future updates much much easier because we're not messing with any of the underlying PBXnSIP goodies. Make sense? Quote
Model12 Posted October 3, 2007 Report Posted October 3, 2007 I finally took the time to merge our changes and we just implemented ... So far so good. Thanks! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.