[Home]

Summary:ASTERISK-24845: pjsip send notify not working with Cisco phone
Reporter:Carl Fortin (phonefxg)Labels:
Date Opened:2015-03-04 12:37:39.000-0600Date Closed:2015-04-24 12:25:09
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_pjsip
Versions:13.2.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS release 6.6 (Final) Asterisk 13.2 realtime PJsip driver Phones: Cisco SPA514G firmware 7.5.6aAttachments:( 0) 1-Sip_notify.jpg
( 1) 2-Sip_notify.jpg
( 2) 3-Sip_notify.jpg
( 3) 4-Sip_notify.jpg
( 4) ASTERISK-24845.patch
( 5) Capture_Cisco_registration_lost_call_flow.PNG
( 6) Capture_Cisco_registration_lost.PNG
( 7) Chan_PJSIP_CISCO_Notify.pcapng
( 8) Chan_SIP_NOtify_Working.pcapng
( 9) myDebugLogCHAN_SIP_NOTIFY_WORKING
(10) myDebugLogPJSIP_NOTIFY_NOT_WORKING
(11) phone_settings.txt
(12) PJSIP_wrong_response.png
Description:pjsip send notify will not work on cisco phone. I have tested the chan_sip driver and it is working great. I even tested with a yealink phone with the PJsip driver and it is working.

Here is my post in the forum:

http://forums.asterisk.org/viewtopic.php?f=1&t=92633&sid=6525c642fac6604b2e52af33edafb676

Here is phone's settings:

[edit by Rusty - removed config data from description field and attaching as phone_settings.txt]

I can provide more info if needed.
Comments:By: Joshua C. Colp (jcolp) 2015-03-07 10:55:39.799-0600

The Cisco appears to be requesting authentication from Asterisk. Since you have not configured outbound authentication on the endpoint Asterisk can not authenticate. If you add outbound_auth=U_9172 to the endpoint what happens?
By: Carl Fortin (phonefxg) 2015-03-08 11:19:07.232-0500

I just changed it and this time I get this:

dti-asterisk*CLI> pjsip send notify cisco-reboot endpoint U_9172
Sending NOTIFY of type 'cisco-reboot' to 'U_9172'

[Mar  8 12:17:00] WARNING[5806]: res_pjsip_outbound_authenticator_digest.c:133 digest_create_request_with_auth: Authentication credentials not accepted by server



By: Matt Jordan (mjordan) 2015-03-09 11:07:11.203-0500

That seems to imply that the authentication credentials you provided were not what the server wanted.

This looks like a configuration issue.
By: Carl Fortin (phonefxg) 2015-03-09 11:49:00.786-0500

I guess... but the phone is registered correctly and can make calls.
Could it be something missing in the database? I have setup my phones in the following tables:

ps_aors
ps_auths
ps_endpoints

There is nothing in the other tables.

I even took some wireshark traces, that I could send you.

As you can see everything seems fine in the console:

pjsip show auth U_9172

 I/OAuth:  <AuthId/UserName.............................................................>
=========================================================================================

    Auth:  U_9172/U_9172

