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

[Marek Bernat (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Bernat updated ASTERISK-25862:
------------------------------------

    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

  was:
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


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