Summary:	ASTERISK-26694: PJSIP: Notify event not authenticating to the phone.
Reporter:	Luke Escude (lukeescude)	Labels:
Date Opened:	2017-01-04 10:04:32.000-0600	Date Closed:	2017-01-04 11:32:31.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:	13.13.1	Frequency of Occurrence
Related Issues:
Environment:	x64 CentOS	Attachments:	( 0) gs_invalid_event.pcap ( 1) gs_noauth.pcap ( 2) yealink_works.pcap
Description:	When sending a NOTIFY packet to the phone via CLI, the following things can be noted: With chan_SIP, the phone returns 401 Unauthorized, then the server does another Notify packet with the correct authorization. With chan_PJSIP, the phone returns 401 Unauthorized, but the server doesn't properly return with a correctly authenticated packet.
Comments:	By: Asterisk Team (asteriskteam) 2017-01-04 10:04:33.395-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2017-01-04 10:06:33.932-0600 What is the configuration for the endpoint? By: Luke Escude (lukeescude) 2017-01-04 10:07:06.001-0600 You can see that a Yealink phone works, but the Grandstream is the one giving us problems. But Grandstream does work just fine with chan-SIP By: Luke Escude (lukeescude) 2017-01-04 10:08:28.905-0600 Here is the configuration for the endpoint. Note we are new to working with PJSIP, so it might look strange. [142] type=endpoint context=from-internal disallow=all allow=ulaw allow=ilbc:30 allow=g729 auth=142-auth aors=142 rtp_symmetric=yes force_rport=yes direct_media=no rewrite_contact=yes send_pai=yes send_rpid=no mailboxes=142@voicemail callerid=TB3 142 <142> t38_udptl=yes t38_udptl_ec=redundancy t38_udptl_maxdatagram=400 t38_udptl_nat=yes [142-auth] type=auth auth_type=userpass username=142 password=HELLO realm=asterisk [142] type=aor max_contacts=3 qualify_frequency=15 qualify_timeout=20 We added realm=asterisk to see if that would help, and it doesn't. By: Joshua C. Colp (jcolp) 2017-01-04 10:20:19.900-0600 The "auth" option configures inbound auth only. If you set "outbound_auth" does the behavior change? By: Luke Escude (lukeescude) 2017-01-04 10:42:43.567-0600 Hmm how would I do that? Another context with type=outbound-auth? By: Joshua C. Colp (jcolp) 2017-01-04 11:06:24.509-0600 It is added to the endpoint like so: outbound_auth=142-auth That means "if I send a request and I am challenged for authentication use the credentials from 142-auth". By: Luke Escude (lukeescude) 2017-01-04 11:30:45.669-0600 Yep that fixed it! Thanks so much!