Cellular Network Infrastructure » OsmoMGW

The most minimal "RTP proxy" that is apparently sufficient for nano3G operation would
merely change the UP Initialization sent to a nano3G to an ACK Initialization
by writing 0xe4 to the Initialization message's first byte...

This is currently done in our MGCP-GW (openbsc.git:osmo-bsc_mgcp on branch neels/nano3G),
notably without detecting whether it is indeed IuUP being forwarded but by crudely writing
0xe4 to the first payload forwarded in an RTP stream. Definitely needs improvement.

neels wrote:

The most minimal "RTP proxy" that is apparently sufficient for nano3G operation would
merely change the UP Initialization sent to a nano3G to an ACK Initialization
by writing 0xe4 to the Initialization message's first byte...

To clarify, one side would send an UP Initialization, and the other side would send
an Initialization ACK. The nano3G seems to omit the Initialization ACK even though it
receives an Initialization, possibly because it assumes to be the first to have sent
the Initialization and thus deserves an ACK from the other side instead of being the
party that should ACK. In our case, the other side is so far the same nano3G itself,
because we first echo back the RTP streams to the sender until both legs of the call
are established, at which point we switch RTP from echo to forward mode. Maybe this
should actually change so that the nano3Gs talk to each other directly concerning
IuUP Initialization and ACK, in which case a proxy might be necessary to change the
second Initialization to an ACK as indicated above.

neels wrote:

Maybe this
should actually change so that the nano3Gs talk to each other directly

right now I don't see how this can work. According to our MNCC code in OsmoMSC, we first need to establish both call legs before we can BRIDGE two calls. Establishing a call leg centrally depends on the RAB Assignment to be successful. Having that succeed centrally depends on the UP Initialization to succeed. So it would always need to be our MGW (aka MGCP-GW aka osmo-bsc_mgcp) that responds with the Initialization ACK, IIUC.

shouldn't this go to OsmoMGW? Maybe assign to dexter?

The interesting problem here is how to express IuUP in MGCP.

We cannot introduce separate endpoint types, as this would mean we can never connect an IuUP (3G) and plain RTP (2G) connection together. So this support will probably be at conncetion level, so a single RTP-bridge endpoint can have connections either in RTP or in IuUP-fashion.

Based on seveal soruces, and the fact that IuUp is more or less identical to IuNp, the SDP for IuUP should look like this:

m=audio 49300 RTP/AVP 97
a=rtpmap:97 VND.3GPP.IUFP/16000

Where 16000 is of course only applicable in case of AMR-WB. The key part is the "VND.3GPP.IUFP" part instead of "AMR".

My humble guess would be that if we activate the voice bearers with "RANAP_UserPlaneMode_transparent" there would be no IuUP inside the RTP to begin with.

Not aware of it; I remember that I tried to tweak around various parameters when attempting to get the nano3G to run, but am not sure whether I tweaked this one in particular. Would be good to try.

Only thing missing is rework codec related code to have 2g<->3g calls at the osmo-msc collocated osmo-mgw working properly. This can be addresses after the SDP improvement patches for osmo-mgw are merged. Other stuff is working. So we can close this ticket.