Bug #3807
closed
short HRv1 RTP payload on PHY based BTS implementations
Added by dexter about 5 years ago.
Updated about 5 years ago.
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
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.
- Subject changed from short rtp payload on phy based BTS implementations to short HRv1 RTP payload on PHY based BTS implementations
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.
- 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
- % 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.
- 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.
- Related to Bug #4002: AMR defaults to bandwidth-efficient mode added
Also available in: Atom
PDF