Project

General

Profile

Bug #2728

Align better with 48.103 for AoIP user plane

Added by laforge 8 months ago. Updated 7 days ago.

Status:
Stalled
Priority:
Normal
Assignee:
Target version:
-
Start date:
12/09/2017
Due date:
% Done:

90%

Estimated time:
Spec Reference:

Description

In most aspects we seem to do what 48.103 States. However, e.g. our payload types for RTP differ from whats specified there. Also not sure aboiut Details oft MARKER behavior and behavior with regard to lost frames on radio interface.

History

#1 Updated by laforge 7 months ago

  • Description updated (diff)

#2 Updated by dexter about 2 months ago

Note:
I just learned that there are profiles that are just statically defined by the payload type number. And there are dynamics payload types that require an rtpmap in SDP to be fully described.
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml
We also seem to use payload type 255 a lot, however this one seems to be illegal because the dynamic range is from 96 to 127 only.

#3 Updated by laforge about 2 months ago

On Mon, Jun 04, 2018 at 07:55:24PM +0000, dexter [REDMINE] wrote:

I just learned that there are profiles that are just statically defined by the payload type number. And there are dynamics payload types that require an rtpmap in SDP to be fully described.
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml

yes, that's standard RTP operation since the 1990ies. However, the important part for AoIP is that 3GPP
actually defined some "fixed" types in the "dynamic payload type" range.

We also seem to use payload type 255 a lot, however this one seems to be illegal because the dynamic range is from 96 to 127 only.

please open an issue for this, I think this is a quite serious separate bug which should be resolved rather quickly.

#4 Updated by dexter about 1 month ago

yes, that's standard RTP operation since the 1990ies. However, the important part for AoIP is that 3GPP
actually defined some "fixed" types in the "dynamic payload type" range.

Thats new to me. Is this defined in 3GPP TS 48.008?

please open an issue for this, I think this is a quite serious separate bug which should be resolved rather quickly.

In osmo-mgw I have elimiated the problem while cleaing up the SDP parser. In the client I got rid of the hardcoded SDP, so its gone there as well. See also #3334

#5 Updated by laforge about 1 month ago

Hi dexter,

On Mon, Jun 11, 2018 at 07:44:24PM +0000, dexter [REDMINE] wrote:

yes, that's standard RTP operation since the 1990ies. However, the important part for AoIP is that 3GPP
actually defined some "fixed" types in the "dynamic payload type" range.

Thats new to me. Is this defined in 3GPP TS 48.008?

No. Please read the subject f this issue. It states exactly which 3GPP TS we have to match ;)

Specifically, I was referring to
"Table 5.4.2.2.1: Type of data transported versus RTP Payload Type" when
creating this issue. It lists 110 for EFR, 111 for HR, 112 for AMR

#6 Updated by dexter about 1 month ago

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

The latest updates to osmo-mgw, which are currently in review also cover this topic. Both libosmo-mgcp and libosmo-mgcp-client now use the 3gpp/IANA defined payload types. So from the payload type perspective we should be good now.

See also:
https://gerrit.osmocom.org/#/c/osmo-mgw/+/9649/
https://gerrit.osmocom.org/#/c/osmo-mgw/+/9648/

What still remains is the MARKER behaviour / lost frames on radio topic.

#7 Updated by dexter 27 days ago

  • % Done changed from 50 to 60

As expected many of the BSC tests now fail because osmo-bsc does not set the codec information yet. I have now modifed gscon that it sets basic codec information. This should make the tests pass again.

See also:
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9738/

The TTCN3 tests still use wrong/hardoced codec information. This is now also fixed.

See also:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9737/

#8 Updated by laforge 27 days ago

On Mon, Jun 25, 2018 at 07:41:19PM +0000, dexter [REDMINE] wrote:

https://gerrit.osmocom.org/#/c/osmo-bsc/+/9738/
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9737/

both patches now merged.

#9 Updated by dexter 24 days ago

Note: I think we now should have a look at the RTP-Streams as well since there are still problmatic payload types inside the streams. (on a trace with AMR-HR/AMR-FR the streams are tagged with 98, which is wrong)

#10 Updated by dexter 24 days ago

  • % Done changed from 60 to 80

I have now changed the constants which are used for RTP streams in various places. I have changed those constants now so that they match the 3GPP recommendations:

https://gerrit.osmocom.org/#/c/libosmo-abis/+/9779 ortp: use 3GPP assigned payload type numbers
https://gerrit.osmocom.org/#/c/libosmo-netif/+/9780 rtp: use 3GPP assigned payload type numbers
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9781 rsl: use 3GPP assigned payload type numbers
https://gerrit.osmocom.org/#/c/openbsc/+/9782 rtp_proxy: use 3GPP assigned payload type numbers

#11 Updated by dexter 14 days ago

There was the suggestion not only to change the various constants but also to limit the number of redundant definitions. When we put openbsc aside we still have 3 places where the payload type constants for the RTP-Streams are defined. (Note: We now focusing on the payload type tags used in the RTP packets, not on the ones in the MGCP messages.)

I have abandoned the changes I made in openbsc (osmo-nitb). I thought it would be better to use the 3gpp assigned payload types there as well, but its also true that we do not have any benefit from this while we introduce a regression risk.

In libosmo-netif I kept it the way it is as we do not want to introduce any dependencies here. So I did not do any further changes here.

In osmo-bsc I removed the constants completely and used the ones already present in libosmo-abis. This works fine. However, we need to make sure that we do not introduce a regression with nanoBTS. (I am also not sure about the nanoBTS support in osmo-bsc, the tests I did some months ago were not very promising but I also do not receive any complaints from the tester)

For now I tagged the change in osmo-bsc as WIP until I managed to do a test using the nanobts.

While working on the RTP stream payload types we also realized that osmo-mgw can not do payload type translation yet. See also #3384 If we resolve this, we may also very well stick to the non-3gpp payload types on the BSS/BTS side, however I would recommend to use the 3gpp assigned payload types there as well if there are no problems with nanoBTS.

#12 Updated by dexter 7 days ago

  • Status changed from In Progress to Stalled
  • % Done changed from 80 to 90

I think we are very close to complete here. The final bits (Payload type numbers inside the RTP stream) require a discussion.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)