Bug #2825
closedosmo-mgw for osmo-bsc receives RTCP from wrong port and tosses all of them (from sysmoBTS)
100%
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?
Updated by neels over 6 years 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?
Updated by neels over 6 years 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.
Updated by laforge over 6 years 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.
Updated by dexter almost 6 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
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).
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.
