https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-01-10T23:40:19ZOpen Source Mobile CommunicationsOsmoMGW - Bug #2825: osmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)https://osmocom.org/issues/2825?journal_id=70952018-01-10T23:40:19Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>just now I noticed that I was stupid and NATing everything going out on eth0, but after resolving that, I still get the above situation for RTCP.<br />It seems that osmo-bts on the sysmoBTS simply uses a random port to send out RTCP, and the MGW expects RTP + 1 instead?</p> OsmoMGW - Bug #2825: osmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)https://osmocom.org/issues/2825?journal_id=70962018-01-11T00:01:32Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>found that the RTP and RTCP socket ports are set by libortp's<br /><pre>
*@param rtp_port: a local port or -1 to let oRTP choose the port randomly
*@param rtcp_port: a local port or -1 to let oRTP choose the port randomly
rtp_session_set_local_addr (RtpSession * session, const char * addr, int rtp_port, int rtcp_port)
</pre></p>
<p>We use it in libosmo-abis/src/trau/osmo_ortp.c:<br /><pre>
int osmo_rtp_socket_bind(struct osmo_rtp_socket *rs, const char *ip, int port)
{
int rc, rtcp = (-1 != port) ? port + 1 : -1;
rc = rtp_session_set_local_addr(rs->sess, ip, port, rtcp);
</pre></p>
<p>and in osmo-bts/common/rsl.c, we indeed call with -1 as port:</p>
<pre>
rc = osmo_rtp_socket_bind(lchan->abis_ip.rtp_socket,
ipstr, -1);
</pre>
<p>So either we need to pass both RTP and RTCP port numbers to libortp explicitly, or we need to refrain from enforcing the RTCP = RTP + 1 source port number in osmo-mgw.<br />Setting explicit port numbers is tricky and would involve checking whether we have two consecutive port numbers that are unused in osmo-bts.</p>
<p>Easiest way out to allow RTCP to pass through osmo-mgw is to make the RTCP = RTP + 1 rule an optional configuration (and switch off by default?).<br />I guess we could still learn the RTCP port from the first RTCP packet received. Validating the source IP address is still possible and desired.</p> OsmoMGW - Bug #2825: osmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)https://osmocom.org/issues/2825?journal_id=71152018-01-11T15:48:54Zlaforge
<ul></ul><p>On Thu, Jan 11, 2018 at 12:01:32AM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>We use it in libosmo-abis/src/trau/osmo_ortp.c:<br /><pre>
> int osmo_rtp_socket_bind(struct osmo_rtp_socket *rs, const char *ip, int port)
> {
> int rc, rtcp = (-1 != port) ? port + 1 : -1;
> rc = rtp_session_set_local_addr(rs->sess, ip, port, rtcp);
> </pre></p>
<p>and in osmo-bts/common/rsl.c, we indeed call with -1 as port:<br /><pre>
> rc = osmo_rtp_socket_bind(lchan->abis_ip.rtp_socket,
> ipstr, -1);
> </pre></p>
</blockquote>
<p>One more reason to move osmo-bts over to the osmo_rtp_ code. I think there were some patches<br />or a branch many years ago :/</p>
<blockquote>
<p>So either we need to pass both RTP and RTCP port numbers to libortp explicitly,</p>
</blockquote>
<p>yes.</p>
<blockquote>
<p>or we need to refrain from enforcing the RTCP = RTP + 1 source port number in osmo-mgw.</p>
</blockquote>
<p>clearly not. RTP + RTCP are specified very tightly in that RTCP must be +1 and RTP must be an even port<br />number.</p>
<blockquote>
<p>Setting explicit port numbers is tricky and would involve checking whether we have two consecutive port<br />numbers that are unused in osmo-bts.</p>
</blockquote>
<p>In order to avoid spending tons of syscalls at every channel activation<br />trying to find two even-aligned consecutive port numbers, one could bind<br />them already at BTS startup time and later only re-connect them, but<br />keep them bound at all times?</p>
<p>How does OsmoNITB and/or OsmoMGW deal with this?</p>
<blockquote>
<p>Easiest way out to allow RTCP to pass through osmo-mgw is to make the<br />RTCP = RTP + 1 rule an optional configuration (and switch off by<br />default?).</p>
</blockquote>
<p>No. We will not intentionally break a very clear RFC requirement on how<br />RTP behaves. If we start down that road, we might as well change the<br />RTP header or not use RTP at all.</p>
<blockquote>
<p>I guess we could still learn the RTCP port from the first RTCP packet<br />received. Validating the source IP address is still possible and<br />desired.</p>
</blockquote>
<p>No. We have a bug, let's fix it please.</p> OsmoMGW - Bug #2825: osmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)https://osmocom.org/issues/2825?journal_id=74242018-02-06T01:12:06Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoMGW - Bug #2825: osmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)https://osmocom.org/issues/2825?journal_id=95262018-05-28T08:55:20Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>The root of the problem is that the BTS picks a random port for RTP and another random port for RTCP. This clearly violates the rules given by RFC 3550, chapter 11 (RTP over Network and Transport Protocols).</p>
<p>To fix the problem. OsmoBTS now picks the ports from a configured port range. It also makes sure the RTP port is always an even number and the RTPC port is alwas the following odd number. The actual implementation is similar to the one we find in osmo-mgw.</p>
<p>See also: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/9261/">https://gerrit.osmocom.org/#/c/osmo-bts/+/9261/</a></p>