Feature #2659
closedprepare osmo-mgw architecture for other endpoint types
Added by laforge over 6 years ago. Updated over 3 years ago.
100%
Description
there is still a lot of legacy that ties osmo-mgw to the old concept of "a statically allocated array of rtp-bridge endpoints"
Checklist
- get rid of endpoint integers and replace it with string (e.g. in log messages)
- dispatch messages like CRCX/MDCX to endpoint class specific operations after message decodin
- implement endpoint name matching based on endpoint class prefix like 'rtpbridge/'
Related issues
Updated by laforge almost 5 years ago
- Related to Bug #3260: Implement libosmo-abis input for new E1 interface added
Updated by laforge almost 5 years ago
- Related to Feature #2547: Add E1/T1 endpoint type to osmo-mgw added
Updated by dexter almost 4 years ago
- % Done changed from 0 to 50
I am currently cleaning up the source around the endpoint / trunk management. I have basically eliminated the integer based endpoint access. Also there is a better evaluation of the trunk prefix. For the virtual trunk things are fine, for E1 I have not done much yet. I still see that there osmo-mgw still requires a lot of cleanup. For example there is a lot of endpoint/trunk allocation related stuff in protocol.c, even though this has nothing to do with the protocol at all. I am about the get this cleaned up.
See also #2547
Updated by laforge almost 4 years ago
On Mon, May 18, 2020 at 06:59:15PM +0000, dexter [REDMINE] wrote:
For E1, I need to know if the following makes sense:
The spec suggests the following for the selection of an E1 (digital) endpoint:
ds/<unit-type1>-<unit #>/<unit-type2>-<unit #>/.../<channel #>I understand this recommendation like this:
ds/e1-0/s-2/su-1/0 => digital-trunk/e1-card number 0/timeslot 1/subslot 0/channel 0For the "channel" I am not sure.
Neither am I.
To keep it generic, we need to be able to express/address the following in the naming:- a full 64k timeslot
- a 32k sub-slot (up to 2 in one timeslot)
- a 16k sub-slot (up to 4 in one timeslot)
- a 8k sub-slot (up to 8 in one timeslot)
To make things more interesting, they can be mixed, e.g. you can have two 16k sub-slots
and 4 8k sub-slots within one timeslot.
so rather than 'su-1' (which doesn't state which sub-channel) I would suggest something like
su32-0 (bit 0..3)
su32-4 (bit 4..7)
su16-0 (bit 0..1)
su16-2 (bit 2..3)
su16-4 (bit 4..5)
su16-6 (bit 6..7)
su8-0 (bit 0)
su8-1 (bit 0)
su8-2 (bit 0)
su8-3 (bit 0)
su8-4 (bit 0)
su8-5 (bit 0)
su8-6 (bit 0)
su8-7 (bit 0)
This way the naming is very clear, i.e. it specifies unambigously which bits of each 64k timeslot byte
a given sub-channel is to use. One could then have combinations (simultaneously active sub-channels) like
su32-0 + su16-4 + su8-6 + su8-7
Feel free to make better proposals regarding the naming, but the semantics of identifying both
the sub-slot type and its bit offset in the byte are required.
Combinations with overlapping bit allocations are of course invalid, i.e. su16-0 + su8-1 would be illegal.
As far as I know the E1 timeslots are assigned to the air interface timeslot in a fixed way. Basically one E1 subslot maps on one UM timeslot.
The fact whether they are allocated fixed or not to Um interface timeslots does not matter
to the MGW. The MGW has no knowledge about GSM, and how the BSC and the BTS map Um timeslots
to E1 sub-slots should not matter to the MGW. All the MGW sees is a CRCX for some endpoint name,
and from that information it must be able to deduce all relevant details.
HR can be mapped on 16k sub-slots but also on 8k sub-slots. I am currently working on implementingNow I am not sure how half-rate channels would end up on the E1. Where does the demuxing take place (libosmo-abis)? Does my endpoint addressing model make sense?
the full processing chain in libosmo-*, that is
- I.460 demultiplex from 64k to any combination of sub-slots
- TRAU frame synchronization / alignment
- generic TRAU frame parsing
- payload-specific TRAU frame to RTP payload conversion (and vice versa)
How this will be integrated with the mgw is not clear at this point yet. My main
goal is to create something the MGW can be tested/developed against at this point.
In any case, the actual functionality will be in libosmocore + libosmo-trau (part of libosmo-abis).
Updated by dexter almost 4 years ago
I think the naming scheme you suggest is fine.
The combinations above would than result into the following endpoint names (assuming e1 card #0, TS1):
ds/e1-0/s-1/su32-0
ds/e1-0/s-1/su32-4
ds/e1-0/s-1/su16-0
ds/e1-0/s-1/su16-2
ds/e1-0/s-1/su16-4
ds/e1-0/s-1/su16-6
ds/e1-0/s-1/su8-0
ds/e1-0/s-1/su8-1
ds/e1-0/s-1/su8-2
ds/e1-0/s-1/su8-3
ds/e1-0/s-1/su8-4
ds/e1-0/s-1/su8-5
ds/e1-0/s-1/su8-6
ds/e1-0/s-1/su8-7
Is this list complete, or could we also have something like this?
su16-0 su32-2 su16-6 (16k + 32k + 16k)
The reason why I am asking this is because I see a problem with the modeling inside osmo-mgw. At the moment we allocate the entire trunk with all its endpoints once on startup and never free it. We also keep per endpoint counters, which I believe are not reset when a call ends. So basically we model the endpoints as a fixed resource. In the case of the virtual-trunk this is fine, we set up N endpoints and the system runs with it. Each endpoint has its fixed name that unambiguously identifies it.
I wonder how this would work out for an E1 trunk. It looks simple in the first place. The E1 trunk has limited resources, and a very specified way how they are allocated but how one timeslot is used is very dynamic. If the list above is complete I would say this is no problem, we could still move on with the statically allocated endpoints, all we would need is some logic that makes sure no illegal combination of endpoints is picked but if we can combine the various subslot types arbitrary like (e.g. 16k + 32k + 16k) the overhead would get to much I think.
I mean we could move on with a dynamic allocation for trunk endpoints but then we would loose the counter states each time a call ends. What do you think?
Updated by tnt almost 4 years ago
The list is complete you can't have 32k channel starting on bit 2. They are "aligned".
Updated by laforge almost 4 years ago
On Tue, May 19, 2020 at 03:34:07PM +0000, dexter [REDMINE] wrote:
The combinations above would than result into the following endpoint names (assuming e1 card #0, TS1):
Is this list complete, or could we also have something like this?
I think it is
su16-0 su32-2 su16-6 (16k + 32k + 16k)
I believe I.460 does not support such a layout. A 32 sub-slot will always start either at bit 0 or 4.
So you can have 32+16+16 or 16+16+32, but not the combination you outlined above.
I mean we could move on with a dynamic allocation for trunk endpoints but then we would loose the counter states each time a call ends. What do you think?
I think an E1 line has a fixed number of timeslots, and there is a fixed nubmer of sub-slots possible
on each of them. Resourecs are not dynamic, even more than for the virtual trunk. So I'm against
dynamic allocation.
Updated by dexter almost 4 years ago
- Checklist item get rid of endpoint integers and replace it with string (e.g. in log messages) set to Done
- Checklist item implement endpoint name matching based on endpoint class prefix like 'rtpbridge/' set to Done
Updated by dexter almost 4 years ago
- % Done changed from 50 to 70
Major changes to the architecture are done, however we are not there yet. The following patches are in review:
https://gerrit.osmocom.org/c/osmo-mgw/+/18831 cosmetic: remove excess space
https://gerrit.osmocom.org/c/osmo-mgw/+/18590 trunk: get rid of virt_trunk pointer
https://gerrit.osmocom.org/c/osmo-mgw/+/18745 endp: add name generator function for E1 endpoints
https://gerrit.osmocom.org/c/osmo-mgw/+/18752 trunk: parse E1 trunk number
https://gerrit.osmocom.org/c/osmo-mgw/+/18754 endp: move endpoint name generation into mgcp_endp.c
(https://gerrit.osmocom.org/c/osmo-mgw/+/18755 is still work in progress, lets focus on getting the pending patches as soon as possible)
Updated by dexter almost 4 years ago
- Checklist item dispatch messages like CRCX/MDCX to endpoint class specific operations after message decodin set to Done
We now have everything together to support E1 as our first "different" endpoint type. Endpoint names are strings and are also resolved as strings as well.
However, I think the way we currently resolve the trunks needs some re thinking. One problem is that the trunk number currently is the array index in the array of trunks. We probably should find a way to have a bit more freedom here. Also at the moment all additional trunks that are added by the user can only be E1 trunks. This limitation is more due to the way how VTY configuration works rather than it is a true limitation in the current architecture.
I have set the checkbox to the "dispatch messages like CRCX..." because there are no limitations here. The MGCP layer does not care about the endpoint time. It just uses the name as reference and the right endpoint from the right trunk is picked. So I think this is fine now. The RTP side is also already detached I think because we have callback functions that are picked depending on the endpoint type as well.
The audio playback endpoint is waht is still missing from the list. I think that such an endpoint would need a separate trunk with endpoint names like "playback/filename@mgw". However, this requires to revise the VTY config first.
Updated by laforge almost 4 years ago
- Checklist item deleted (
implement a simple "audio file playback" endpoint endpoint class to verify abstraction is complete)
Updated by dexter almost 4 years ago
- % Done changed from 70 to 100
Some of the patches above are still in review, lets keep this open until the patches are merged.
Updated by dexter almost 4 years ago
- % Done changed from 100 to 90
While integrating the E1 support I see that there is still quite a bit to refactor:
https://gerrit.osmocom.org/c/osmo-mgw/+/19163 mgcp_conn: move struct mgcp_conn mgcp_conn.h
https://gerrit.osmocom.org/c/osmo-mgw/+/19164 mgcp_internal: remove forward declaration struct mgcp_endpoint_type
https://gerrit.osmocom.org/c/osmo-mgw/+/19102 mgcp_trunk: pick trunk by number and type
https://gerrit.osmocom.org/c/osmo-mgw/+/19103 mgcp_vty: be more specific about E1 trunks
https://gerrit.osmocom.org/c/osmo-mgw/+/19120 mgcp_test: do not access endpoint array elements directly
https://gerrit.osmocom.org/c/osmo-mgw/+/19165 mgcp_test: remove trunk2 from unit-test
https://gerrit.osmocom.org/c/osmo-mgw/+/19166 mgcp_endp: add function to claim an endpoint
Maybe it is wise to report the not directly E1 related changes here. Unfortunately it is a problem to see every bit that needs to be changed in advance. I expect that when E1 support is done there needs to go one final run of refactoring to round everything up.
Updated by dexter over 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
