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

Marek Bernat (JIRA) noreply at issues.asterisk.org
Wed Mar 23 10:43:56 CDT 2016


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

Marek Bernat commented on ASTERISK-25862:
-----------------------------------------

I don't think it's a duplicate at all (the other issue only mentions audio and not DTMF, for example) but I'm fine with it as long as someone is working on a solution. This wasn't clear to me as nobody replied to that issue in almost a year. Also, that issue is flagged as Minor, which is puzzling given how major and complex this problem is.

> 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