[Asterisk-code-review] rtp engine.c: Initial split of payload types into rx and tx ... (asterisk[master])

Richard Mudgett asteriskteam at digium.com
Thu Aug 20 11:58:37 CDT 2015


Hello Anonymous Coward #1000019, Joshua Colp,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/1018

to look at the new patch set (#3).

Change subject: rtp_engine.c: Initial split of payload types into rx and tx mappings.
......................................................................

rtp_engine.c: Initial split of payload types into rx and tx mappings.

There are numerous problems with the current implementation of the RTP
payload type mapping in Asterisk.  It uses only one mapping structure to
associate payload types to codecs.  The single mapping is overkill if all
of the payload type values are well known values.  Dynamic payload type
mappings do not work as well with the single mapping because RFC3264
allows each side of the link to negotiate different dynamic mappings for
what they want to receive.  Not only could you have the same codec mapped
for sending and receiving on different payload types you could wind up
with the same payload type mapped to different codecs for each direction.

1) An independent payload type mapping is needed for sending and
receiving.

2) The receive mapping needs to keep track of previous mappings because of
the slack to when negotiation happens and current packets in flight using
the old mapping arrive.

3) The transmit mapping only needs to keep track of the current negotiated
values since we are sending the packets and know when the switchover takes
place.

* Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
use the new function because ast_rtp_codecs_payload_code() was used for
mappings in both directions.

* Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
to pass preferred codec mappings to the peer channel for early media
bridging or when we need to prefer the offered mapping that RFC3264 says
we SHOULD use.

* ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
the only new public functions created.  All the others were only used for
the tx or rx mapping direction so the function doxygen now reflects which
direction the function operates.

* chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
that makes no sense when processing an incoming SDP.  We would be wiping
out any mappings that we set for the possible outgoing SDP we sent
earlier.

ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac
---
M channels/chan_mgcp.c
M channels/chan_unistim.c
M include/asterisk/rtp_engine.h
M main/rtp_engine.c
M res/res_rtp_asterisk.c
M res/res_rtp_multicast.c
6 files changed, 495 insertions(+), 118 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/18/1018/3
-- 
To view, visit https://gerrit.asterisk.org/1018
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac
Gerrit-PatchSet: 3
Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Owner: Richard Mudgett <rmudgett at digium.com>
Gerrit-Reviewer: Anonymous Coward #1000019
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>



More information about the asterisk-code-review mailing list