Mode-Change Capability

[mtryfoss]

Incoming call to Asterisk from an Ericsson MSC using AMR-NB seems to work as it should.
Outgoing calls (transcoding from alaw to amr) from Asterisk is sent without fmtp-line, and the switch rejects the call. I manually hardcoded in the fmtp in the outgoing request and then the switch accepted it.

I'm going to investigate more on this tomorrow, but do you got any tips?
Asterisk 13.6.0 as a base
chan_sip (not pjsip)

[traud]

Yes, when you start the call within Asterisk, the current code does not send an fmtp-line because the module uses the defaults of RFC 4867 and all attributes are optional. Is Ericsson expecting
A) any particular attribute, like octet-align or
B) an unique attribute=value pair, like mode-change-capability=2 or
C) simply a fmtp-line, no matter what attribute is listed?

Or asked differently: Which fmtp-line worked so far = which did you hard code? You are able to play with the attributes via the struct default_amr_attr in res/res_format_attr_amr.c. There, every non-default value triggers the fmtp-line, then. With the mode_change_* attributes, every non-zero value triggers the fmtp-line. Start with mode_change_capability=1 (case C). If that was not the culprit, try mode_change_capability=2 (case B). Then octet_align=1 (case A), then any other attribute combination (case A or case B).

[mtryfoss]

This is the line Ericsson sends in the INVITE to us:

a=fmtp:96 mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0

It worked when I sent this in the INVITE back. I will try to narrow down.

[mtryfoss]

It did not work with mode-change-capability=1, but worked well with mode-change-capability=2 (only this parameter). I'll check the Ericsson documentation for any settings related to this.

[mtryfoss]

Here is the documentation regarding SDP from Ericsson.

[mtryfoss]

[traud]

Thank you for testing! Consequently, case B was the cause. It is allowed to reject the payload, when mode-change-capability=2 is not offered but required by the answerer, especially when he requires mode-change-period=2. Consequently, Ericsson does not do anything wrong here.

Therefore, let us have a look at my side: Currently in the transcoding module codecs/codec_amr.c, the attributes mode-change-* are neither honoured nor implemented. Therefore, I did not specify mode-change-capability=2 in the format module res/res_format_attr_amr.c. Nothing wrong either. The attributes exist in the format module, to allow proxying these attributes only.

Consequently, you hit an interoperability issue. Until mode-change-period and mode-change-neighbor are implemented, you could change mode-change-capability from 0 to 2 in the default_amr_attr. Anyway, that would be a lie. I have to update the missing section of the Read Me.

Before somebody implements this, another question: What is your architecture – what role has your Ericsson device in your scenario? Because you mentioned a license, is that device able to transcode itself? In that case, what about continuing to feed it with G.711/G.722 instead of AMR(-WB)?

[mtryfoss]

I understand.

We are a small MVNO and the Ericsson device is our switch (MSC). We use a cluster of Asterisk-instances to add virtual switchboard services to our mobile subscribers. We will soon have AMR/AMR-WB as codecs to handle when Asterisk is going to be an application server in the IMS network (VoLTE calls).

How much work do you expect it would be to implement this?

[traud]

Implementation takes around two hours. However for this, I do not see any resources (available time-slot) till Christmas. Beside that, I have no idea how to test that additional code, then. If you are not able to code yourself, somebody could speed-up this by providing test cases.

[mtryfoss]

I will be happy to help with testing and/or providing necessary development environment. Don't hesitate contacting me. Thanks for all the nice work so far!

[traud]

Thank you for the offer. It is always good to have a second testing environment. However, I am looking more for at least one test case: When does who change the mode, and how does our module have to honour mode-change-period and mode-change-neighbor then. To be honest, I do not get that, yet. Currently, our module follows the change-mode request (CMR) of the other party – in your case Ericsson. Are there CMRs from Ericsson which should not be executed immediately? If there is no such thing, we would have a working mode-change capability already. In that case, you are able to set the mode-change capability in default_amr_attr already.

[mtryfoss]

I completely forgot this case.

• .mode_change_capability = 0, /* not supported */
• .mode_change_capability = 2, /* not supported */

seemed to do the trick. The call was accepted and there are two-way audio.

We're soon about to have AMR-WB licenses in the switch and I will do some testing with that as well.