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 <[email protected]>           https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Reply via email to