Project

General

Profile

Actions

Bug #3539

closed

osmo-mgw data from wrong address: 127.0.0.1, expected: 0.0.0.0

Added by duo_kali over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/09/2018
Due date:
% Done:

100%

Spec Reference:

Description

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

this is the log file https://pastebin.com/6N00ZCGj


Files


Related issues

Has duplicate Cellular Network Infrastructure - Bug #3538: osmo-mgw data from wrong address: 127.0.0.1, expected: 0.0.0.0Rejectedduo_kali09/09/2018

Actions
Actions #2

Updated by neels over 5 years ago

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

Updated by neels over 5 years 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 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.

Actions #4

Updated by neels over 5 years ago

  • Assignee changed from duo_kali to neels
  • % Done changed from 0 to 90
Actions #5

Updated by neels over 5 years 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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)