Phoner Admin wrote on 08. Oct 2021 at 11:57:
But I don't really understand, whats your problem. What exactly is not working with PhonerLite?
Long story short: after Phonerlite advertises its local port in the contact field, the communication with PBX becomes totally onesided (broken). Here is an example of what's going on (at least how I see it):
Phonerlite has local IP:port (TLS, for incoming connections): 192.168.0.1:5061
PBX IP:port: 1.2.3.4:5061
Phonerlite's login and extension is 90000
Phonerlite sends register request to PBX, trying to open a TLS session. For that it uses a random local outbound port, say 192.168.0.1:56789
While Phonerlite goes through NAT, in the outbound TCP packets the router replaces Phoner's local ip:port with its external IP and other random port, for example 100.100.100.100:60000. This external ip:port pair Phonerlite sends in the Contact field in the registration phase to the PBX.
Here is a part of Phoner's REGISTER message (taken from the debug log):
REGISTER sip:1.2.3.4 SIP/2.0
Via: SIP/2.0/TLS 100.100.100.100:60000;rport
Contact: <sip:90000@100.100.100.100:60000;transport=tls>
As we can see, Phonerlite correctly determined external IP and port (100.100.100.100:60000) of the router and use them in the Contact field.
-------------------------------------------
PBX responds with register success: SIP/2.0 200 OK
Via: SIP/2.0/TLS 100.100.100.100:60000;rport=60000
Contact: <sip:90000@100.100.100.100:60000;transport=tls>
Because server sends packets to 100.100.100.100:60000, the router with NAT correctly redirects such packets to a correct destination (Phonerlite local port 192.168.0.1:56789)
-------------------------------------------
After a while PBX initiates an incoming call: INVITE sip:90000@100.100.100.100:60000;transport=tls SIP/2.0
Via: SIP/2.0/TLS 1.2.3.4:5061;rport;
Contact: <sip:asterisk@1.2.3.4:5061;transport=TLS>
To this point everything is going fine.
-------------------------------------------
Phonerlite indicates to PBX the phone is ringing:
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 1.2.3.4:5061;rport=5061;
Contact: <sip:90000@100.100.100.100:5061;transport=tls>
Now Phonerlite tells PBX: "Send me packets to 100.100.100.100:5061" (despite knowing that it is behind NAT!). So sending packets to 100.100.100.100:5061 is pointless.
-------------------------------------------
Beyond that point Phonerlite is not able to receive any SIP messages from PBX at all at least till the next call or re-registration because PBX starts to send them to
100.100.100.100:5061 (that connection from the PBX perspective stays in the SYN_SENT state because the router drops them packets without any warning, so a TCP session couldn't be established).
And the router simply drops all packets to that port because 5061 was not involved in any previous NAT-related communications. So port 5061 is not associated with any local IP address behind NAT.
And after the other side hangs up, Phonerlite never receives a BYE message from PBX and the call is indicated ongoing forever.
So why Phonerlite advertises "Contact: <sip:90000@
100.100.100.100:5061;transport=tls>" in such case instead of continuing to advertise its port in an already established TLS session (
100.100.100.100:60000) knowing that 100.100.100.100:5061 is a deadend? If it would have kept sticking with 100.100.100.100:56789 (reused the already established session) to the very end, all the PBX packets would have reached the destination.