Project

General

Profile

Actions

Feature #1937

closed

Implement way how to handle IuUP on RTP endpoints

Added by laforge about 7 years ago. Updated about 2 years ago.

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

100%

Spec Reference:
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 - Bug #3411: 3G voice broken, CS RAB Assignment is not workingResolvedneels07/23/2018

Actions
Related to OsmoMGW - Feature #5468: osmo-mgw: 2g<->3g call supportNew02/28/2022

Actions
Precedes OsmoMGW - Feature #2459: remove nano3G IuUP "Initialization ACK" hack when IuUP proxy is in placeResolvedpespin02/06/201702/06/2017

Actions
Follows OsmoMGW - Feature #1936: Implementation of IuUP SMpSDU modeResolvedpespin02/02/2017

Actions
Actions #1

Updated by neels about 7 years 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.

Actions #2

Updated by neels about 7 years ago

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

Updated by neels about 7 years 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.

Actions #4

Updated by neels almost 7 years 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.

Actions #5

Updated by laforge over 6 years ago

  • Assignee changed from 118 to 4368
Actions #6

Updated by neels over 6 years ago

  • Project changed from OsmoHNBGW to OsmoMGW

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

Actions #7

Updated by laforge over 6 years 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...

Actions #8

Updated by laforge over 6 years ago

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

Actions #9

Updated by laforge over 6 years 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".

Actions #10

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years 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
Actions #13

Updated by laforge about 6 years ago

  • Assignee changed from dexter to laforge
Actions #14

Updated by laforge about 6 years ago

  • Priority changed from Normal to Urgent
Actions #15

Updated by laforge about 6 years 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.

Actions #17

Updated by laforge almost 6 years ago

  • Tags set to 3G
Actions #18

Updated by neels over 5 years ago

  • Related to Bug #3411: 3G voice broken, CS RAB Assignment is not working added
Actions #19

Updated by laforge over 5 years ago

  • Priority changed from Urgent to Normal
Actions #20

Updated by laforge about 2 years ago

Just to get this noted somewhere, in case we later need it:

3GPP TS 23.153 Section 5.4 covers the UP Framing Protocol handling for TrFO. From it we can see that the MGW might need to perform RFCI value correction .

Actions #21

Updated by laforge about 2 years ago

  • Assignee changed from laforge to pespin
Actions #22

Updated by pespin about 2 years ago

Work being done on this. See https://osmocom.org/issues/1936#note-18

Actions #23

Updated by pespin about 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 90
Actions #24

Updated by pespin about 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

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.

Actions #25

Updated by pespin about 2 years ago

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)