PJSIP Registration Rejected

Asterisk Asterisk SIP
#1

Hello,

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:

  1. => Register
  2. <= Unauthorized (WWW-Authenticate)
  3. => Register (Authorization)
  4. <= 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.

#2

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?

#3

Thanks for the quick reply, yes I do, after a pjsip reload it does:

  1. => Register
  2. <= Unauthorized (WWW-Authenticate)
  3. => Register (Authorization)

And everything works. No stale involved.

#4

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.

#5

What is really needed is the SIP trace of outbound registrations for a period of time including when it has failed, so the progression can be seen.

#6

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.

#7

Here is a quick example of the non-working scenario with mininal headers

  1. => Register
  2. <= Unauthorized (WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“50e88819”)
  3. => Register (Authorization: Digest username=“myuser”, realm=“asterisk”, nonce=“50e88819”, uri=“sip:X.X.X.X”, response=“c2013b31dd5efbf7dd8c48f85101a06c”, algorithm=MD5)
  4. <= Unauthorized (WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“2304a4e4”, stale=true)

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.

#8

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.

[transport_udp]
        type=transport
        protocol=udp
        bind=0.0.0.0
[HND]
        type=registration
        transport=transport_udp
        outbound_auth=HND
        server_uri=sip:X.X.X.X
        client_uri=sip:myuser@X.X.X.X
        contact_user=dst_ext
        expiration=3600
        line=yes
        endpoint=HND
[HND]
        type=auth
        auth_type=userpass
        username=myuser
        password=secret
[HND]
        type=aor
        contact=sip:X.X.X.X:5060
        qualify_frequency=60
[HND]
        type=endpoint
        outbound_auth=HND
        aors=HND
        context=from_hnd
        allow=!all,ulaw,alaw,g729
[HND]
        type=identify
        endpoint=HND
        match=X.X.X.X
#9

I only accept traces privately if redaction is absolutely impossible. Have you tried adjusting the options[1] to deal with failure?

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Configuration_res_pjsip_outbound_registration#Asterisk17Configuration_res_pjsip_outbound_registration-registration_auth_rejection_permanent

#10

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.

#11

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.

#12

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.

#13

All issues should go to the issue tracker[1] with information.

[1] https://issues.asterisk.org/jira

#14

Thanks a lot, I’ll go to the issue tracker then.