This is actually a feature -- we do not accept RTP from any source, but verify that it comes from the peer we expect it to come from.
osmo-bsc and osmo-msc should instruct their respective MGWs to expect the right IP-address, in MGCP CRCX or MDCX messages.
If we receive early media before the endpoint is properly configured, then this error message happens.
See also https://gerrit.osmocom.org/10119 -- here we explicitly allow loopback-ing RTP to a femto cell in the early stage to trick the IuUP into thinking it was initialized.
So, the cause for this error is that RTP is coming in before the endpoint is properly configured.
Towards the BTS, we do this correctly, i.e. we only instruct RTP to start when the endpoint knows the BTS to expect RTP from.
This error message occurs because one call leg is already receiving RTP from the other call leg, before the call has been properly bridged.
So, both call legs' lchans are set up and ready for RTP, but we haven't told both sides yet where the respective other call leg sits.
The MSC's MGW is already in sendrecv and already sending RTP to the other call leg, but the other call leg isn't yet fully configured.
This error isn't really harmful, because it's all about early media, and should go away as soon as bridging is complete.
A naive solution would be to keep the MSC's endpoint in loopback mode until bridging is complete.
We did loopback until more or less recently: http://git.osmocom.org/osmo-msc/commit/?id=65d8d0d9b5b0a59bc34d5b5f3677e3cbe9d21a64
Instead of loopback, dropping on the floor is more accurate. That's what we do now.
But it would be less confusing if we could somehow mark this event as expected, and not error log about it.
