Summary:ASTERISK-26065: chan_pjsip: MWI NOTIFY contents not ordered properly
Reporter:Ross Beer (rossbeer)Labels:
Date Opened:2016-05-26 04:31:03Date Closed:2016-05-31 12:41:46
Status:Closed/CompleteComponents:Resources/res_pjsip_mwi Resources/res_pjsip_mwi_body_generator
Versions:13.9.1 Frequency of
Environment:CentOS 7Attachments:
Description:PJSIP is reporting mal-formed packets when sending voicemail Notifications:
[2016-05-26 10:20:22] ERROR[22460]: pjproject:0 <?>:    sip_transport. Error processing 620 bytes packet from UDP <IP Removed>: PJSIP syntax error exception when parsing 'Status Line' header on line 2 col 2:
SIP/2.0 400 ../../rutil/ParseBuffer.cxx:669, Parse failed Expected a digit, got: sip:1571@<IP Removed>:5060
in context: Contents
Messages-Waiting: no
Voice-Message: 0/0 (0/0)
Message-Account: sip:1571@<IP Removed>:5060[CRLF]

Via: SIP/2.0/UDP <IP Removed>:5060;rport=5060;branch=z9hG4bKPj1bf70ab5-b450-49e9-923e-fb1e1228b48a
To: <sip:<ACCOUNT REMOVED>@<IP Removed>;rinstance=784a071431a881b7>;tag=1da26c29
From: <sip:<ACCOUNT REMOVED>@<IP Removed>>;tag=66f68e25-0513-4aec-89e5-7ac7c629add6
Call-ID: dfd314b5-c634-481a-9d82-39d0b35fc12e
CSeq: 30479 NOTIFY
Accept-Language: en
Content-Length: 0
Comments:By: Asterisk Team (asteriskteam) 2016-05-26 04:31:05.223-0500

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: Ross Beer (rossbeer) 2016-05-26 06:50:54.898-0500


This issue looks to be related to clients incorrectly parsing the MWI NOTIFY packet, this is due to the order of the Message-Account. Once re-organising it to the following, the issue goes away:
Messages-Waiting: no
Message-Account: sip:1571@<SERVER IP>;transport=TLS
Voice-Message: 0/0 (0/0)

Can the message order be brought into line with earlier versions of asterisk and rfc3842?