Hi Nick,
I just read your post
https://nickvsnetworking.com/tales-from-the-trenches-mode-set-in-amr/
and just when it really gets interesting, the article ends =)
I'm working at osmocom.org and am currently figuring out how TH we are supposed
to communicate the AMR mode sets across 2G + 3G mobile networking on the one
side and SDP/SIP+RTP on the other side.
My plan was to do it like choosing codecs: One side sends all its capabilities,
the other responds with the own capabilites removing unsupported entries.
Now I read in your post that mode-set is take-it-or-leave-it.
The interesting part is the practical problem that arises from it: e.g. on a 2G
mobile network, i'm allowed to choose up to four AMR rates, no more. When on a
half-rate channel, then specific rates (12k2, 10k2) are not supported.
Otherwise I can tell the 2G BTS and the phone to pick various mode-set
combinations. So why not send a full mode-set of 0,1,2,3,4,5,6,7 and the other
call leg can then say "i'll pick these four", or something like that.
With your spec references, it means that now I need to pick specific mode-set
combinations in advance, and assign a different payload type number to each of
them.
The extreme example would be:
a rtpmap:110 AMR/8000/1
a fmtp:110 mode-set=0
a rtpmap:111 AMR/8000/1
a fmtp:111 mode-set=1
a rtpmap:112 AMR/8000/1
a fmtp:112 mode-set=2
...
a fmtp:117 mode-set=7
a fmtp:118 mode-set=0,1
a fmtp:119 mode-set=0,2
a fmtp:120 mode-set=0,3
a fmtp:121 mode-set=0,4
...
a fmtp:99999998 mode-set=0,1,2,3,4,5,6
a fmtp:99999999 mode-set=0,1,2,3,4,5,6,7
Obviously nonsense, but you catch my drift.
So what is the solution then?
In 2G GSM I have half-rate and full-rate channels; AMR-FR and AMR-HR should be
able to interop. So if one FR side offers mode-set=0,2,4,7 then the HR side may
return mode-set=0,2,4 to leave only HR compatible rates. Well, no.
If not that, then:
I probably need to create one RTPMAP entry for full-rate compatible operation
and another entry for half-rate compatible operation.
111:mode-set=0,2,4,7 112:mode-set=0,2,4
Also some hardware supports only 12k2, so then I need to add an extra entry for
only 12k2. But I have to so not only on the side that has the 12k2 limit, but
on the side that wants to interop with it! Because if the peer doesn't offer a
single "mode-set=7", then the only-12k2 supporting side must reject the entire
call.
111:mode-set=0,2,4,7 112:mode-set=0,2,4 113:mode-set=7
The question is, were the specs in good intentions, but in practicality it is
mayhem of exploding nr of permutations, and maybe your MGW made a sane choice
of not diving into this madness?
Thanks for your feedback on this!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
I have a request for comments regarding osmo-mgw,
particularly the fmtp for AMR octet-align mode and the two GSM-HR variants.
We are currently reviewing/writing patches to allow flexible use of fmtp in
libosmo-mgcp-client. The plan is to be able to indicate which GSM-HR variant
(RFC5993 or 3GPP TS 101.318) is in use.
Also we are fixing the ability to indicate AMR mode (octet-align=1 vs 0)
properly, per payload type nr instead of once per SDP body.
Example of MGCP with SDP, showing two codecs, AMR as 112 and GSM-HR as 111,
each with a fmtp as I'm discussing now:
CRCX 2 7@mgw MGCP 1.0
C: 2
v=0
c=IN IP4 123.12.12.123
m=audio 5904 RTP/AVP 112 111
a=rtpmap:112 AMR/8000/1
a=fmtp:112 octet-align=1
a=rtpmap:111 GSM-HR-08/8000/1
a=fmtp:111 gsm-hr-format=3gpp-ts-101.318
a=ptime:20
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.
So far so complex, BUT:
In practical testing, I see from logging that osmo-mgw is already quite capable
of detecting which AMR octet-align mode and which HR format is actually
arriving from the RTP peer (from the BTS...).
I see this log line:
DRTP NOTICE (rtpbridge/1@bsc0 I:FA1F785D) rx_rtp(44 bytes): Expected RTP AMR octet-aligned=1 but got octet-aligned=0. check the config of your call-agent! (mgcp_network.c:1525)
And I'm thinking, where is the problem, just do what you need to do; all the
information it needs to do the right thing is already available to osmo-mgw.
So why even the need to configure {AMR octet-align|GSM-HR mode} in SDP?
Idea:
- the first RTP packet arriving is examined, and from then on the peer is
known to use that format.
- when later, an RTP needs to be forwarded back to that peer, we convert to the
format that the peer uses, iff it is necessary.
- for sanity we could hold back forwarding RTP before the details of the
recipient are known, i.e. wait for each peer to send the first RTP to MGW.
Example for an RTP stream in GSM-HR format:
A MGW B
|--HR(3gpp)-->|--x drop | (don't know B's preference yet, cannot send)
| [3gpp]| | (now know A uses the 3gpp format)
| |<--HR(rfc)--|
| |[rfc] | (now know B uses the RFC format)
| [convert] |
|<--HR(3gpp)--| |
|--HR(3gpp)-->|--HR(rfc)-->|
|<--HR(3gpp)--|<--HR(rfc)--|
There is an important difference between AMR octet-align and GSM-HR:
- '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.
- 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)
What do you think?
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hello various Osmocom mailing lists,
the official Osmocom binary packages will not be built anymore for the
following distributions starting at 2024-02:
* Raspberry Pi OS 64-bit (use Debian_12 etc. instead)
* Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available)
* openSUSE 15.4 (openSUSE Tumbleweed feed is available)
* Debian Testing (Debian Unstable and 12-10 feeds are available)
For Raspberry Pi OS 64-bit users, make sure to adjust your
/etc/apt/sources.list.d as described here to switch to a Debian
aarch64 feed:
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
See the new linux distributions article for information on how long we
plan to keep building packages for each distribution:
https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio…
Let me know if you have questions.
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
