Project

General

Profile

Bug #2825

osmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)

Added by neels 6 days ago. Updated 5 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
01/10/2018
Due date:
% Done:

0%


Description

My sysmoBTS is sending RTP from port 44286, which go through. However, it appears to send RTCP from port 39839, where the osmo-mgw wants to enforce it to come from port 44287. As a result, it tosses all RTCP packets.

20180110192222187 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:900 endpoint:0x21 receiving RTP/RTCP packet...
20180110192222187 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:802 receiving 140 bytes length packet from 192.168.0.9:39839 ...
20180110192222187 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:907 endpoint:0x21 receiveing from 3 192.168.0.9 39839
20180110192222187 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:912 endpoint:0x21 conn:(3/rtp, id:0x056EDA798F9250F3ECAFDCAE998FB14E, ip:192.168.0.9, rtp:44286 rtcp:44287)
20180110192222187 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:849 endpoint:0x21 data from wrong source port: 39839, expected: 44286 for RTP or 44287 for RTCP
20180110192222188 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:854 endpoint:0x21 packet tossed

20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:1070 endpoint:0x21 source conn:(3/rtp, id:0x056EDA798F9250F3ECAFDCAE998FB14E, ip:192.168.0.9, rtp:44286 rtcp:44287)
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:900 endpoint:0x21 receiving RTP/RTCP packet...
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:802 receiving 29 bytes length packet from 192.168.0.9:44286 ...
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:907 endpoint:0x21 receiveing from 3 192.168.0.9 44286
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:912 endpoint:0x21 conn:(3/rtp, id:0x056EDA798F9250F3ECAFDCAE998FB14E, ip:192.168.0.9, rtp:44286 rtcp:44287)
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:951 endpoint:0x21 destin conn:(3/rtp, id:0xD7655E43E6894076C8AAF7A33263BABE, ip:192.168.0.10, rtp:4002 rtcp:4003)
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:966 endpoint:0x21 endpoint type is MGCP_RTP_DEFAULT, using mgcp_send() to forward data directly
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:673 endpoint:0x21 delivering RTP packet...
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:682 endpoint:0x21 loop:0, mode:3 
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:396 endpoint:0x21 transcoding disabled
20180110192222191 DRTP <0000> ../../../../src/osmo-mgw/src/libosmo-mgcp/mgcp_network.c:725 endpoint:0x21 process/send to 3 192.168.0.10 rtp_port:4002 rtcp_port:4003

What is going on here? Should we not enforce the source port in the first place? Has the RTCP source port become unconfigured for some odd reason?

History

#1 Updated by neels 6 days ago

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.
It seems that osmo-bts on the sysmoBTS simply uses a random port to send out RTCP, and the MGW expects RTP + 1 instead?

#2 Updated by neels 6 days ago

found that the RTP and RTCP socket ports are set by libortp's

 *@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)

We use it in libosmo-abis/src/trau/osmo_ortp.c:

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);

and in osmo-bts/common/rsl.c, we indeed call with -1 as port:

                rc = osmo_rtp_socket_bind(lchan->abis_ip.rtp_socket,
                                          ipstr, -1);

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.
Setting explicit port numbers is tricky and would involve checking whether we have two consecutive port numbers that are unused in osmo-bts.

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?).
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.

#3 Updated by laforge 5 days ago

On Thu, Jan 11, 2018 at 12:01:32AM +0000, neels [REDMINE] wrote:

We use it in libosmo-abis/src/trau/osmo_ortp.c:

> 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);
> 

and in osmo-bts/common/rsl.c, we indeed call with -1 as port:

>                 rc = osmo_rtp_socket_bind(lchan->abis_ip.rtp_socket,
>                                           ipstr, -1);
> 

One more reason to move osmo-bts over to the osmo_rtp_ code. I think there were some patches
or a branch many years ago :/

So either we need to pass both RTP and RTCP port numbers to libortp explicitly,

yes.

or we need to refrain from enforcing the RTCP = RTP + 1 source port number in osmo-mgw.

clearly not. RTP + RTCP are specified very tightly in that RTCP must be +1 and RTP must be an even port
number.

Setting explicit port numbers is tricky and would involve checking whether we have two consecutive port
numbers that are unused in osmo-bts.

In order to avoid spending tons of syscalls at every channel activation
trying to find two even-aligned consecutive port numbers, one could bind
them already at BTS startup time and later only re-connect them, but
keep them bound at all times?

How does OsmoNITB and/or OsmoMGW deal with this?

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?).

No. We will not intentionally break a very clear RFC requirement on how
RTP behaves. If we start down that road, we might as well change the
RTP header or not use RTP at all.

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.

No. We have a bug, let's fix it please.

Also available in: Atom PDF