[asterisk-bugs] [Asterisk 0019281]: [patch] Invite with session description that supports both SRTP(SAVP) and RTP(AVP) fails if asterisk is not configured to use SR

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19281 
====================================================================== 
Reported By:                jacco
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   19281
Category:                   Channels/chan_sip/SRTP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.8.4 
JIRA:                       SWP-3458 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-05-12 02:17 CDT
Last Modified:              2011-05-13 03:59 CDT
====================================================================== 
Summary:                    [patch] Invite with session description that
supports both SRTP(SAVP) and RTP(AVP) fails if asterisk is not configured to use
SR
Description: 
I was doing an interoperability with a HiPath 3000 V8 M5T SIP
Stack/4.0.26.26 and it failed.

It has to do with an invite with session desription that supports both
SRTP(SAVP) and RTP(AVP); when asterisk is not configured for SRTP it will
not start an RTP session.
Asterisk CLI shows : 
chan_sip.c: Can't provide secure audio requested in SDP offer
and does not continue with setting up rtp

I guess it should provide an insecure audio request en continue with RTP

tested in asterisk 1.8.2.4 and asterisk 1.8.4



====================================================================== 

---------------------------------------------------------------------- 
 (0134879) schmidts (manager) - 2011-05-13 03:59
 https://issues.asterisk.org/view.php?id=19281#c134879 
---------------------------------------------------------------------- 
i uploaded a not malformed patch which helps but only in this special
case.

the reporter told me he has found the rfc where this behavior is described
in rfc3264. In part 5.1 the definition tells:

In all cases, the formats in the "m=" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.

----

A stream that is offered with a port of zero MUST be marked with port
   zero in the answer.  Like the offer, the answer MAY omit all
   attributes present previously, and MAY list just a single media
   format from amongst those in the offer. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-13 03:59 schmidts       Note Added: 0134879                          
======================================================================