| Summary: | ASTERISK-25573: [patch] H.264 format attribute module: resets whole SDP | ||
| Reporter: | Alexander Traud (traud) | Labels: | |
| Date Opened: | 2015-11-19 01:10:34.000-0600 | Date Closed: | 2015-11-20 09:22:36.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Formats/format_h264 |
| Versions: | 13.6.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) no_reset_in_generate_sdp_fmtp.patch | |
| Description: | When the video codec H.264 is negotiated, Asterisk has to forward (generate) the line fmtp. Because all parameters are optional according to [RFC 6184|https://tools.ietf.org/html/rfc6184#section-8], the line might be empty. In that case, Asterisk resets the given string buffer.
However, at least in the channel chan_sip, that string buffer contains not only the fmtp-data for H.264 but also parts of the SDP message like rtpmap and even other codecs. Consequently, H.264 gets disabled, other dynamic RTP payloads are not offered anymore, and the SDP negotiation results in a static RTP payload like G.711 audio without video. Asterisk 11 is not affected by this, because it uses another strategy to build the line fmtp. | ||
| Comments: | By: Alexander Traud (traud) 2015-11-19 01:21:49.098-0600 The attached patch fixes this; plus avoids a potential double-semicolon with the attribute sprop-parameter-sets. | ||