Bug #5308


confusion around mgw e1 line vs trunk dichtomy

Added by laforge over 2 years ago. Updated about 2 years ago.

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


Spec Reference:


there seems to be some lack of logical clarity how the MGCP endpoint names are constructed for use with E1.

  • osmo-mgw uses the trunk number to construct the "e1-N" part in "ds/e1-0/s-1/su16-0"
    • any e1_input line_nr can be mapped to any trunk_nr in the config
  • osmo-bsc unconditionally uses the e1_input line_nr to construct the "e1-N" part in "ds/e1-0/s-1/su16-0"
This means that the entire setup will only work, if osmo-mgw is confiugred to use the same trunk_nr as e1_input line_nr, which
  1. is weird, as why would you make something configurable if it only works in one way, and
  2. is not mentioned or documented anywhere in either the osmo-mgw or osmo-bsc documentation, and also not really visible from the example configs, AFAICT

So I think we have two ways forward:

  1. make osmo-mgw always use the e1 line_nr for constructing the enpdoint names
  2. allow osmo-bsc to configure the mgw-side trunk number [for each timeslot?]
Actions #1

Updated by laforge over 2 years ago

at the very least, even if we do nothing now, the existing constraint should be documented, and osmo-mgw could even print some warning if a bsc-incompatible configuration was attempted.

Actions #2

Updated by laforge over 2 years ago

  • Category set to RTP/Media

from a logical point of view, I think extending the BSC side configuration makes more sense. In the end, it is also imaginable that somebody might have too many e1 lines to handle by a single mgw, so the BSC wouldn't only need to allow to configure the trunk number, but also the remote mgw ip/host, too. Or some hypothetical non-osmocom mgw might have a completely different endpoint naming scheme.

So making the bsc more configurable/flexible sounds like the right way to go ahead. Together with documentation, of course.

Actions #3

Updated by tnt over 2 years ago

The MGW will always be co-located with the BSC if they need to access the same E1 card.

Actions #4

Updated by dexter over 2 years ago

  • Status changed from New to In Progress

The relation between E1 line number and the trunk number is indeed not obvious. I have updated the config now: bts-examples: add example for E1 connected BTS configuration: point out difference between trunk-nr and e1 line nr

I think the next task here should be to make the trunk number configurable so that we basically have a similar flexibility like we already have in osmo-mgw. The scenario where multiple MGWs are assigned to different BTSs could be handled by the MGW pool. We could just assign one specific pool member to each BTS.

What I am not sure with are the line numbers on the BSC that are set up for the voice channels. As far as I know those numbers are not used for anything other than addressing the trunk (and with that the lines) on the MGW side, or is there more to it? If not, then this is just a naming problem. "e1 line 0 timeslot 3 sub-slot 3" could be expressed as "mgcp trunk 0 timeslot 3 sub-slot 3" for example?

Also If we start to extend the configuration scheme I would need to get my test setup up and running again to make sure we do not break anything.

Actions #5

Updated by dexter over 2 years ago

The problem as I understand it now: We can set up an arbitrary trunk number and assign a physical E1 line to it (no problem with that, its just flexibility). We have a naming problem on osmo-bsc, we mean trunk number, but we write e1 line in the configuration.

Actions #6

Updated by dexter about 2 years ago

  • Status changed from In Progress to Stalled

The updates for the documentation are merged now. So we can set this to stalled for now.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)