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