When registering to an upstream provider using the uac module, the source port of REGISTER messages alternates seemingly randomly between either 5060 or the lowest available port, e.g., 1024, 1025, 1026. All SIP providers that I tested send subsequent INVITEs of incoming calls to the originating ip/port of the prior REGISTER, which is problematic when kamilio is running behind a firewall.
I tested both the latest master (7c03340b4b486afaf00b14a6589c13b7165240a0) and 4.4 (df5ef6183350d99f77087dd83950ef35466e84a1) on Debian unstable/amd64.
#### /etc/kamailio/kamailio.cfg ``` #!KAMAILIO
debug=3
loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "db_text.so" loadmodule "dialog.so" loadmodule "uac.so"
#!define DBURL "text:///etc/kamailio/dbtext"
modparam("rr", "append_fromtag", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "track_cseq_updates", 1) modparam("uac", "restore_dlg", 1) modparam("uac", "reg_db_url", DBURL) modparam("uac", "reg_timer_interval", 60) modparam("uac", "reg_retry_interval", 60) modparam("uac", "reg_contact_addr", "1.2.3.4:5060")
request_route { exit; } ```
#### /etc/kamailio/dbtext/uacreg ``` l_uuid(string) l_username(string) l_domain(string) r_username(string) r_domain(string) realm(string) auth_username(string) auth_password(string) auth_proxy(string) expires(int) flags(int) reg_delay(int) 12345678:user:domain.local:11111111:sip.example.org:sip.example.org:11111111:XXXXXXXXXXXXXXXX:sip:sip.example.org:600:0:0 ```
Can you attach a pcap file with some of suchregistrations? Kamailio should use the sockets it listens on for sending these requests.
I apologize for the incomplete report so far. I was tracing the SIP traffic with `sngrep` and unfortunately did not save the pcap file while I was testing something else. The registrations with an alternate source port are in fact hard to reproduce and appear to occur, if at all, only right after (re)starting kamailio. kamailio sends out one (or multiple, in the configured interval of 600-60 seconds) registrations with sport != 5060 and eventually switches to sport 5060 for all subsequent registrations.
The registration dialogs were absolutely normal apart from the source port, e.g., ``` 1.2.3.4:1026 -> 5.6.7.8:5060 REGISTER sip:sip.example.org SIP/2.0.
5.6.7.8:5060 -> 1.2.3.4:1026 SIP/2.0 401 Unauthorized.
1.2.3.4:1026 -> 5.6.7.8:5060 REGISTER sip:sip.example.org SIP/2.0.
5.6.7.8:5060 -> 1.2.3.4:1026 SIP/2.0 200 OK. ```
Can there be a race between obtaining the listening sockets and sending out the first registration?
Kamailio doesn't create any other sockests for sending over udp than the ones set for listen. I can't say for sure if the kernel decides to change that in case of high traffic, but I doubt that.
Is ther a single sport different than 5060, or there are many?
Any update on this?
Can you explain what you mean with a single different source port versus many? The kamailio instance was not doing anything else besides sending out periodic registrations to a single provider, so this was very low traffic indeed.
Is it possible to explicitly force the source port for outgoing packets on the listening socket?
Kamailio is always forcing one of its UDP listen sockets when sending out.
The question was if it the issue you observed was using only one other port and the same always (besides those where kamailio is listening on), or there were different other ports and many of them from case to case.
Over the lifetime of a kamailio process, I observed messages from two source ports: the same source port < 5060 for the first or first few REGISTER, and source port 5060 for all subsequent REGISTER.
One more clarification: is that port<5060 always the same, even at different tests? Or was the same only per each test?
You can try to define `event_route[tm:local-request] { ... }` and force send socket there (there is a function or can be done with assignment to $fs). I don't think there is anything else that can be done in kamailio, it may be a matter of OS/kernel settings or behaviour.
Closed #936.
The source port < 5060 changed between different tests. It was the same only per each test.
Thanks for the hint, I will try that in case the issue reemerges. So far I have been unable to reproduce it.