Hi Neels,
On Thu, Dec 07, 2023 at 02:19:08AM +0100, Neels Hofmeyr wrote:
That means that each MGW client tells osmo-mgw exactly
what AMR and HR formats
to send to the RTP peer, and also restricts exactly which format to expect from
that RTP peer. So BSC and MSC need to know things about BTS and BSS, in advance:
- the BSC needs configured knowledge of each BTS's octet-align and gsm-hr-format.
- the MSC needs configured knowledge of what the BSC will do.
- what if there are divergent formats in different BTS of a BSS, does MSC need to know
that too?
There is certainly no way to indicate octet-align nor HR variant in standard A
interface proto.
IMHO, the BSC and its colocated MGW should "hide" all the RAN-internal
details from the MSC. A MSC should never have to know anything specific
about each and every BTS, or even how many BTS there are.
The AoIP interface is the only where the RTP format / codec types /
payload types are specified. We should always use what's specified in
TS 48.103.
So if a BTS has some differnt format on the Abis side, the bsc-colocated
MGW would need to convert to the one format specified by TS 48.103 on AoIP
- 'octet-align=(0|1)' is a defined standard
fmtp that already exists, and it
may be necessary to forward this accurately to PBX. We may not get around
having to explicitly set this.
Yes, following the spec where there is one is a good idea.
- GSM-HR format is a new fmtp we are inventing now. So
the idea is most
relevant here: if we can always just autodetect the right thing to do, then
why introduce a non-standard fmtp? (plus all the MGW client vty cfg needed)
I would do whatever is less effort here, given that the interest in GSM-HR is very
low in 2023, and we have to conserve our capacity to where it really matters.
--
- Harald Welte <laforge(a)osmocom.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)