https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-12-10T15:37:00ZOpen Source Mobile CommunicationsCellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=66332017-12-10T15:37:00Zlaforge
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/6633/diff?detail_id=10340">diff</a>)</li></ul> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=97452018-06-04T19:55:24Zdexter
<ul></ul><p>Note:<br />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.<br /><a class="external" href="https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml">https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml</a><br />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.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=97502018-06-05T07:30:14Zlaforge
<ul></ul><p>On Mon, Jun 04, 2018 at 07:55:24PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>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.<br /><a class="external" href="https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml">https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml</a></p>
</blockquote>
<p>yes, that's standard RTP operation since the 1990ies. However, the important part for AoIP is that 3GPP<br />actually defined some "fixed" types in the "dynamic payload type" range.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>please open an issue for this, I think this is a quite serious separate bug which should be resolved rather quickly.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=98472018-06-11T19:44:24Zdexter
<ul></ul><blockquote>
<p>yes, that's standard RTP operation since the 1990ies. However, the important part for AoIP is that 3GPP<br />actually defined some "fixed" types in the "dynamic payload type" range.</p>
</blockquote>
<p>Thats new to me. Is this defined in 3GPP TS 48.008?</p>
<blockquote>
<p>please open an issue for this, I think this is a quite serious separate bug which should be resolved rather quickly.</p>
</blockquote>
<p>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 <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: use proper sdp in libosmo-mgcp-client (Resolved)" href="https://osmocom.org/issues/3334">#3334</a></p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=98512018-06-11T20:55:07Zlaforge
<ul></ul><p>Hi dexter,</p>
<p>On Mon, Jun 11, 2018 at 07:44:24PM +0000, dexter [REDMINE] wrote:</p>
<blockquote><blockquote>
<p>yes, that's standard RTP operation since the 1990ies. However, the important part for AoIP is that 3GPP<br />actually defined some "fixed" types in the "dynamic payload type" range.</p>
</blockquote>
<p>Thats new to me. Is this defined in 3GPP TS 48.008?</p>
</blockquote>
<p>No. Please read the subject f this issue. It states exactly which 3GPP TS we have to match ;)</p>
<p>Specifically, I was referring to<br />"Table 5.4.2.2.1: Type of data transported versus RTP Payload Type" when<br />creating this issue. It lists 110 for EFR, 111 for HR, 112 for AMR</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=99412018-06-18T07:26:02Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>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.</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-mgw/+/9649/">https://gerrit.osmocom.org/#/c/osmo-mgw/+/9649/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-mgw/+/9648/">https://gerrit.osmocom.org/#/c/osmo-mgw/+/9648/</a></p>
<p>What still remains is the MARKER behaviour / lost frames on radio topic.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=100692018-06-25T19:41:19Zdexter
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>60</i></li></ul><p>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.</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/9738/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/9738/</a></p>
<p>The TTCN3 tests still use wrong/hardoced codec information. This is now also fixed.</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9737/">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9737/</a></p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=100742018-06-25T20:00:10Zlaforge
<ul></ul><p>On Mon, Jun 25, 2018 at 07:41:19PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/9738/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/9738/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9737/">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9737/</a></p>
</blockquote>
<p>both patches now merged.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=101222018-06-28T16:15:56Zdexter
<ul></ul><p>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)</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=101492018-06-29T09:06:34Zdexter
<ul><li><strong>% Done</strong> changed from <i>60</i> to <i>80</i></li></ul><p>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:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/libosmo-abis/+/9779">https://gerrit.osmocom.org/#/c/libosmo-abis/+/9779</a> ortp: use 3GPP assigned payload type numbers<br /><a class="external" href="https://gerrit.osmocom.org/#/c/libosmo-netif/+/9780">https://gerrit.osmocom.org/#/c/libosmo-netif/+/9780</a> rtp: use 3GPP assigned payload type numbers<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/9781">https://gerrit.osmocom.org/#/c/osmo-bsc/+/9781</a> rsl: use 3GPP assigned payload type numbers<br /><a class="external" href="https://gerrit.osmocom.org/#/c/openbsc/+/9782">https://gerrit.osmocom.org/#/c/openbsc/+/9782</a> rtp_proxy: use 3GPP assigned payload type numbers</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=102642018-07-09T08:17:31Zdexter
<ul></ul><p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>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)</p>
<p>For now I tagged the change in osmo-bsc as WIP until I managed to do a test using the nanobts.</p>
<p>While working on the RTP stream payload types we also realized that osmo-mgw can not do payload type translation yet. See also <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Translate PT before sending RTP packets (different PT numbers, but same codec on two connections) (Resolved)" href="https://osmocom.org/issues/3384">#3384</a> 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.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=103042018-07-16T07:05:06Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>I think we are very close to complete here. The final bits (Payload type numbers inside the RTP stream) require a discussion.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=104852018-07-26T15:14:11Zdexter
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>80</i></li></ul><p>Osmo-bsc now negotiates the payload types that we also use in the RTP packets. So on the BSS side the RTP flow is now coherent to what we have negotiated via MGCP/SDP</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/10173">https://gerrit.osmocom.org/#/c/osmo-bsc/+/10173</a> gscon: use BSS-common payload types on BSS side</p>
<p>(There is also still work to do on osmo-msc, it does not yet set proper payload type in the MGCP/SDP, this has to be fixed as well.)</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=105342018-07-30T10:36:35Zdexter
<ul></ul><p>I have looked through the code of the MSC. We do not care about the codec much yet. I am currently fixing it. For the internal MNCC I think it will simple to fix, but for the external MNCC we will have to be a bit harder since we need to exchange the codecs with the PBX as well.</p>
<p>The patches that fix the BSC side are not through the review yet. I see there are merge conflicts I have to fix.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=105552018-08-01T10:02:37Zdexter
<ul></ul><p>I noticed there were a lot of changes in osmo-bsc, so I have revised my patch to use consistant payload types in RTP packets and MGCP.<br />See also: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/10287">https://gerrit.osmocom.org/#/c/osmo-bsc/+/10287</a></p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=105992018-08-06T12:34:01Zdexter
<ul></ul><p>On the MSC side I now extract the Speech Codec (Choosen) field. Based on the content I can set the codec that has to be negotiated to the MGW on the RAN side. The codec information on the CN side is the same when we run with the internal MNCC. When we run on the external MNCC we must take the codec information from the MNCC data we get via the socket.</p>
<p>Unfortunately there ssems to be problems with the external MNCC interface. I do not understand how it is used to signal dynamic payload types. I contacted holger to get some info about this but I fear we have to upgrade the MNCC interface a bit.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=112452018-09-11T07:56:34Zdexter
<ul></ul><p>Note: Probably also interesting in the context of this ticket and Speech Codec (Choosen): <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bsc does not send the correct S0-S15 bits for AMR in the Assignment Compl Message. (Resolved)" href="https://osmocom.org/issues/3529">#3529</a></p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=117862018-09-30T11:51:02Zlaforge
<ul></ul><p><a class="user active" href="https://osmocom.org/users/15">dexter</a>: What's the status here? Notes about the MNCC interface are not applicable here. What's needed is an analysis/update of which parts of 48.103 we are compliant to, which parts we are not, and which parts we don't know. And then add checkbox items or sub-tasks for those incompatible/dont-know items here. Thanks!</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=118302018-10-01T16:02:17Zdexter
<ul></ul><p>A lot of the compliance was depending on correct signaling on the MGCP side, especially payload types were a problem here. Most of this is now fiexed but we still have a problem is osmo-msc. When we use the external MNCC we do not negotiate the payload type, this leads into violation of 48.103 because we get incorrect payload type numbers in the RTP packets. Apart from that most things look ok. I have gone over the spec and checked some points:</p>
<pre>
4. Transport over TDM:
(Not implemented yet)
5. Transport over IP:
OK: Port numbering
OK: Same ports for Send/Receive
5.4.2: RTP
OK: RTP Header version
OK: No Padding
OK: No Extension
OK: CSRC=0
CHECK: Marker Bit, unknown yet, must check.
OK: Payload type (when codec is correctly negotiated,
there are problems in osmo-msc and MNCC so that we
do not know the right codec and therefore the payload
type will be wrong then. In principle osmo-mgw does
patch the payload types inthe RTP stream so that they
are correct on the egress connection.)
OK: Packetization time (20ms)
OK: RTCP (optional)
5.5 RTP Multiplexing:
(Not Implemented yet)
5.6 Transport of CSData:
(Not omplemented yet)
5.7 Transport during local switching
(We do not release any endpoints while local switching, this looks ok.)
</pre>
<p>I did not check the marker bit yet. The spec says that on AMR the ONSET frame must have the marker bit set and also the voice frame that follows after the ONSET. This still needs to be checked. I also found that we do not have RTP multiplexing, nor do we have CSData, but I think those are not all important anyway.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=120302018-10-05T16:17:42Zlaforge
<ul></ul><p>Ok, so we need to check for the marker bit usage, and then we can close this issue.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=121082018-10-09T09:49:29Zdexter
<ul><li><strong>File</strong> <a href="/attachments/3394">mobile_to_mobile_fr-amr_call_with_osmo-bsc_and_osmo-msc_09102018_filtered.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3394/mobile_to_mobile_fr-amr_call_with_osmo-bsc_and_osmo-msc_09102018_filtered.pcapng">mobile_to_mobile_fr-amr_call_with_osmo-bsc_and_osmo-msc_09102018_filtered.pcapng</a> added</li></ul><p>I now had a look at the marker behaviour. The spec says that the mark bit should be set for every ONSET frame and for the following voice frame. In the trace I can only see a marker once when the RTP stream starts, so I think there is a problem here. This needs to be investigated on osmo-bts. As far as I understood the payload is generated by the phy and used 1:1 in the RTP stream, we just add the RTP header.</p>
<p>Attached one finds a trace that shows the problem. I also did a trace with GSM-FR and the behavior is exactly the same there, so my guess is that we just have the same marker behavior for all codecs and did not program an exception for AMR.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=121102018-10-09T10:20:07Zlaforge
<ul></ul><p>On Tue, Oct 09, 2018 at 09:49:29AM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>I now had a look at the marker behaviour. The spec says that the mark<br />bit should be set for every ONSET frame and for the following voice<br />frame. In the trace I can only see a marker once when the RTP stream<br />starts, so I think there is a problem here.</p>
</blockquote>
<p>Sad :/</p>
<blockquote>
<p>This needs to be investigated on osmo-bts. As far as I understood the<br />payload is generated by the phy and used 1:1 in the RTP stream, we<br />just add the RTP header.</p>
</blockquote>
<p>Yes, and the marker bit is part of the RTP header which we generate.</p>
<p>grep for things like lchan_set_marker() and lchan->rtp_tx_marker in the osmo-bts source<br />code and you should find some code that is supposed to set the marker bits.</p>
<p>The common part above l1sap uses osmo_rtp_send_frame_ext() with lchan->rtp_tx_marker<br />as a flag to state whether or not the marker bit shall be sent in the next RTP frame.<br />Once it has been set once, it is reset to false.</p>
<p>You an see that rtp_tx_marker is set by osmo-bts-sysmo and osmo-bts-lc15<br />in the AMR related use cases...</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=122572018-10-17T09:53:59Zlaforge
<ul></ul><p>it may make sense to shift this over to <a class="user active" href="https://osmocom.org/users/119">msuraev</a> as he had been working on AMR DTX in the past?</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=124232018-10-29T13:43:38Zdexter
<ul><li><strong>Assignee</strong> changed from <i>dexter</i> to <i>msuraev</i></li></ul><p>I think it makes sense when max does it, he probably knows better where to fix it.</p>
<p><a class="user active" href="https://osmocom.org/users/119">msuraev</a> Have a look at update <a class="issue tracker-2 status-5 priority-3 priority-high3 closed" title="Feature: ip.access nanoBTS support (Closed)" href="https://osmocom.org/issues/19">#19</a>. The only thing that is still missing is the slightly different marker behavior when AMR is used.</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=126042018-11-19T09:30:31Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=133202019-02-12T18:29:24Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/3798">Feature #3798</a>: Implement bandwidth-efficient AMR payload as per RFC 4867 Section 4.3</i> added</li></ul> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=142732019-05-08T14:43:10Zlaforge
<ul><li><strong>Subject</strong> changed from <i>Align better with 48.103 for AoIP user plane</i> to <i>Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)</i></li><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>4368</i></li></ul> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=158512019-09-04T09:34:09Zlaforge
<ul><li><strong>Assignee</strong> deleted (<del><i>4368</i></del>)</li></ul> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=179672020-04-06T20:19:34Zdexter
<ul></ul><p>In <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoBTS rxlev/rxqual SUB computation completely broken [AMR DTX] (Resolved)" href="https://osmocom.org/issues/2978">#2978</a> we implement the implement the correct setting of the marker bit for osmo-bts-trx. The marker bit is now set in the first actual voice frame after ONSET (The ONSET frame itself exists only on the radio link, it does not generate an RTP frame)</p> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=186382020-06-08T19:08:11Zlaforge
<ul></ul> Cellular Network Infrastructure - Bug #2728: Align better with 48.103 for AoIP user plane (AMR marker bit for frame following ONSET)https://osmocom.org/issues/2728?journal_id=211812021-02-06T13:52:56Zlaforge
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>this should have been closed 10 motnhs ago, when <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoBTS rxlev/rxqual SUB computation completely broken [AMR DTX] (Resolved)" href="https://osmocom.org/issues/2978">#2978</a> was closed.</p>