[asterisk-bugs] [Asterisk 0017758]: Asterisk just reads the first "Accept" header

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17758 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17758
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.33.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-29 16:31 CDT
Last Modified:              2010-07-30 01:46 CDT
====================================================================== 
Summary:                    Asterisk just reads the first "Accept" header
Description: 
When a SUBSCRIBE "Event: dialog" comes to Asterisk it takes the first
"Accept" header value as the only one, discarding all the rest, so it
replies "489 Bad Event" if it doesn't recognize the first "Accept" value.

Real example:


This is a SUBSCRIBE coming from a Linksys SPA phone without using the
specific "asterisk BLF mode" (a mode which shouldn't exist as "event"
subscription is a RFC standard):

SUBSCRIBE sip:8888 at 222.222.19.1 SIP/2.0'
Via: SIP/2.0/UDP 192.168.1.14:25060;branch=z9hG4bK-f443274c;rport'
From: <sip:cliente8888 at 222.222.19.1>;tag=a833e3091d78eb5'
To: <sip:8888 at 222.222.19.1>'
Call-ID: 7645f40c-c2e2f289 at 192.168.1.14'
CSeq: 63626 SUBSCRIBE'
Max-Forwards: 70'
Contact: <sip:cliente8888 at 192.168.1.14:25060>'
Accept: multipart/related'
Accept: application/rlmi+xml'
Accept: application/dialog-info+xml'
Expires: 1800'
Event: dialog'
User-Agent: Linksys/SPA942-6.1.5(a)'
Content-Length: 0'
Supported: replaces, eventlist'

Asterisk replies 489 Bad Event (format multipart/related).


This is a SUBSCRIBE coming from the same SPA phone by using "asterisk BLF
mode":

SUBSCRIBE sip:8888 at 222.222.19.1 SIP/2.0'
Via: SIP/2.0/UDP 192.168.1.14:25060;branch=z9hG4bK-3733da3b;rport'
From: <sip:cliente8169 at 212.230.19.1>;tag=d041391aac7ac1b5'
To: <sip:8888 at 222.222.19.1>'
Call-ID: 70dd34be-24845a61 at 192.168.1.14'
CSeq: 50627 SUBSCRIBE'
Max-Forwards: 70'
Contact: <sip:cliente8169 at 192.168.1.14:25060>'
Accept: application/dialog-info+xml'
Expires: 1800'
Event: dialog'
User-Agent: Linksys/SPA942-6.1.5(a)'
Content-Length: 0

In this case Asterisk replies "200 OK" as it understands
application/dialog-info+xml.



The differences are:

1)
 Accept: multipart/related'
 Accept: application/rlmi+xml'
 Accept: application/dialog-info+xml'
 Supported: replaces, eventlist'

2)
 Accept: application/dialog-info+xml'


Of course, the expected behavior is Asterisk to inspect *all* the "Accept"
headers and *all* the possible comma separated values in each "Accept"
header. There is no "preference" based on the Accept value position as
Asterisk should select its preferred value.
====================================================================== 

---------------------------------------------------------------------- 
 (0125360) oej (manager) - 2010-07-30 01:46
 https://issues.asterisk.org/view.php?id=17758#c125360 
---------------------------------------------------------------------- 
It is clearly a bug when we can't parse a standard SIP message. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-30 01:46 oej            Note Added: 0125360                          
======================================================================