| Summary: | ASTERISK-25862: No support for dynamic payload types in direct media | ||||
| Reporter: | Marek Bernat (marekbernat) | Labels: | |||
| Date Opened: | 2016-03-23 09:21:49 | Date Closed: | 2016-03-23 10:53:30 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | |||
| Versions: | 13.6.0 13.7.2 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | 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 | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-03-23 09:21:50.089-0500 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]. By: Marek Bernat (marekbernat) 2016-03-23 09:24:14.050-0500 Related issues that would be solved by proper dynamic payload type negotiation: * ASTERISK-25166 * ASTERISK-6393 * ASTERISK-1755 * ASTERISK-17410 * ASTERISK-21382 By: Richard Mudgett (rmudgett) 2016-03-23 10:24:58.303-0500 ASTERISK-25862 really does not say anything new that is not already in ASTERISK-25166 By: Marek Bernat (marekbernat) 2016-03-23 10:43:43.248-0500 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. By: Asterisk Team (asteriskteam) 2016-03-23 10:43:43.415-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Joshua C. Colp (jcolp) 2016-03-23 10:53:31.037-0500 The issue mentioned, ASTERISK-25166, is not currently being worked on as far as I am aware but is open specifically to track this. If you would like to see it worked on sooner you may want to try to find interest amongst the development community, otherwise it will fall to a Digium developer and may take some time to get to (which I have no time frame on). I have also escalated the issue to Major. | ||||