[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:comment-tabpanel&focusedCommentId=228232#comment-228232 ] 

Alexander Traud edited comment on ASTERISK-25537 at 11/10/15 12:28 PM:
-----------------------------------------------------------------------

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.


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

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.

> [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
>         Attachments: 11_rtp_fmtp_RFC_default_by_MAP.patch, 11_rtp_fmtp_RFC_default_by_M.patch, 13_rtp_fmtp_RFC_default_by_MAP.patch, 13_rtp_fmtp_RFC_default_by_M.patch
>
>
> 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)