Are you suffering any noticeable problems as a result?
Are you using TCP for SIP?
↧
Error[6641] chan_sip.c:4273 Serious Network Trouble; __sip_xmit returns error for pkt data
↧
System updates gets exception even after reboot
Andrew i have followed your solution and it did work. thanks for that. however i have now lost connection to the web interface. i am getting an ERR_CONNECTION_REFUSED on the browser, although i am on the local network.
calls are processed normally.
any ideas please, since i have not yet found on the forum a solution that works, and i would not really like to experiment.
thanks
↧
↧
System updates gets exception even after reboot
Hi!
For this particular fix you not only need to have DAHDI hardware but actually have to have Sangoma hardware which, if I recall correctly, is not what you have in your system (unless I am mistaken you use Digium inspired hardware, no?).
I am not sure this fix would still work after the recent updates though... Chances are it might not...
What I did in my case was switch to a kernel those package supported... All it required was to edit the grub.cfg file (IIRC) and indicate that the default was the previous kernel...
Now I have a question, do you have Sangoma hardware in that box or not???
I was sure that you didn't so the fact that you have or don't have the right Wanpipe drivers should not matter as these are for Sangoma hardware.. This seems to suggest that if there is a problem with the Wanpipe drivers even people which don't have Sangoma hardware are affected which should not be the case...
Non-Sangoma hardware should not depend on whether Sangoma hardware drivers are initializing correctly or not...
Some of those problem seems to be related to the underlying OS changing enough that the step at which the DAHDI hardware should initialized is no longer the same as it was in the past...
With Sangoma hardware if the network is not up when the driver is loaded it fails with a timeout after something like 4 minutes...
Another problem in your case seems to be that the DAHDI driver initialization seems to have a big dependency on the Sangoma Wanpipe drivers initialization, something it should not have...
There's something unclear in your description but it looks like what got things working for you was that the Wanpipe drivers were broken yesterday night... It's almost as if that's what is needed for your Digium derivative card to be initialized properly...
I think (gut feeling) that under normal circumstances the Sangoma Wanpipe drivers need to be initialized first, then DAHDI but that DAHDI initilization should not depend on whether the Wanpipe drivers have been properly initialized and, right now, it seems to depend on it in some way...
From what you posted it sounds like what is making things work for you is having broken Wanpipe drivers with your Digium card derivative.
What is making things work for me is, obviously, having working Wanpipe for my Sangoma card...
Something somewhere in those scripts is enforcing a strong dependency between Wanpipe drivers initialization and DAHDI driver initialization which definitely should not be there...
Good luck and have a nice day!
Nick
↧
System updates gets exception even after reboot
Hi Leon!
I don't remember what hardware you have...
Do you have any DAHDI hardware and if so, which?
My guess is that if you have DAHDI hardware it's not hardware which use the Sangoma Wanpipe drivers as you would have the same problem I do...
If you don't have any DAHDI hardware at all I think you can update those safely but if you have anything else wait until both chaser and me report that things are working for them...
Good luck and have a nice day!
Nick
↧
System updates gets exception even after reboot
Many thanks for the detailed feedback.
I can confirm that I do NOT have any Sangoma hardware. I was pointed to the wanrouter start / stop level mod by @tm1000, which is why I tried that.
I accept that the hardware I am using is NOT digium manufactured, but there is another member (@glew) who is reporting exactly the same symptoms as me, and he has indicated that he is using genuine digium hardware.
I'm not sure if he's tried his system with the 'broken' wanpipe driver. I saw him posting today asking how to go about the big update that came out the other day. However, I guess that if he does the update now, he'll miss out on the broken wanpipe driver, so he still might not get DAHDi to work (unless he then downgrades wanpipe to the broken version, as I have done).
↧
↧
FreePbx issue usa number
Hi!
Do you have other DIDs (ie phone numbers)?
If you do, do you ave an inbound route for each one of them or an ANY/ANY one?
(I don't use ANY/ANY routes but I believe the order in which any additional routes are declared when those are present is important and that the ANY/ANY route would need to be the last one...)
What you want to do is to add an Inbound route for that DID and set it's Destination to the extension you want to have it forwarded to...
The fact that it's in another country is unimportant, you just need to make sure the DID number you put in your Inbound route matches what your provider provides you with.
Some providers might provide you with something in the format 15555551212 while others might provide it in the format 5555551212, you have to make sure you use the right one....
Good luck and have a nice day!
Nick
↧
System updates gets exception even after reboot
You can remove wanpipe if you wish. It's not needed since you don't have wanpipe.
↧
System updates gets exception even after reboot
Ok. I'll try that and see if it works. Thanks
Edit: Oooh. I'm not sure that's going to work...
[root@freepbx ~]# yum remove kmod-wanpipe.x86_64 wanpipe.x86_64
Loaded plugins: fastestmirror, kmod, versionlock
Resolving Dependencies
--> Running transaction check
---> Package kmod-wanpipe.x86_64 0:7.0.20-9.sng7 will be erased
--> Processing Dependency: kmod-wanpipe for package: freepbx-14.1-1.sng7.noarch
---> Package wanpipe.x86_64 0:7.0.20-9.sng7 will be erased
--> Running transaction check
---> Package freepbx.noarch 0:14.1-1.sng7 will be erased
--> Processing Dependency: freepbx for package: sangoma-pbx-1708-1.sng7.noarch
--> Running transaction check
---> Package sangoma-pbx.noarch 0:1708-1.sng7 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
========================================================================================================================
Package Arch Version Repository Size
========================================================================================================================
Removing:
kmod-wanpipe x86_64 7.0.20-9.sng7 @sng-pkgs 36 M
wanpipe x86_64 7.0.20-9.sng7 @sng-pkgs 29 M
Removing for dependencies:
freepbx noarch 14.1-1.sng7 @sng-pkgs 163 M
sangoma-pbx noarch 1708-1.sng7 @sng-pkgs 8.0 k
Transaction Summary
========================================================================================================================
Remove 2 Packages (+2 Dependent packages)
Installed size: 228 M
Is this ok [y/N]:↧
System updates gets exception even after reboot
What hardware do you have
Can you run
Uname -r
↧
↧
System updates gets exception even after reboot
[root@freepbx ~]# uname -r
3.10.0-693.2.2.el7.x86_64
[root@freepbx ~]#It's running on a Dell Optiplex 755
↧
System updates gets exception even after reboot
Hi!
The problem is pretty much related right now which is why he referred you to my ticket but under normal circumstances your DAHDI card initialization should not depend on the Sangoma Wanpipe drivers initalization...
My Sangoma card needs both to work but in a system which doesn't have Sangoma hardware your DAHDI card initialization should not depend on proper (or improper!) Sangoma Wanpipe driver intialization and right now it looks like it is the case...
I believe this whole setup predates Schmooze becoming Sangoma so Andrew, Bryan, Rob, etc...are only trying to make right something they had more than likely no say in how it was initially setted up...
I don't think the current problem is related to this and your Digium derivative card seems to behave pretty much like the real hardware (unless later proven otherwise 
)...
Right now I would not suggest that someone who has DAHDI hardware of any kind update unless (s)he is OK with having some possible downtime and knows how to revert things to get her/his system back to working order...
Good luck and have a nice day!
Nick
↧
Yealink T4XG phones will not autoprovision over HTTPS with FreePBX 14
Hi!
Are they in the same subnet? If they are, do they have matching subnet masks (I once saw pretty weird problems caused by this...).
Good luck and have a nice day!
Nick
↧
Error[6641] chan_sip.c:4273 Serious Network Trouble; __sip_xmit returns error for pkt data
I've tried to set on and off, and got same result. 
And yes, we are sffering issues, like some daemons stopping: ucp, xmpp, zulu amd restapps
Any idea?
↧
↧
Error[6641] chan_sip.c:4273 Serious Network Trouble; __sip_xmit returns error for pkt data
Sorry to hear. We're not using UCP, but seem to only have them on the servers in the environment explained here:
But here's a post were some other users talk about it seeming to be related to UCP somehow:
↧
Incomming Calls Going Nowhere
We are still having these issues, and they seem to be causing FRACK Errors, which often result in Asterisk crashing. Anyone else?
Here I posted our problem in detail: https://community.freepbx.org/t/consistent-asterisk-freepbx-crash-issue/43682
↧
System updates gets exception even after reboot
I hope no-one thinks I'm being difficult. I really appreciate all the work and support that everyone is putting in to give me and the whole community a free pbx system. I am really grateful of this. In return, what I am trying to do is provide as much information as possible to aid fault finding, so that everyone can benefit from a fully debugged system.
↧
Yealink T4XG phones will not autoprovision over HTTPS with FreePBX 14
No, The phones are in my office, the PBX (all three examples) is hosted on Vultr in the Chicago Datacenter.
↧
↧
Outbound calling doesn't work
Hey guys, I'm having a weird problem with one of our PBXs. It's running FreePBX 14.0.1.4, and VoicePules is my SIP provider. Inbound calling and internal calls work fine, but any calls to the outside world fail saying the call cannot be completed as dialed. This WAS working and then spontaneously stopped. When I run asterisk -RvvvvvT and make a test call here's what I see:
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
0x2cd3f60 -- Strict RTP learning after remote address set to: 10.99.79.10:8000
-- Executing [MYCELL#@from-internal:1] Macro("SIP/503-00000011", "user-callerid,LIMIT") in new stack
-- Executing [s@macro-user-callerid:1] Set("SIP/503-00000011", "TOUCH_MONITOR=1507314122.17") in new stack
-- Executing [s@macro-user-callerid:2] Set("SIP/503-00000011", "AMPUSER=503") in new stack
-- Executing [s@macro-user-callerid:3] GotoIf("SIP/503-00000011", "0?report") in new stack
-- Executing [s@macro-user-callerid:4] ExecIf("SIP/503-00000011", "1?Set(__REALCALLERIDNUM=503)") in new stack
-- Executing [s@macro-user-callerid:5] Set("SIP/503-00000011", "AMPUSER=503") in new stack
-- Executing [s@macro-user-callerid:6] GotoIf("SIP/503-00000011", "0?limit") in new stack
-- Executing [s@macro-user-callerid:7] Set("SIP/503-00000011", "AMPUSERCIDNAME=jordan.pesavento") in new stack
-- Executing [s@macro-user-callerid:8] GotoIf("SIP/503-00000011", "0?report") in new stack
-- Executing [s@macro-user-callerid:9] Set("SIP/503-00000011", "AMPUSERCID=503") in new stack
-- Executing [s@macro-user-callerid:10] Set("SIP/503-00000011", "_DIALOPTIONS=Ttr") in new stack
-- Executing [s@macro-user-callerid:11] Set("SIP/503-00000011", "CALLERID(all)="jordan.pesavento" <503>") in new stack
-- Executing [s@macro-user-callerid:12] GotoIf("SIP/503-00000011", "0?limit") in new stack
-- Executing [s@macro-user-callerid:13] ExecIf("SIP/503-00000011", "1?Set(GROUP(concurrency_limit)=503)") in new stack
-- Executing [s@macro-user-callerid:14] ExecIf("SIP/503-00000011", "0?Set(CHANNEL(language)=)") in new stack
-- Executing [s@macro-user-callerid:15] GotoIf("SIP/503-00000011", "1?continue") in new stack
-- Goto (macro-user-callerid,s,29)
-- Executing [s@macro-user-callerid:29] Set("SIP/503-00000011", "CALLERID(number)=503") in new stack
-- Executing [s@macro-user-callerid:30] Set("SIP/503-00000011", "CALLERID(name)=user.name") in new stack
-- Executing [s@macro-user-callerid:31] GotoIf("SIP/503-00000011", "0?cnum") in new stack
-- Executing [s@macro-user-callerid:32] Set("SIP/503-00000011", "CDR(cnam)=user.name") in new stack
-- Executing [s@macro-user-callerid:33] Set("SIP/503-00000011", "CDR(cnum)=503") in new stack
-- Executing [s@macro-user-callerid:34] Set("SIP/503-00000011", "CHANNEL(language)=en") in new stack
-- Executing [MYCELL#@from-internal:2] Set("SIP/503-00000011", "ROUTEUSER=503") in new stack
-- Executing [MYCELL#@from-internal:3] Set("SIP/503-00000011", "ROUTEUSER=503") in new stack
-- Executing [MYCELL#@from-internal:4] GotoIf("SIP/503-00000011", "1?notblind") in new stack
-- Goto (from-internal,MYCELL#,7)
-- Executing [MYCELL#@from-internal:7] GotoIf("SIP/503-00000011", "1?restrictedroute-cfcd208495d565ef66e7dff9f98764da,MYCELL#,2:outbound-allroutes,MYCELL#,2") in new stack
-- Goto (restrictedroute-cfcd208495d565ef66e7dff9f98764da,MYCELL#,2)
-- Channel 'SIP/503-00000011' sent to invalid extension: context,exten,priority=restrictedroute-cfcd208495d565ef66e7dff9f98764da,MYCELL#,2
-- Executing [i@restrictedroute-cfcd208495d565ef66e7dff9f98764da:1] Goto("SIP/503-00000011", "bad-number,s,1") in new stack
-- Goto (bad-number,s,1)
-- Executing [s@bad-number:1] Goto("SIP/503-00000011", "11,1") in new stack
-- Goto (bad-number,11,1)
-- Executing [11@bad-number:1] ResetCDR("SIP/503-00000011", "") in new stack
-- Executing [11@bad-number:2] NoCDR("SIP/503-00000011", "") in new stack
-- Executing [11@bad-number:3] Progress("SIP/503-00000011", "") in new stack
-- Executing [11@bad-number:4] Wait("SIP/503-00000011", "1") in new stack
0x2cd3f60 -- Strict RTP switching source address to 50.246.204.75:59572
-- Executing [11@bad-number:5] Playback("SIP/503-00000011", "silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer") in new stack
-- Playing 'silence/1.ulaw' (language 'en')
0x2cd3f60 -- Strict RTP learning complete - Locking on source address 50.246.204.75:59572
-- Playing 'cannot-complete-as-dialed.ulaw' (language 'en')
-- Playing 'check-number-dial-again.ulaw' (language 'en')
-- Executing [11@bad-number:6] Wait("SIP/503-00000011", "1") in new stack
-- Executing [11@bad-number:7] Congestion("SIP/503-00000011", "20") in new stack
[2017-10-06 12:22:10] WARNING[145465][C-0000019b]: channel.c:4861 ast_prod: Prodding channel 'SIP/503-00000011' failed
== Spawn extension (bad-number, 11, 7) exited non-zero on 'SIP/503-00000011'
I would think this means I have a problem with my outbound routes, but I can't find what it is. I've compared it to another PBX we have that's working fine and the routes look exactly the same. See attached:
Any ideas what's going wrong here?
↧
System updates gets exception even after reboot
LOL...
It would appear that you misunderstood my comment...
It was not targeted towards your comments but my own...
I think it's pretty apparent that I find the way I think it works (based on everyone's experiences) convoluted to say the least...
While all the people I named now work for the manufacturer of my DAHDI card I know that it was not always the case and they are just trying to fix something they were not the ones to break in the first place...
I said the comment to which I think you replied because I didn't to appear, myself, difficult...
That doesn't mean that I don't have an opinion on how things should be done I also understand why things don't always go smoothly...
Good luck and have a nice day!
Nick
↧
Outbound calling doesn't work
Well I think I figured it out. Apparently having the outbound route time condition set to "Permanent Route" isn't working. If I create a Time Group that's from 00:00 to 23:59 and assign that the calls go through.
So I guess the next questions is if this is a problem in FreePBX 14 (permanent route works fine on my other 4 PBXs that are on 13) or is there something busted with my install?
↧