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