ParameterName  : ParameterValue
===============================================
auth_type      : userpass
md5_cred       :
nonce_lifetime : 1
password       : P_qpOJ(cnY9qDoPi7TqUdk!Xp6Gj4p
realm          :
username       : U_9172

pjsip show aors

Aor:  U_9172                                               1
   Contact:  U_9172/sip:U_9172@10.188.6.25:5061                 Unknown               nan






By: Carl Fortin (phonefxg) 2015-03-09 12:59:47.199-0500

Wireshark capture of notify to cisco phone
By: Carl Fortin (phonefxg) 2015-03-11 05:16:18.531-0500

I have included some wireshark screenshots with the sip filter on.
By: Carl Fortin (phonefxg) 2015-03-11 15:32:09.368-0500

Wireshark's Screenshot
By: Rusty Newton (rnewton) 2015-03-13 17:43:50.254-0500

Can you try setting the appropriate realm in the auth object?
By: Carl Fortin (phonefxg) 2015-03-13 18:04:09.526-0500

What do you mean by appropriate realm? I have tried asterisk's IP address (like the one in the screenshot). It is still not working.
I even did a test with the same settings in a config file instead of realtime and I get the same result....
By: Carl Fortin (phonefxg) 2015-03-20 12:16:08.533-0500

I would be great if someone with a Cisco phone could test it and see if it works.

By: Carl Fortin (phonefxg) 2015-03-24 07:24:37.626-0500

The response sent by Asterisk to the Cisco is wrong....

The response from the wireshark's capture with password P_qpOJ(cnY9qDoPi7TqUdk!Xp6Gj4p should be this:


4a07bd32a3b06aa3923d1c351cdc0976


See attached file PJSIP_wrong_response with the tool I have used to calculate the response.


I also did another test with a notify and the old Chansip driver and the calculated response is ok.
By: Carl Fortin (phonefxg) 2015-03-24 07:25:36.496-0500

Wrong response in challenge
By: Rusty Newton (rnewton) 2015-04-07 16:37:03.364-0500

Looks like a bug to me... I'm opening it up. Though, can you also post a packet capture of working notify scenario with the chan_sip driver for comparison?

If you can include Asterisk full logs of both(chan_sip call and pjsip call) that would also be helpful for whoever looks into this.

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Carl Fortin (phonefxg) 2015-04-08 08:42:05.838-0500

Here are my debug logs and wireshark's sip captures for both Chan_sip and PJsip. I hope it will help find the bug..
By: Mark Michelson (mmichelson) 2015-04-22 18:36:29.569-0500

The calculated response digest is actually correct. In the checking program you ran, you entered the incorrect URI. You entered {{sip:U_9172@10.188.4.30:5061}} but it should be {{sip:U_9172@10.188.6.25:5061}} . I ran a check with the correct URI and got the following:

{noformat}
santigold pjproject # openssl dgst -md5
U_9172:206.167.100.39:P_qpOJ(cnY9qDoPi7TqUdk!Xp6Gj4p(stdin)= b798acff6833dddc9b7be8c169bfe193
santigold pjproject # openssl dgst -md5
NOTIFY:sip:U_9172@10.188.6.25:5061(stdin)= 7f9d8eabf6c27bf2c1eb1354f64a321a
santigold pjproject # openssl dgst -md5
b798acff6833dddc9b7be8c169bfe193:41933333:00000001:2bef322e-3570-4127-84dc-944ee367bb45:auth:7f9d8eabf6c27bf2c1eb1354f64a321a(stdin)= 8d6a7d1be65ccd7828f25210a4fd31be
{noformat}

I suspect that the problem is elsewhere, but it's not immediately obvious just be looking at the pcaps. Here are some things that are possibilities:
1)  The From headers that Asterisk uses differ between versions. In chan_sip, the header looks like {{"asterisk" <sip:asterisk@206.167.100.39>;tag=as6d5921f0}}, and in chan_pjsip, the header is {{<sip:U_9172@206.167.100.39>;tag=2aaa3335-0505-41dd-9bc2-0fc0e0a9cfa2}}. If the Cisco phone distinguishes who it's talking to based on usernames in From headers, then this may factor into the problem. I find it unlikely that this would be the case since most phones are configured to operate with exactly one server, and the phones will always assume that incoming requests are from that server. In other words, I don't suspect that authentication is failing because the phone is authenticating against the wrong user.
2) There are fewer headers in the NOTIFY request that Asterisk sends in chan_pjsip. Specifically, in the example pcap, there is no Max-Forwards, User-Agent, Supported, Date, and Allow headers in the PJSIP version.
3) Because chan_pjsip uses UUIDs for randomly-generated values, the cnonce is much longer in the PJSIP version than in chan_sip. The extra long header value may get truncated by the Cisco phone, resulting in an inability to authenticate. I am *highly* doubtful that this is the case, but I have to mention it just because it's a noticeable difference between the two implementations.
4) chan_sip sets {{algorithm=MD5}} in its Authorization header and chan_pjsip sets {{algorithm=md5}} in its authorization header.

None of these things should have any effect on whether a SIP request can be authenticated, but it's worth investigating some. With the first two, you can actually experiment some and see if it makes a difference.
1) For the endpoint that you are sending the NOTIFY to, set the {{from_user}} option to be "asterisk".
2) I'm not sure whether you were using {{pjsip_notify.conf}} or sending the AMI command, but in either case, you can experiment by adding the missing headers in the NOTIFY you send. If I were guessing, I'd say the Max-Forwards, Supported, or Allow are most likely to cause a difference, if any of them are going to at all. If it does turn out that one of these makes the difference, then I'll create a patch to add the required header(s) by default to outbound NOTIFYs from Asterisk.

