Bug #5356


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

Added by pespin about 2 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


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, "", 16384);
rc = osmo_rtp_socket_connect(rs, remote_ipstr, remote_port); //
rc = rtp_get_bound_addr(rs, loc_addr); // <---- THIS WILL RETURN loc_addr= BECAUSE SOCK IS NOT CONNECTED

Calling in rtp_get_bound_addr() shows:

socket: r=NULL<->l=

Apparently the issue goes back to #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->,(struct sockaddr*)&session->,session->

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

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 "" 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 "" is not received (see [3]).


No data to display


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)