I’m running Asterisk 13.9.1. I’ve configured chan_pjsip to register a user with an external SIP server (using TLS), and to reregister periodically thereafter. I’m seeing the reregistrations being sent out on different ports to the original registration. Is this expected behaviour?
Incoming calls request from remote endpoints come in on the registered port.
If a call is initated just prior to a reregistration then up to the reregistration SIP INFO/UPDATE call session pkts. from the other endpoint successfully reach Asterisk and are successfully processed. But after the reregistration (because the port has changed) they do not. Instead 477 is returned to the endpoint from the SIP server.
So can I force the reregistration to go out on the same port (if so how?). Or should this be handled via some other means?
What transport are you using? If using UDP then the source from the server will always be that of the UDP transport, the only way it would be changed is if you have NAT in the way and it’s assigning a new outbound port. If using TCP then it would depend on if the connection is up or not. If it’s not then it would establish a new one.
Asterisk<->SIP server transport is TLS, so it’s TCP.
So after reregistration the connection is up on the new TCP port, but the original TCP connection is now closed.
So should the SIP server (which knows the Asterisk registered user is now on a different port) simple redirect the endpoint call session SIP traffic to the newly registered port. (i.e. is my problem due to a misconfigured SIP server).
Or should Asterisk reuse the original registration port for reregistration (via some Asterisk pjsip config change).
Or should Asterisk be notifying the endpoint that it’s TCP port has now changed via some UPDATE after the reregistration.
For TCP/TLS when sending a request to something we will look to see if a connection is already up to the target, if it is then we will reuse that connection. If that isn’t happening then something is closing the connection. A wireshark will determine who is closing it.
For the remote server it’s up to them what to do. They can also reuse the connection if it is still up, or try to establish a new one to us using the Contact we provide.
As for reusing the port - you can’t. TCP doesn’t work like that.
Overall the REGISTER should replace the existing connection and be used.
Wireshark trace shows the initial registration TCP connection being closed by Asterisk and reopened (on another port). This repeats every pjsip.conf expiration secs.
As for reusing the port - you can’t. TCP doesn’t work like that.
Overall the REGISTER should replace the existing connection and be used.
Ok - but if an incoming call straddles a re-REGISTRATION how do incoming call session SIP pkts get redirected to the new TCP port.
At present the remote endpoint (i.e. the client the other side of the SIP server) is trying to send them back to Asterisk specifying the TCP port current at the time the call session begins, the SIP server rejects it (because Asterisk is no longer on that TCP port), and the pkt never reaches Asterisk.
Is it Asterisk’s responsibility to notify the remote endpoint of the TCP port change after the reregistration?
Or should the SIP server have enough info to redirect the call session SIP pkts to the new TCP port?
Or are calls straddling re-REGISTRATIONS just not handled gracefully?
No, it’s not the responsibility of Asterisk. Asterisk tells the remote server that it can be reached at X address and port. This isn’t the active TCP connection, but where the remote server can connect to if need be. The remote server may reuse the existing connection if it’s open but otherwise should establish a connection back to Asterisk. The same applies for active calls. There is also a global option, keep_alive_interval, which can be set to send a keep alive to keep TCP connections open longer.
I only ever see SIP pkts arriving on the TCP ports used by Asterisk to perform the registerations. Sounds like I am missing something in my SIP registration. i.e. How do I indicate in the pjsip registration config that Asterisk is also listening on the TLS bind port.
There’s nothing you can do on the Asterisk side to force the other side to connect to the port we’re listening on. It’s up to them what to do. If you mean how do you use TLS then you’d use “sips:hostname;transport=tls” for a URI.
Apart from this issue I have TLS working fine thanks.
Mobile SIP clients - Linphone, etc. can be configured to reuse the same outgoing TCP port when performing the SIP re-registration on TLS. I had assumed Asterisk would be similarly configurable - but from what you say it is not.
From what you say it also sound like there is no way to get Asterisk to register via one port and pass the TLS-bind port on which it is currently listening in. If there was a way to configure (say) the Contact field of the SIP REGISTRATION with the TLS-bind port? - would that potentially resolve the problem? The SIP server would then know both Asterisk TCP ports and could (possibly) be configured to fall back to the TLS-bind port if a re-registration comes in on another port and Asterisk is no longer on the initial registration port.
So it sounds like I need to provision Asterisk differently within the SIP server to the way I provision mobile SIP clients, i.e. by defining the TLS-bind port as part of that config.
Yes, the Contact header should contain the bound address and port. As well I forgot that if you are using unbundled PJSIP and specify a transport on things then the connection will not be reused, this is fixed in the bundled version and will be fixed in the next release of PJSIP. I’d suggest providing your configuration and a SIP trace of the registrations.
Ah - ok. well I am using Asterisk 13.9.1 but, as I have only recently updated from Asterisk 13.7.2, I am still using my own copy of PJSIP 2.4.5 i.e. not the bundled version.
And the Contact field of my SIP REGISTRATION specifies the TCP registration port number, and not the TLS-bind port number.
Sounds like if I use the bundled PJSIP I may see different behaviour.