For (3), that would be a Cisco issue if it's an issue at all. However, I'd think we can eliminate that as a possibility if Asterisk is able to authenticate properly with the phone on normal calls. If that is the case, then there's no reason that a NOTIFY should behave any differently.

For (4), that's a behavior that occurs within the PJSIP library, so altering it would require code changes to it instead of Asterisk. However, this again can be eliminated as a possibility if other types of requests from Asterisk can authenticate properly.

I suggest you try the diagnostics I described above and see if any of them have a positive result.
By: Carl Fortin (phonefxg) 2015-04-22 19:20:54.986-0500

I have tested option 1 (setting asterisk as from_user) without success.

I am using the following command directly in the console or a code within the dialplan:

pjsip send notify cisco-reboot endpoint U_9172
Sending NOTIFY of type 'cisco-reboot' to 'U_9172'
[Apr 22 20:17:03] WARNING[26777]: res_pjsip_outbound_authenticator_digest.c:133 digest_create_request_with_auth: Authentication credentials not accepted by server

Dialplan:
exten  => *76,1,NoOp()
same   => n,System(asterisk -x 'pjsip send notify cisco-reboot endpoint ${CHANNEL(endpoint)}')
same   => n,Hangup()

How can I add the headers in the notify exactly ? Do I have to use the AMI ?



By: Mark Michelson (mmichelson) 2015-04-23 09:07:49.745-0500

You don't have to use AMI. You should have a {{pjsip_notify.conf}} file in your {{/etc/asterisk}} directory that has a section called "cisco_reboot". You can add the following to that section:

{noformat}
Max-Forwards=>70
Allow=>INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
Supported=>100rel, timer, replaces, norefersub
User-Agent=>Asterisk PBX
{noformat}

I got the values for those headers based on values I've seen Asterisk send. If you find that adding these headers helps, then you can try eliminating them one at a time to see which is the one that actually made the scenario succeed.

If none works, then I'll hit the drawing board again and see what else I can find.
By: Mark Michelson (mmichelson) 2015-04-23 11:01:54.663-0500

I've just noticed another difference between the working chan_sip and non-working chan_pjsip authentication attempts. In chan_sip, Asterisk bumps the CSeq up by one on the NOTIFY with auth credentials. In chan_pjsip, the exact same request is sent with auth credentials instead, meaning that the CSeq is the same between auth attempts. It may be that the phone sees this as a violation of CSeq order and responds with the same response as it did when the phone first received a NOTIFY with that CSeq.
By: Carl Fortin (phonefxg) 2015-04-23 11:10:48.746-0500

I have added the info to the pjsip_notify.conf but I still get the same message. You might be right about the CSeq....

[cisco-reboot]
Event=>restart_now
Max-Forwards=>70
Allow=>INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
Supported=>100rel, timer, replaces, norefersub
User-Agent=>Asterisk PBX


By: Mark Michelson (mmichelson) 2015-04-23 13:07:15.375-0500

Okay thanks for testing that out. I'll get back when I know something more.
By: Carl Fortin (phonefxg) 2015-04-23 13:09:19.168-0500

Sure, let me know if you need anything else from me.
By: Mark Michelson (mmichelson) 2015-04-23 14:41:10.777-0500

I'm attaching ASTERISK-24845.patch to the issue.  The patch is following up on the idea that perhaps the CSeq is the issue here by incrementing the CSeq number when sending an authed request.

Please apply this patch and see if the behavior persists.
By: Carl Fortin (phonefxg) 2015-04-23 18:32:57.435-0500

I have applied the patch to asterisk 13.3.2. I can confirm that the patch is working. Great job Mark!

Here is the proof:

dti-asterisk*CLI> pjsip send notify cisco-reboot endpoint U_9172
Sending NOTIFY of type 'cisco-reboot' to 'U_9172'
[Apr 23 19:25:56]     -- Removed contact 'sip:U_9172@10.188.4.30:5061' from AOR 'U_9172' due to request
[Apr 23 19:26:43]     -- Added contact 'sip:U_9172@10.188.4.30:5061' to AOR 'U_9172' with expiration of 3600 seconds
[Apr 23 19:26:47]     -- Removed contact 'sip:U_9172@10.188.4.30:5061' from AOR 'U_9172' due to request