Bug #3539

osmo-mgw data from wrong address:, expected:

Added by duo_kali over 1 year ago. Updated about 1 year ago.

Target version:
Start date:
Due date:
% Done:



osmo-mgw log showing the error : data from wrong address:, expected:

this is the log file

Related issues

Has duplicate Cellular Network Infrastructure - Bug #3538: osmo-mgw data from wrong address:, expected:


#2 Updated by neels over 1 year ago

  • Has duplicate Bug #3538: osmo-mgw data from wrong address:, expected: added

#3 Updated by neels over 1 year ago

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

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.

#4 Updated by neels over 1 year ago

  • Assignee changed from duo_kali to neels
  • % Done changed from 0 to 90

#5 Updated by neels about 1 year ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

The patch to mark the event as "early media" instead of "error" has been merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)