Bug #3384
closedTranslate PT before sending RTP packets (different PT numbers, but same codec on two connections)
100%
Description
When dynamic payload types are used and the call-agent configures two connections with the same codec, but different payload type numbers then osmo-mgw must ensure that the RTP packets are sent with the correct payload type number. This means on the ingress connection the MGW must lookup the codec by the payload type number. On the egress connection the MGW must use the previously looked up codec to determine the matching payload type number that is configured for that codec on the egress connection.
We need: Payload-type number re-writing in osmo-mgw and a TTCN3 testcase that verifies this behavior.
Updated by dexter over 5 years ago
We first need a TTCN3 test for this. As a primer I have added some logic so that the test sets the payload type in the RTP stream as well.
See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10076/
Next we need some mechanism to count packets with a non matching payload type number. As far as I know this is not yet done. We can just add a memeber in the statistics record we already have. Then we would setup a test with two different payload types on both ends and we should be able to detect the problem. Once that is done, we can think of ways to do the payload type translation inside the MGW.
Updated by dexter over 5 years ago
We now have a testcase for the behavior described above. See also:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10155 MGCP_Test: Test what happens when two ends use different PT
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10154 MGCP_Test: add function to check for RTP err counters
Updated by dexter over 5 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 100
osmo-mgw does now translate the payload types when possible:
https://gerrit.osmocom.org/#/c/osmo-mgw/+/10171 mgcp_client_fsm: allow ptmap in mgcp_client_fsm as well
https://gerrit.osmocom.org/#/c/osmo-mgw/+/10172 mgcp_network: translate payload type numbers in RTP packets
Updated by dexter over 5 years ago
- Status changed from In Progress to Resolved
All patches are merged and the TTCN3 tests are passing. I think we can set this to resolved.
