In the PJSIP transport do you have the external signaling address value set with local network?
I don’t think so.
voip*CLI> pjsip show transports
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress....................>
==========================================================================================
Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060
Transport: 0.0.0.0-ws ws 3 96 0.0.0.0:5060
Transport: 0.0.0.0-wss wss 3 96 0.0.0.0:5060
Objects found: 3
I assume at least one of those should show my external IP?
I’m not sure where I’d change that in FreePBX.
“pjsip show transport 0.0.0.0-udp” to show full details if using UDP. The list shows limited information.
1 Like
voip*CLI> pjsip show transport 0.0.0.0-udp
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress....................>
==========================================================================================
Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060
ParameterName : ParameterValue
===============================================
allow_reload : false
async_operations : 1
bind : 0.0.0.0:5060
ca_list_file :
ca_list_path :
cert_file :
cipher :
cos : 3
domain :
external_media_address : <my public ip>
external_signaling_address : <my public ip>
external_signaling_port : 0
local_net : 10.0.0.0/255.0.0.0
method : unspecified
password :
priv_key_file :
protocol : udp
require_client_cert : No
symmetric_transport : false
tos : 96
verify_client : No
verify_server : No
websocket_write_timeout : 100
I’ve filtered out my public ip, but it is correct in both locations.
Thank you for all your help so far.
Just for the heck of it, I tested with a low-end Linksys router, and even with SIP-ALG disabled (there was an option for it), I still got the same results. Outbound calls dropped after 30 seconds.
So this goes back to the SIP trace request others have made. Termination of a call that has been answered is done using a BYE request. Determining which side sent the BYE request will narrow down who has a problem. As well on a call from an endpoint into Asterisk upon answer Asterisk sends a 200 OK response, the remote side then has to send an ACK to say they received the 200 OK. If this doesn’t happen then the call will end, usually after 32 seconds. Until the SIP signaling is verified to be okay focusing on the RTP/RTCP I think is premature.
1 Like
Are you talking about the tcpdump requests? I’ve done those. I have two (one remote, one remote but via vpn).
I can provide whatever info you need, but I just need direction on what to get you since I’m not 100% confident in my ability to read what wireshark is showing me unless it’s in plain English (and then not even then sometimes).
The last BYE request in my first capture came from the PBX.
Source: PBX ip
Destination: remote ip
Protocol: SIP
Info: Request: BYE sip:[email protected]:5060
Followed by a few UDP packets in both directions and then a SIP packet from the remote extension: Status: 200 OK
Looks like I can copy and paste the actual lines.
Remote IP filtered.
No. Time Source Destination Protocol Length Info
3682 46.155686 10.40.0.1 x.y.z.a SIP 454 Request: BYE sip:[email protected]:5060 |
3683 46.156868 x.y.z.a 10.40.0.1 UDP 214 12110 → 12072 Len=172
3684 46.174206 10.40.0.1 x.y.z.a UDP 214 12072 → 12110 Len=172
3685 46.175353 x.y.z.a 10.40.0.1 UDP 214 12110 → 12072 Len=172
3686 46.194966 10.40.0.1 x.y.z.a UDP 214 12072 → 12110 Len=172
3687 46.196516 x.y.z.a 10.40.0.1 UDP 214 12110 → 12072 Len=172
3688 46.198336 x.y.z.a 10.40.0.1 SIP 516 Status: 200 OK |Try it in sngrep over tcpdump , the calls are already prefiltered and although not quite ‘english’ you can more drill down the session’s conversation and see what goes awry and the how and the whens
2 Likes
Ok, I’m not entirely sure what I"m looking at so here’s a screenshot of my most recent call
I can arrow up and down the list and on all of the 200 OK (SDP) lines show the same info on the right:
You are seeing the many 200 ok sent from your pbx, there are no replies so after the 30 second timeout, you hangup, it is the network/firewalls/algs/firewall between your endpoint and your PBX not routing properly.
So now check if there are any rtp packets actually being received at your point of ingress, and if they are so arriving how they are being incorrectly mangled. If they are not being seen by your Machine, then there is something wrong ‘upline’
Perhaps I’m reading it wrong, but the From (sip:107) is my remote extension and the To (sip:202) is me at my desk. It looks like the OKs are being sent from the remote phone to me, or am I reading that wrong?
Should they be sent elsewhere?
Sorry, if you blank out all the relevant routing details. I can’t help further with possible suggestions
No! You have help me without knowing anything!
Apologies I should have clarified after posting.
107 is the remote extension
202 is my extension in the office.
I have blanked out identifiable information (my public IP, the remote IP and my local hostnames).
If there’s something specific you need that I blanked out, please let me know.
Thanks for all your help so far.
Not really possible, they are your (private) networks and you need to explore the connectivity and routing between them.
When your SIP conversations traverse (they do) then you need to arrange for the ensuing RDP traffic to be well routed. That means on every router/switch/firewall between the extension and the PBX. So this sngrep call shows that the remote extensions SDP packets are not reaching your PBX. So stop looking at the PBX and start looking at your upline devices.
Ok, thanks for the suggestion.
I did a tcpdump at my gateway’s WAN connection and then placed an outbound quick call and had the remote phone call me back. Same 30 second drop as expected. The dump shows RTP traffic from the remote to the gateway and several RTCP packets that say “Malformed Packet”.
I’m not 100% sure how to interpret everything, but I could post the results (54 packets), with filtered IP info again if that would help.
That won’t help, RTCP packets are a red herring, if the flow stops after 30 seconds, you need to go to the device that is responsible for stopping that flow, and then stop it stopping it , no?
Right, but I’m trying to determine what is stopping the flow.
Presumably since I see RTP packets at the gateway but not at the PBX, it would be the gateway, which is what I’m trying to confirm.
You have already confirmed it, sngrep looks at the interface before any iptables, so no traffic there then . .
For a simple situation use the “big hammer solution”, forward all traffic on 50??/TCP/UDPTLS (SIP) and UDP-10000-2000 (SDP) to your PBX then work out why your gateway is not communicating with your PBX at a SIP level