Hi @inatechsol !
If you type this on your cli: tail -f /var/log/httpd/access_log | grep your-phone-public-ip-here
Do you see anything after you try to provision the phone ?
Did you whitelist your phone’s public ip on your PBX? Connectivity > Firewall > Networks > Add your phone’s public IP as trusted.
I see this written all the time and it makes ZERO sense. It’s like a car manufacturer saying they don’t support gas purchased at Shell. Gasoline is manufactured to specific standards to which the engine specifications conform. The same is (largely) true of SIP. From the point of view of your provider, they would have no way of knowing what SIP driver you are using locally on your PBX.
It’s probably more accurate to say that they won’t help you set it up if you’re using PJSIP. Customers who are being told this should be pushing back a little bit. PJSIP is the current supported driver, and refusing to support customers using it means they will eventually lose their Asterisk customers.
Seems to have been resolved by adding each subnet that the softphone will connect from to the networks setting
I will be the first to admit this is above my paygrade. But, I know when I setup one with AT&T a long time ago, when Pjsip was first put in, they kept rejecting everything being sent until I changed everything over to legacy sip. Firstcomm specifically said legacy sip on 5060 only. But, they have been useless as far as asterisk is concerned anyway - all thy could send was some old trunk config sheet from a trixbox screen shot…
i’m getting dropped calls after about 30 seconds between an android using GS Wave and OSX using Zulu.
ringing and voice works but only for about 30 seconds then the call is dropped
log in pastebin
Are you using a STUN server on Asterisk SIP Settings ?
This is the real problem. The provider put some minimal effort into a setup document 15 years ago and hasn’t looked at it since.
You can’t argue with success. If one works and the other doesn’t then you go with what works. The average user is probably not in a position to figure out why. You just need to know that using chan_sip today means starting out with a bit of technical debt that will need to be addressed eventually.
Asterisk PJSIP
here you can see i put the call on hold then it drops
[2020-06-05 13:06:52] VERBOSE[28555][C-00000006] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘PJSIP/401-0000000a’
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] res_musiconhold.c: Stopped music on hold on PJSIP/401-0000000a
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] bridge_channel.c: Channel PJSIP/401-0000000a left ‘simple_bridge’ basic-bridge <e4080602-eaed-4230-8785-99d7d427ee51>
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] app_macro.c: Spawn extension (macro-dial-one, s, 62) exited non-zero on ‘PJSIP/401-0000000a’ in macro ‘dial-one’
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] app_macro.c: Spawn extension (macro-exten-vm, s, 26) exited non-zero on ‘PJSIP/401-0000000a’ in macro ‘exten-vm’
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Spawn extension (ext-local, 400, 3) exited non-zero on ‘PJSIP/401-0000000a’
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Executing [h@ext-local:1] Macro(“PJSIP/401-0000000a”, “hangupcall,”) in new stack
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/401-0000000a”, “1?theend”) in new stack
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2020-06-05 13:07:23] VERBOSE[28619][C-00000006] bridge_channel.c: Channel PJSIP/90400-0000000b left ‘simple_bridge’ basic-bridge <e4080602-eaed-4230-8785-99d7d427ee51>
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/401-0000000a”, “0?Set(CDR(recordingfile)=)”) in new stack
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Executing [s@macro-hangupcall:4] NoOp(“PJSIP/401-0000000a”, "PJSIP/90400-0000000b montior file= ") in new stack
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Executing [s@macro-hangupcall:5] GotoIf(“PJSIP/401-0000000a”, “1?skipagi”) in new stack
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx_builtins.c: Goto (macro-hangupcall,s,7)
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Executing [s@macro-hangupcall:7] Hangup(“PJSIP/401-0000000a”, “”) in new stack
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] app_macro.c: Spawn extension (macro-hangupcall, s, 7) exited non-zero on ‘PJSIP/401-0000000a’ in macro ‘hangupcall’
[2020-06-05 13:07:23] VERBOSE[28555][C-00000006] pbx.c: Spawn extension (ext-local, h, 1) exited non-zero on ‘PJSIP/401-0000000a’
Understood. I remember AT&T not being much help either. Its amazing to me how the mainstream providers STILL don’t really support setting up their trunks on Asterisk - and I have been setting these up since 2006. Everytime I tell them its FreePBX over Asterisk - they glaze over and cant help. That’s AT&T, XO, Comcast (and now FirstComm). Thanks for replying - im still chasing this one…
This is a signalling issue. If you look at the invite for the call, you will see an INVITE being sent, a 200 OK coming back and the final required ACK is going astray. Possible NAT misconfig, possible router ALG.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
I think that’s because many front line or second tier individuals at providers don’t actually understand SIP at all, or the properties of the deployment of the provider. SIP is SIP in the end, and it’s really in how the deployment/policy is that alters the configuration. They just know the magic values to put in in some places for solutions that use them.
Speaking from the perspective of someone who has supported people across the forums as well as internally (Switchvox has been exclusively PJSIP since February 2016) I’ve found PJSIP not working generally comes down to three things:
sorry i’m not sure how i’d go about troubleshooting that
is there any other logs that would help suggest it was ACK or NAT?
See on your router if you have any SIP helper or SIP ALG and disable that.
A reboot does seem to bring the PRI back online. During the outage they can call extension to extension but no inbound calls reach the logfiles and outbound calls just die after this:
[2020-05-29 13:36:59] VERBOSE[7648][C-00003019] pbx.c: Executing [s@macro-dialout-trunk:26] Dial(“SIP/149-00003d04”, “DAHDI/g0/16193847180,300,Tb(func-apply-sipheaders^s^1,(2))”) in new stack
We have Dell Switches, PfSense Firewall and the router from our business isp
i’ve asked them if SIP helper or SIP ALG is set by them on the router
You lost me after “I think” lol. Just kidding. I get it, Reminds me of when everyone got together and agreed on an ical standard. Microsoft went off and did their own thing and didn’t conform to the standard they had agreed to. IBM did conform with Lotus domino. But the two have trouble talking to each other - IBM says "we followed the standard, we aren’t changing. Microsoft said. We’re Microsoft… it works if its all Microsoft… we’re not changing it.
they’ve confirmed “SIP is disabled by default on our CPE.”
When trying to log in into Zulu Desktop I got unknown error
I got zulu 15.0.58.3
asterisk 16.6.2
This is what I Have in zulu_err.log
2020-06-05 12:44 +00:00: ^[[31m[2020-6-5 12:44:40.684] [ERROR] console - ^[[39mError authenticating client websocket {“message”:“Permission denied”,“stack”:“Error: Permission denied\n at EventEmitter. (/var/www/html/admin/modules/zulu/node/index.js:1:37704)\n at Object.onceWrapper (events.js:325:23)\n at emitMany (events.js:147:13)\n at EventEmitter.emit (events.js:224:7)\n at _combinedTickCallback (internal/process/next_tick.js:138:11)\n at process._tickDomainCallback (internal/process/next_tick.js:218:9)”,"__error_callsites":[{},{},{},{},{},{}]}
I have open ports 8002 and 10000-20000, I have self signed certificate, and did everything in Zulu Wiki
Thanks in advance
There are two approaches and the choice is yours. Both of these are common misconfigurations, so there are plenty of people in the forum that have solved this problem.
Honestly, my opinion is that the second one is “more correct”, because not having timers can lead to calls where one end quits the call and the other end doesn’t know for half an hour. Either solution, though, is workable. The “right” solution (IMHO) is to do 1 (to get ops working) and then fix 2 (to avoid the problem in the future).