https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-03-17T09:46:45ZOpen Source Mobile CommunicationsOsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=11142016-03-17T09:46:45Zlaforge
<ul><li><strong>Assignee</strong> set to <i>msuraev</i></li></ul> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=11772016-03-18T16:55:08Zmsuraev
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>On which GNU/Linux distribution this was observed?</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=11822016-03-22T18:44:03Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=12992016-04-29T13:57:11Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>laforge</i></li></ul><p>Should be fixed by 8c119f7a0510b75e7fa1b96a37f2a6650e13824f in libosmo-abis.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=13162016-05-04T14:13:49Zlaforge
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Closed</i></li></ul><p>let's close the issue and re-open only in case users report it as still broken.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=13712016-05-09T19:34:18Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/20">Bug #20</a>: phone calls between AMR-capable handset and EFR-only handset</i> added</li></ul> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=13752016-05-09T19:35:15Zlaforge
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/20">Bug #20</a>: phone calls between AMR-capable handset and EFR-only handset</i>)</li></ul> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=19652016-07-31T10:26:48Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/1785">Bug #1785</a>: RTP network error</i> added</li></ul> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21352016-09-13T16:40:32Zmsuraev
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>New</i></li></ul><p>Notice: the error was re-introduced in c77c2a6aa13accbc558888ab788d1148eb9aeb1a.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21362016-09-13T23:10:45Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>msuraev</i></li></ul><p>AFAICT c77c2a6aa13accbc558888ab788d1148eb9aeb1a is quite clearly a<br />fix of erratic use of libortp (at least version 0.25).</p>
<p>The commit being reverted, 8c119f7a0510b75e7fa1b96a37f2a6650e13824f, says:</p>
<pre>
Set connected mode after setting remote address
ortp: according to oRTP documentation rtp_session_set_connected_mode()
uses the address set by rtp_session_set_remote_addr() - move the
function call accordingly.
Fixes: OS#1661
</pre>
<p>Looking at the ortp code, that is definitely not the case. <br />rtp_session_set_connected_mode() simply sets a flag which is used in<br />rtp_session_set_remote_addr().</p>
<pre>
void rtp_session_set_connected_mode(RtpSession *session, bool_t yesno){
session->use_connect=yesno;
}
</pre>
<pre>
static int
_rtp_session_set_remote_addr_full ([...]) { [called by rtp_session_set_remote_addr()]
[...]
if (can_connect(session)){
if (try_connect(session->rtp.gs.socket,(struct sockaddr*)&session->rtp.gs.rem_addr,session->rtp.gs.rem_addrlen))
session->flags|=RTP_SOCKET_CONNECTED;
[...]
}
</pre>
<pre>
#define can_connect(s) ( (s)->use_connect && !(s)->symmetric_rtp)
</pre>
<p>I wonder how introducing this bug could fix this issue, and how fixing the bug <br />could again introduce the problem observed in OS#1661. It seems to be some<br />unintended side effect.</p>
<p>Can you clarify?</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21512016-09-19T11:37:59Zmsuraev
<ul></ul><p>According to API docs - see <a class="external" href="http://download-mirror.savannah.gnu.org/releases/linphone/ortp/docs/rtpsession_8h.html#a84cdf75e48fea6e42b67da998e67fbda">http://download-mirror.savannah.gnu.org/releases/linphone/ortp/docs/rtpsession_8h.html#a84cdf75e48fea6e42b67da998e67fbda</a> for instance:</p>
<p>"If yesno is TRUE, thus a connect() syscall is done on the socket to the destination address set by rtp_session_set_remote_addr()" which I interpret as "rtp_session_set_remote_addr() have to be called before rtp_session_set_connected_mode()".</p>
<p>The tests so far have showed that this is indeed the right order for later ortp versions. I'm not sure yet how to please both old and new - or if it's worth the efforts at all: we can just fix on latest stable version ortp (0.22.0 in Debian stable for example).</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21522016-09-19T11:53:16Zmsuraev
<ul></ul><p>At the same time examples supplied with ortp do the opposite - see src/tests/rtpsend.c:81<br />It's really hard to work with the library when library's documentation contradict library's examples.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21562016-09-24T13:15:14Zlaforge
<ul></ul><p>On Mon, Sep 19, 2016 at 11:53:16AM +0000, msuraev [REDMINE] wrote:</p>
<blockquote>
<p>At the same time examples supplied with ortp do the opposite - see src/tests/rtpsend.c:81<br />It's really hard to work with the library when library's documentation contradict library's examples.</p>
</blockquote>
<p>It might be worth raising this at the apropriate mailing list or issue<br />tracker and ask for guidance.</p>
<p>-- <br />- Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a class="external" href="http://laforge.gnumonks.org/">http://laforge.gnumonks.org/</a>
============================================================================<br />"Privacy in residential applications is a desirable marketing option." <br />(ETSI EN 300 175-7 Ch. A6)</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21572016-09-24T13:19:37Zmsuraev
<ul></ul><p>Already did - no response so far. From previous experience it could be weeks before upstream devs react if at all.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21702016-10-06T13:41:09Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I have analysed a bit further. The starting point was that I switched to using the<br />SysmoBTS SDK version 1.5.4, which includes a newer libortp version, and with that<br />voice was broken (only background noise).</p>
<p>Then Max said:</p>
<blockquote>
<p>This might be related to commit c77c2a6aa13accbc558888ab788d1148eb9aeb1a<br />in <del>osmobts</del> [libosmo-abis]</p>
</blockquote>
<blockquote>
<p>If you roll-back this commit, does voice re-appear?</p>
</blockquote>
<p>Wow, it actually does! But when looking at the ortp code as described in detail<br />in OS#1661, this makes no sense at all. It <strong>should</strong> not fix anything.<br />I tried to understand the ortp code:</p>
<p>rtp_session_set_connected_mode() simply sets a flag (use_connect=1) which is<br />used in rtp_session_set_remote_addr(). Setting the flag only later amounts to<br />setting a different flag value (use_connect=0) for the first connection. The<br />main difference: with use_connect=1, rtp_session_set_remote_addr() establishes<br />a connect() already and sets the "is connected" flag, and with use_connect=0<br />it seems only the socket is opened.</p>
<p>But the use_connect flag is also queried during rtp_process_incoming_packet().<br />This calls rtp_session_update_remote_sock_addr(), to update the address to the<br />remote counterpart, and will connect only if the "is connected" flag is not set yet.</p>
<p>So I suspect this:</p>
<p>When use_connect 1, rtp_session_set_remote_addr() connects and sets the<br />connection flag. Then the rtp_session_update_remote_sock_addr() wants to update<br />to the real remote counterpart, but this has no effect, since the flag that<br />we're connected is already set, and the code does not reconnect the socket.<br />We still have a connect() to the initial wrong remote address.</p>
<p>When use_connect 0, rtp_session_set_remote_addr() does <strong>not</strong> connect(), and<br />the rtp_session_update_remote_sock_addr() has an effect, since the connection<br />is established only in rtp_process_incoming_packet(). So by setting the<br />use_connect only after rtp_session_set_remote_addr(), the first incoming<br />packet does the connect() when it knows the proper remote address.</p>
<p>This is confirmed by a hack: with use_connect == 1 at the top, voice is broken;<br />if I then set the internal ortp flags to not-connected, voice works: the code<br />reconnects with the updated address upon receiving a packet.</p>
<pre>
--- a/src/trau/osmo_ortp.c
+++ b/src/trau/osmo_ortp.c
@@ -401,6 +401,9 @@ int osmo_rtp_socket_connect(struct osmo_rtp_socket *rs, const char *ip, uint16_t
if (rc < 0)
return rc;
+ rs->sess->flags &= ~(1<<8); // RTP_SOCKET_CONNECTED=1<<8
+ rs->sess->flags &= ~(1<<9); // RTCP_SOCKET_CONNECTED=1<<9
+
if (rs->flags & OSMO_RTP_F_POLL)
return rc;
else
</pre>
<p>What appears ugly at this point:</p>
<p>- each rtp_process_incoming_packet() call unconditionally does<br /> rtp_session_update_remote_sock_addr(), but it appears to have an effect only<br /> the first time it is called.</p>
<p>- rtp_process_incoming_packet() should probably update the address on the first<br /> time only.</p>
<p>- rtp_process_incoming_packet() should detect whether an address change is<br /> needed and disconnect the socket (so that it is reconnected in the code<br /> below).</p>
<p>Hence it would be possible to set the use_connect flag a priori and the other<br />code would automagically know whether a reconnect is necessary.</p>
<p>But in summary, setting the use_connect flag "too late" actually fixes voice<br />for newer libortp.</p>
<p>The rtp_process_incoming_packet() was introduced after libortp 0.16.5 which<br />might explain why setting use_connect = 1 at the top doesn't break voice for<br />libortp 0.16.5.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21722016-10-06T17:15:12Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Todo: check whether litecell15 also works with a recent ortp-0.25 with <a class="external" href="https://gerrit.osmocom.org/1011">https://gerrit.osmocom.org/1011</a> applied.<br />(The instructions were to use 0.16.5)</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21762016-10-09T22:27:44Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>To illustrate the landscape a bit further ...</p>
<ul>
<li>libortp versions:
<ul>
<li>The SDK for Litecell 1.5 recommends using libortp v0.16.5.</li>
<li>Recent libosmo-abis has moved to requiring a minimum of libortp v0.22.0</li>
</ul></li>
</ul>
<ul>
<li><a href="https://git.osmocom.org/libosmo-abis/commit/?id=c77c2a6aa13accbc558888ab788d1148eb9aeb1a" class="external">c77c2a6aa13accbc</a> is a patch originally suggested by the Litecell 1.5 SDK.<br /> It looked like a fix at first to me, so I readily applied it, but now the<br /> situation turns out to be far more complex.</li>
</ul>
<ul>
<li>sysmoBTS SDK versions:
<ul>
<li>The sysmoBTS SDK <strong>v1.5.3</strong> works fine with c77c2a6aa13accbc, presumably<br /> because it still includes an older libortp.</li>
<li>The sysmoBTS SDK <strong>v1.5.4</strong> produces no voice when c77c2a6aa13accbc is applied,<br /> presumably because it includes a more recent libortp version.</li>
</ul></li>
</ul>
<p>It seems "recent" libortp internals around the set_connected_mode flag have<br />either introduced a regression, or alternatively a (seemingly bad) design<br />choice forces us to take more care when setting that flag.</p>
<p>We should clarify these:</p>
<ul>
<li>Why does c77c2a6aa13accbc matter when changing to a recent libortp? Is that <br /> situation intended by libortp upstream or actually a regression?</li>
</ul>
<ul>
<li>Why exactly does Litecell 1.5 need libortp 0.16.5?
<ul>
<li>Can we accept Litecell 1.5 to stick to a libortp version that current<br /> libosmo-abis master clearly rejects as too old?</li>
<li>What would it take to pull Litecell 1.5 up to a recent libortp?</li>
</ul></li>
</ul>
<ul>
<li>Furthermore, why does Litecell 1.5 need c77c2a6aa13accbc <strong>on top</strong> of an old<br /> libortp 0.16.5? (Asking because for sysmoBTS it seems that an older libortp<br /> makes c77c2a6aa13accbc not matter much.)</li>
</ul> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21772016-10-10T08:12:25Zmsuraev
<ul></ul><p>The latest litecell sdk has oRTP version 0.22.0 which I've tested recently and it works fine. They promised that documentation update will follow but it has not materialized yet. Hence we can focus on testing with oRTP 0.22.0+ ignoring older versions which are not supported by upstream anyway. See for SYS#2569 details.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=21862016-10-11T08:54:26Zlaforge
<ul></ul><p>On Sun, Oct 09, 2016 at 10:27:44PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<ul>
<li>Furthermore, why does Litecell 1.5 need c77c2a6aa13accbc <strong>on top</strong> of an old<br />libortp 0.16.5? (Asking because for sysmoBTS it seems that an older libortp<br />makes c77c2a6aa13accbc not matter much.)</li>
</ul>
</blockquote>
<p>As all this is related to RTP audio socket binding/connecting behavior,<br />it might very well be that the test environment for the two BTS models<br />is different, too. sysmoBTS is normally tested against OsmoNITB, which<br />I believe is not the case for LC1.5.</p>
<p>So when making stateents like "commit xxxx breaks LC15", I think it is<br />very important to describe the test environment for this.</p>
<p>A different BSC implementation than our libbsc might very well be using<br />different parameters and timing for the RSL IPA CRCX/MDCX messages that<br />affect RTP sockets.</p>
<p>-- <br />- Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a class="external" href="http://laforge.gnumonks.org/">http://laforge.gnumonks.org/</a>
============================================================================<br />"Privacy in residential applications is a desirable marketing option." <br />(ETSI EN 300 175-7 Ch. A6)</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=22182016-10-11T13:53:09Zmsuraev
<ul></ul><p>As original bug refers to osmo-bts-octphy, it got to be tested as well.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=22202016-10-11T15:32:02Zdexter
<ul></ul><p>Checked it with libortp 0.25.0 on OCTBTS3500 with most recent firmware (02.07.00-B1039) and it works fine. However, the recent libortp (0.27.0 and above) there will be problems because of API changes.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=22212016-10-11T15:38:28Zmsuraev
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>laforge</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>As it works for osmo-bts-octphy again I suggest to close this and move further lc15-specific discussion to linked <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: RTP network error (Closed)" href="https://osmocom.org/issues/1785">#1785</a>.</p> OsmoNITB - Bug #1661: voice not audible in TCH/F-TCH/F calls using osmo-bts-octphy and ortp-0.25https://osmocom.org/issues/1661?journal_id=23012016-10-27T08:58:07Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>