Hi, my first actual post… although an avid reader. Wondering if anyone can help see what is going on with my calls.
This setup used to work… I dont know what has changed. Am getting calls from outside dropped at exactly 30 seconds.
https://pastebin.freepbx.org/view/7968c119
Thanks in advance 
The usual culprit is NAT, is this a local or hosted PBX?
Have you checked in Asterisk SIP Settings to make sure the external IP is correct?
No-one answered the ringing Yealink. Your verbosity level was too low to see the dialplan, but I think you have a 30 timeout on the Dial call.
its a self hosted PBX. External ip is set to my FQDN. And Nat is set to no as my pbx is in my routers DMZ
The latest log seems to contain two half calls, rather than a single complete call.
Sorry about that. Here is another.
https://pastebin.freepbx.org/view/6acd379b
I cant see from the log what is happening. There doesnt seem to be anything wrong. But the call always hangs up on 30 seconds when calling into the pbx.
It looks like you screen scraped this, meaning there are no time stamps, and therefore no evidence of how long into the call the cal failed.
Also you don’t have the protocol debugging running so one cannot see how it failed at that level.
It looks to me as though homevoip cleared the call normally.
(The dial timeout is 20 seconds so the CANCEL I picked on before is irrelevant.
You really should clean up your list of destinations as you still seem to have a chan_sip one, but haven’t got chan_sip loaded.)
Try to send here PCAP.
tcpdump -s0 -iany -w/tmp/capture-Started-date +%Y%m%d-%H%M%Z.pcap -C75
The problems with a PCAP are that you can’t match it up with what Asterisk thinks it is doing; PCAPs are taken before the firewall, so may show packets that never reach Asterisk; and they they can be too noisy and too difficult to redact.
Going back to the original trace, now that I know that the CANCEL is a red herring, you are getting no response to the OK sent to Twilio, which would typically mean that this line in the trace is wrong:
411. Contact: <sip:X.X.X.X:5160>
That would be typically the result of failing to have a valid public signalling address configured.
I can see different ports.
Contact: "+44ANUMBER" <sip:[email protected]:5060;transport=udp>
Contact: <sip:X.X.X.X:5160>
There is nothing wrong with the two ends having different port numbers. The 5060 one is Twilio’s port, and the 5160 is Asterisk’s.
There is something weird at line 8370. The BYE is sent by TCP when the incoming request, contact, and record route all indicated UDP. I don’t think that is wrong from a SIP point of view, but it suggests that your configuration doesn’t agree with Twilio’s on the choice of transports.
However, the OK’s are sent using UDP, and the Contact header on those doesn’t override the transport, so I don’t see that it explains why there are no ACKs coming back from Twilio, assuming that the OK’s contact header contains the correct address.
As it looks like you probably have transport set to TCP, locally, outbound calls will not be using the same transport as responses to inbound calls, so there could be a problem with outbound UDP to Twilio, but then why have two people reported the problem.
As Twilio obviously accepts TCP, can it be configured to originate TCP?
Are you registering, or are you using IP authentication? In the case of registering, the contact URI in the REGISTER determines the transport. Maybe transport isn’t been set, but Twilio used to force TCP, but now Twilio is honouring the UDP default and that explains why incoming requests are UDP, although not why there is no ACK.
Though not directly related to the Twilio connection, line 531
Via: SIP/2.0/TCP 38.x.x.x:5160;rport=5060;branch=z9hG4bKPj51dda596-7039-45e8-8cfe-430af8081ec1;alias
seems to show that a router/firewall somewhere has external port 5160 forwarded to internal port 5060.
Are you also doing that in the Twilio path? If so, why? The Contact headers sent to Twilio show Asterisk is listening on port 5160, but if the original invite was sent to 5060 that won’t work properly.
I am registering. I have set everything to use TCP now and it still drops the call. The RTP stuff seems to be working. Here is another dropped call log
pjsip logger was not on, so there is little information.
What is pjsip Port to Listen On set to? To which port is Twilio told to send the call? What, if anything, are you using port 5160 for?
There’s no protocol trace, so I can’t tell if TCP is really being used.
If it is, there should only be 1 OK sent, as TCP is assumed to deal with re-transmissions.