Jitsi sip client upgrade#

Notice the port on the first IP is 5060 and the port on the second IP is also 5060. YouвЂ™ll see a timestamp followed by two IP:port pairs. Look again at the first line of the request from Jitsi. I stared at these traces for a while to get a clue. This 401 Unauthorized response was received by the client and the follow up request with the Authorization header was sent with the correct digest. Since I could register Linphone using the same account, I did the same trace for that client. ItвЂ™s almost like something has blocked the response to the client. The dialog flow is cut off after the 401 Unauthorized response. The SIP dialog looks good but Jitsi continues not to register. When Kamailio receives this request, checks the auth database and sends a 200 OK response, the client is authenticated. A second client request should follow it, which should contain an Authorization header with an md5 and a nonce. If you read the response, youвЂ™ll see Kamailio sent 401 Unauthorized. IP addresses and usernames have been changed to protect the innocent. IвЂ™ll include an excerpt (IвЂ™ve included only the relevant headers for this issue) of the initial request from Jitsi.

Ngrep -d eth0 -t -p -W byline foo port 5060 If you are new to operating a SIP network, ngrep is an excellent tool for debugging. For the curious, hereвЂ™s the utility and options I used. I opened Jitsi and things got interesting. I did a packet trace on the serverвЂ™s public network interface, filtered to dump packets only on UDP port 5060 that match my SIP username. What could the server be doing to this poor client?

Jitsi sip client upgrade#

The only change was a Kamailio upgrade from 4.0.1 to 4.0.2. I went back to the server, diffed all the configs, checked server versions, connected with every client I could find that would run on any of my computers. To make matters more confusing, I could register and make calls with two different clients (CSipSimple and Linphone) on the same network (my home ISP, Verizon FiOS) using an insecure connection to on UDP port 5060. Secure connections (on TCP port 5061) continued to work as expected. After some testing we discovered the problem was related to insecure connections from Jitsi to UDP port 5060 on. Obviously something had changed but none of us knew what it was. To support n8fr8вЂ™s hypothesis, there was a small change to the server but I wanвЂ™t convinced it effected anything since all my clients continued to work properly, including Jitsi. The tl dr follows, skip to keyword CONCLUSION to hear only the punch line. The common question was вЂњwhy did it work a few weeks ago and now it doesnвЂ™t anymore?вЂќ Earlier last week n8fr8 suspected something changed on the server, due to many users emailing support specifically about Jitsi connectivity to.