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

Richard Mudgett (JIRA) noreply at issues.asterisk.org
Wed Mar 23 10:21:56 CDT 2016


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

Richard Mudgett edited comment on ASTERISK-25862 at 3/23/16 10:21 AM:
----------------------------------------------------------------------

Related issues that would be solved by proper dynamic payload type negotiation:
* ASTERISK-25166
* ASTERISK-6393
* ASTERISK-1755
* ASTERISK-17410
* ASTERISK-21382


was (Author: marekbernat):
Related issues that would be solved by proper dynamic payload type negotiation:
* https://issues.asterisk.org/jira/browse/ASTERISK-25166
* https://issues.asterisk.org/jira/browse/ASTERISK-6393
* https://issues.asterisk.org/jira/browse/ASTERISK-1755
* https://issues.asterisk.org/jira/browse/ASTERISK-17410
* https://issues.asterisk.org/jira/browse/ASTERISK-21382

> 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 issue, 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)



More information about the asterisk-bugs mailing list