Project

General

Profile

Actions

Bug #3807

closed

short HRv1 RTP payload on PHY based BTS implementations

Added by dexter about 5 years ago. Updated about 5 years ago.

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

100%

Spec Reference:

Description

The RTP payload that is emitted by phy based BTSs (verified with osmo-bts-oc2g and osmo-bts-sysmo) seems to be one byte shorter (14/70 instead of 15/71 bytes) than the payload that osmo-bts-trx emits. Attached one finds two traces, one from osmo-bts-trx and one from osmo-bts-oc2g.

3GPP TS 26.103 Table 7.1.1 references IETF RFC 5993 as specification for the GSM-HR RTP audio ("Useful if an A-interface over IP is attached. or TFO is used") In 5993 one can find in chapter 5.2. Payload Structure that there is a ToC (table of contents) byte specified that is to be attached in front of the actual payload.

The problem is known since the end of 2015 since there is a branch sylvain/32c3_codec in openbsc.git that suggests a fix. According to the proposed fix there is also some mangling of the payload involved as well.


Files


Checklist

  • implement conversion function in osmo-mgw
  • add ttcn-3 test for conversion function in osmo-mgw
  • implement conversion function in osmo-bts, with VTY command to enable/disable

Related issues

Related to OsmoBSC - Bug #4002: AMR defaults to bandwidth-efficient modeResolvedlaforge05/15/2019

Actions
Actions #1

Updated by dexter about 5 years ago

It seems desirable to add a conversion function into osmo-mgw in order to convert the payload to make it appear RFC 5993 compliant to the core network. This would prevent the need for field upgrading multiple BTSs.

A simple check could detect the payload format and convert it into the corresponding complementary form. An implementation could just check all incoming packets and convert them. Since the BTS will only emit short packets, the end pointing to the core network would only get long packets. The core network would send only long packets, which would be converted into short packets that are then sent to the BTS. It would be not necessary for the MGW to explicitly know which connection points to the BTS and which connection points to the core network.

Actions #2

Updated by laforge about 5 years ago

  • Subject changed from short rtp payload on phy based BTS implementations to short HRv1 RTP payload on PHY based BTS implementations
Actions #3

Updated by laforge about 5 years ago

  • Checklist item implement conversion function in osmo-mgw added
  • Checklist item add ttcn-3 test for conversion function in osmo-mgw added
  • Checklist item implement conversion function in osmo-bts, with VTY command to enable/disable added

The existing HRv1 RTP payload format of osmo-bts-{sysmo,oc2g,lc15} is following "ETSI TS 101318 Chapter 5.2", while the AoIP is following RFC5993.

First priority is to implement a converter in osmo-mgw (and an associated set of test cases in MGCP_Tests.ttcn).

Second priority is to make the HRv1 RTP payload format configurable on the BTS side, by adding a conversion function and associated VTY command where the user can choose between "(ts101318|rfc5993)". This VTY command should then be installed on all affected BTS models.

Actions #4

Updated by josef304 about 5 years ago

Actions #5

Updated by dexter about 5 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 60

I have added an optional conversion function to osmo-mgw now but I think this is not the final approach yet since the hr_jumble() function is still next to the conversion function. Since we want to re-use this in osmo-bts, this function should be moved to libosmocore (maybe somewhere in libosmocore/src/coding)

The conversion works, I have tested it locally and in the real world. The problem RTP packets are now converted and HR voice works fine now.

See also: https://gerrit.osmocom.org/#/c/osmo-mgw/+/12979 Add option to GSM HR frames to RFC5593 representation

Actions #6

Updated by dexter about 5 years ago

Unfortunately there is no VTY support for the MGCP_Tests yet. The VTY is needed to switch on the conversion function as we don't want to have it in place for the other tests. I have added VTY support now:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12981 MGCP_Test: Add VTY access
https://gerrit.osmocom.org/#/c/docker-playground/+/12982 ttcn3-mgw_test: Configure VTY interface

Actions #7

Updated by dexter about 5 years ago

  • % Done changed from 60 to 90

The patches are merged, so technically the feature is now available and as far as osmo-mgw is concerned (we still have to add the conversion on osmo-bts) the problem is solved. However, there is a similar problem with AMR and there was the question if it is possible to avoid the blind change from one format to another (see: https://gerrit.osmocom.org/#/c/osmo-mgw/+/13082/) We should check on this, maybe we can apply the solution we find for AMR here as well.

Actions #8

Updated by dexter about 5 years ago

  • Checklist item implement conversion function in osmo-mgw set to Done
  • Checklist item add ttcn-3 test for conversion function in osmo-mgw set to Done
Actions #9

Updated by dexter about 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

All related patches are merged. I think we can see this as resolved.

Actions #10

Updated by laforge almost 5 years ago

  • Related to Bug #4002: AMR defaults to bandwidth-efficient mode added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)