Project

General

Profile

Actions

Bug #5356

open

libosmo-abis: osmo_rtp_socket_connect() not calling connect() on sockets

Added by pespin about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12/13/2021
Due date:
% Done:

0%

Spec Reference:

Description

osmo_rtp_socket_connect() in libosmo-abis is actually not calling connect() on the socket. Hence, doing the following, won't work:

rs = osmo_rtp_socket_create(ue, OSMO_RTP_F_POLL);
...
rc = osmo_rtp_socket_bind(rs, "0.0.0.0", 16384);
...
rc = osmo_rtp_socket_connect(rs, remote_ipstr, remote_port); // 172.18.33.203:9000
rc = rtp_get_bound_addr(rs, loc_addr); // <---- THIS WILL RETURN loc_addr=0.0.0.0 BECAUSE SOCK IS NOT CONNECTED

Calling in rtp_get_bound_addr() shows:

socket: r=NULL<->l=0.0.0.0:16384

Apparently the issue goes back to #1661 (https://osmocom.org/issues/1661), where this commit [1] was reported to break audio calls.
It was discussed in #161 and following commit was merged [2].

So after [2] being merged, we are nowadays in an scenario where osmo_rtp_socket_connect() doesn't really make libortp call connect() on the socket. With current implementation, connect() is actually called by libortp upon first RTP packet being received.

In libortp, the function calling connect() is rtp_session_set_remote_addr(), based on:

#define can_connect(s)    ( (s)->use_connect && !(s)->symmetric_rtp)
_rtp_session_set_remote_addr_full(...) {
...
        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;

Where s->use_connect is set by the following API:

/**
 *    If yesno is TRUE, thus a connect() syscall is done on the socket to
 *    the destination address set by rtp_session_set_remote_addr(), or
 *    if the session does symmetric rtp (see rtp_session_set_symmetric_rtp())
 *    a the connect() is done to the source address of the first packet received.
 *    Connecting a socket has effect of rejecting all incoming packets that
 *    don't come from the address specified in connect().
 *    It also makes ICMP errors (such as connection refused) available to the
 *    application.
 *    @param session a rtp session
 *    @param yesno a boolean to enable or disable the feature
 *
**/
void rtp_session_set_connected_mode(RtpSession *session, bool_t yesno){
    session->use_connect=yesno;
}

and currently in osmo_rtp_socket_connect(), we do:

    /* We don't want the connected mode enabled during
     * rtp_session_set_remote_addr(), because that will already setup a
     * connection and updating the remote address will no longer have an
     * effect. Contrary to what one may expect, this must be 0 at first,
     * and we're setting to 1 further down to establish a connection once
     * the first RTP packet is received (OS#1661). */
    rtp_session_set_connected_mode(rs->sess, 0);

    rc = rtp_session_set_remote_addr(rs->sess, ip, port);
    if (rc < 0)
        return rc;

    /* enable the use of connect() so later getsockname() will
     * actually return the IP address that was chosen for the local
     * sid of the connection */
    rtp_session_set_connected_mode(rs->sess, 1);

So, as can see above, in a function we call ourselves ..._connect(), we trick libortp to actually avoid connect()ing...

That probably also means a user of osmo_rtp using that API is actually unable to transmit RTP traffic until a first RTP packet is received? In any case, osmo-bts code in rsl_rx_ipac_XXcx() seems to be expecting to retrieve the local addr from the socket as I described in the first code block, by setting "0.0.0.0" and later retrieving whatever was finally bound based on the remote address when connecting(). That path is most probably not working (I had the same issue in osmo-hnodeb), but we probably didn't see it because we are probably receiving in osmo-bts a IPA CRCX with no remote address, and hence rsl_rx_ipac_XXcx() picks the RSL IP address as a dirty hack to set up the socket, so "0.0.0.0" is not received (see [3]).

[1] https://git.osmocom.org/libosmo-abis/commit/?id=c77c2a6aa13accbc558888ab788d1148eb9aeb1a
[2] https://git.osmocom.org/libosmo-abis/commit/?id=a0ff942e927e771875a183c045b3a1676a7d579c
[3] https://git.osmocom.org/osmo-bts/commit/?id=18708dd3b60fa27e6a7121b686f11ee8c8069a4b

No data to display

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)