| Summary: | ASTERISK-25537: [patch] format-attribute module: RFC or internal defaults? | ||
| Reporter: | Alexander Traud (traud) | Labels: | |
| Date Opened: | 2015-11-10 09:26:07.000-0600 | Date Closed: | 2015-11-11 08:11:39.000-0600 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Formats/General |
| Versions: | 11.20.0 13.6.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 11_rtp_fmtp_RFC_default_by_M.patch ( 1) 11_rtp_fmtp_RFC_default_by_MAP.patch ( 2) 13_rtp_fmtp_RFC_default_by_M.patch ( 3) 13_rtp_fmtp_RFC_default_by_MAP.patch | |
| Description: | For example, the format Opus has an attribute module registered thanks to {{res/res_format_attr_opus.c}}. When Opus is negotiated in SIP/SDP, {{ast_format_parse_sdp_fmtp}} calls this module to parse the line {{fmtp}}. However, {{fmtp}} is optional for many formats including Opus. Therefore, the attribute module might not be called in all SIP/SDP negotiations correctly.
Without a {{fmtp}}, default values are specified. These defaults describe the RTP payload which is brought to Asterisk for example by a VoIP/SIP client. Or stated differently: A VoIP client specifies its defaults to Asterisk. Asterisk negotiates between its internal defaults and the external {{fmtp}}. When a VoIP client does not send {{fmtp}} at all, the last sentence changes into: Asterisk negotiates between it’s internal defaults and the defaults of the RFC. However, the defaults of the RFC might not be the internal defaults of Asterisk. For example, some RFCs are backward compatible: * iLBC 20: Asterisk {{mode=20}} [RFC 3952|https://tools.ietf.org/html/rfc3952#section-4.2] {{=30}} * AMR: Asterisk {{mode-change-capability=2}} [RFC 4867|https://tools.ietf.org/html/rfc4867#section-8] {{=1}} * Opus: Asterisk {{useinbandfec=1}} [RFC 7587|https://tools.ietf.org/html/rfc7587#section-6.1] {{=0}} Currently, I am not aware of any trick to determine whether a format was created because of external means (for example a VoIP client). Consequently, I am not able to apply defaults while doing {{format_get_joint}} or {{format_cmp}}, in case {{format_parse_sdp_fmtp}} was not called. Therefore, I am not able to negotiate correctly within SDP. | ||
| Comments: | By: Alexander Traud (traud) 2015-11-10 09:42:04.190-0600 The attached patches solve this issue simply by parsing an empty line of attributes, even when there is no line {{ftmp}} but a line {{rtpmap}} in SDP. With this, {{format_parse_sdp_fmtp}} can be used to apply the RFC defaults. There, the attribute data can marked as being an externally created format. If no attribute data is present in {{format_get_joint}} or {{format_cmp}}, the Asterisk internal default can be assumed. There is a corner case: {{rtpmap}} itself is optional if the payload is not a dynamic but a static one. However, because this is a pathological case – I am not aware of a format/codec with a static RTP payload ID, which could benefit from this change – that part of the patch was not submitted for review. Nevertheless, if somebody needs this one day, a patch was added to parse every codec mentioned in the line {{m}}, see {{_by_M.patch}}. Finally, because the format structure and handling changed between Asterisk 11 and Asterisk 13, we have two sets = four patches. | ||