[asterisk-bugs] [JIRA] (ASTERISK-25537) [patch] format-attribute module: RFC or internal defaults?

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-25537:
---------------------------------------

    Comment: was deleted

(was: 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].)

> [patch] format-attribute module: RFC or internal defaults?
> ----------------------------------------------------------
>
>                 Key: ASTERISK-25537
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25537
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Formats/General
>    Affects Versions: 11.20.0, 13.6.0
>            Reporter: Alexander Traud
>            Severity: Minor
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)