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