A few months ago, we moved from Asterisk 1.8 (Debian 8) using chan_sip to Asterisk 16.2.1 (Debian 10) using PJSIP. So far the journey has been quite smooth. There is however a problem when registering with sip providers. We have 3 different providers and two of them constantly present the problem.
Initially the problem was that pjsip show registrations showed them as Rejected. All it took to fix it was a pjsip reload. Once a pattern started to emerge, we started to dig deeper and using tcpdump we manage to capture the interaction, yet we fail to understand why it’s happening, so I hope anyone can shed some light on this.
The interaction is as follow:
=> Register
<= Unauthorized (WWW-Authenticate)
=> Register (Authorization)
<= Unauthorized (WWW-Authenticate, stale=true)
This interaction repeats until a pjsip reload is issued. I have the full dumps of the call in case they can be of use.
So my only question is, shouldn’t Asterisk resend the credentials with the new nonce once it gets a stale=true instead of redoing the whole cycle?. Other than this, I have no idea what could be causing the problem. Any help is appreciated.
I would expect PJSIP to try again, but I’d be more interesting in why the nonce is stale in the first place. Do you have a SIP trace of registrations that succeeded and then the one that failed?
I can post a redacted (text) version of both scenarios if that would be useful. Otherwise I could share the full dumps by other means so you can inspect them. Again, any help is appreciated. Also one of these providers have an Asterisk that is accessible to us in case we need some info from that provider.
Debug level within Asterisk would also be useful so messages can be seen within PJSIP and the outbound registration module. Oh, as well as configuration. There are configuration options that alter behavior on different error cases.
At least the nonce header is the same on 2 and 3, but for some reason the other end (Asterisk with chan_sip) replies with stale=true. Initially I thought there was something wrong with the other end, but seeing that a pjsip reload on our end fixes the issue, I’m not so sure.
This repeats for days even until we do something about it.
Here is the configuration of that specific provider. Would it be possible to share the sip traces privately?. It’s a tcpdump capture, can be easily viewed with WireShark.
I have not tried auth_rejection_permanent=no if that is your suggestion, I’ll try that and see how it goes. As for the traces I’m not sure I can redact a tcpdump capture without corrupting the data. If you have any idea on that end let me know. There is nothing really secret in there other than IPs and credentials. But I would like to avoid posting that publicly if possible.
I would suggest trying that first, then we can see if additional things are actually needed. Also generally people provide “pjsip set logger on” output as it also interleaves log messages and thus makes understanding timing easier as well.
Well the problem repeated itself, with all 3 providers. At this point I’m planning on going back to chan_sip for the providers and keep the pjsip channel for users. If you are willing to investigate this further let me know. Like I said I can provide the pcap privately. As for the logger I can provide that too, there seems to be a pjsip set history that looks usefull for that.