Project

General

Profile

Feature #1937

Implement way how to handle IuUP on RTP endpoints

Added by laforge over 1 year ago. Updated 24 days ago.

Status:
New
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
02/03/2017
Due date:
02/03/2017
% Done:

0%

Estimated time:
Tags:
3G

Description

It seems like (at least) the nano3G have a bug where they cannot handle RTP/IuUP between two hNodeB for some reason. So we'll have to implement some kind of minimal RTP proxy that locally terminates the IuUP protocol but passes the payload throgh. It should use the IuUP library code to be developed in #1936


Related issues

Related to Cellular Network Infrastructure - Feature #2909: Document user plane handling with BSC+MSC co-located OsmoMGW, Osmux, and outlookNew2018-02-06

Precedes OsmoMGW - Feature #2459: remove nano3G IuUP "Initialization ACK" hack when IuUP proxy is in placeNew2017-02-062017-02-06

Follows OsmoMGW - Feature #1936: Implementation of IuUP SMpSDU modeIn Progress2017-02-02

History

#1 Updated by neels over 1 year ago

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.

#2 Updated by neels over 1 year ago

  • Related to Feature #1936: Implementation of IuUP SMpSDU mode added

#3 Updated by neels over 1 year ago

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.

#4 Updated by neels about 1 year ago

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.

#5 Updated by laforge 10 months ago

  • Assignee changed from Osmocom Developers to sysmocom

#6 Updated by neels 9 months ago

  • Project changed from OsmoHNBGW to OsmoMGW

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

#7 Updated by laforge 9 months ago

Hi Neels,

On Tue, Sep 19, 2017 at 11:21:45PM +0000, neels [REDMINE] wrote:

Project changed from OsmoHNBGW to OsmoMGW
shouldn't this go to OsmoMGW?

correct, it was probably created at a time when there was no OsmoMGW project in redmine, or it was a mistake.

Maybe assign to dexter?

By now that's a good idea, yes. Wasn't clear yet a the time...

#8 Updated by laforge 9 months ago

  • Subject changed from Implement minimal RTP proxy with IuUP to Implement way how to handle IuUP on RTP endpoints
  • Assignee changed from sysmocom 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.

#9 Updated by laforge 7 months ago

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".

#10 Updated by laforge 7 months ago

  • Precedes Feature #2459: remove nano3G IuUP "Initialization ACK" hack when IuUP proxy is in place added

#11 Updated by laforge 7 months ago

  • Related to deleted (Feature #1936: Implementation of IuUP SMpSDU mode)

#12 Updated by laforge 7 months ago

  • Due date set to 02/03/2017
  • Start date changed from 02/02/2017 to 02/03/2017
  • Follows Feature #1936: Implementation of IuUP SMpSDU mode added

#13 Updated by laforge 6 months ago

  • Assignee changed from dexter to laforge

#14 Updated by laforge 6 months ago

  • Priority changed from Normal to Urgent

#15 Updated by laforge 6 months ago

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.

#16 Updated by laforge 5 months ago

  • Related to Feature #2909: Document user plane handling with BSC+MSC co-located OsmoMGW, Osmux, and outlook added

#17 Updated by laforge 24 days ago

  • Tags set to 3G

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)