[asterisk-bugs] [JIRA] (ASTERISK-25862) No support for dynamic payload types in direct media

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229993#comment-229993 ] 

Asterisk Team commented on ASTERISK-25862:
------------------------------------------

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].

> No support for dynamic payload types in direct media
> ----------------------------------------------------
>
>                 Key: ASTERISK-25862
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25862
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.6.0, 13.7.2
>            Reporter: Marek Bernat
>
> Dynamically configured RTP payload type information is not correctly negotiated during SIP invite session. As a result neither dynamic audio codecs (such as Opus) nor non-standard DTMF configurations (such as {{rtpmap:98 telephone-event}}) currently work in a direct media setup.
> This is not a new, it has been reported at least five times already, although no reporter seems to had realized the full scale of the problem.
> WORKAROUND: The code that's currently meant to handle the dynamic payload type lookup in {{main/rtp_engine.c}} behaves very impredictably, which is why we ended up with a patch of ignoring endpoint SDP payload type information completely and instead forcing static payload type information from {{static_RTP_PT}} list. This is not a great solution, but it's the best that is currently possible since proper dynamic payload negotiation would probably involve a major overhaul of the Asterisk bridging / channel synchronization implementation. In what follows I describe our current understanding of the problem.
> BEGIN_IMPLEMENTATION_DETAILS
> The payload mapping information is kept in the {{payloads}} field of the {{ast_rtp_codecs}} type of the session of each channel and is used during SDP stream creation using the {{ast_rtp_codecs_payload_code}} of the {{main/rtp_engine.c}}.
> The problem is, this data is almost never synchronized across channels (the only occurence of payload types being copied is with {{ast_rtp_instance_early_bridge_make_compatible}} called from {{dial_exec_full}}, but this is not sufficient to fully propagate the data to the peer) which means that dynamically configured payload types cannot work in the direct media mode, even in principle.
> END_IMPLEMENTATION_DETAILS



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