Half sided calls

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Pavel Balashov psb1979 at hotmail.com
Thu Apr 28 13:50:01 UTC 2016


Hello,

Sorry for having kept silent for so long.
I see how rtcp is not that important for this use-case - even if it fails. But this causes "osmo-ortp(): network_error" error messages which are confusing the user. Just my opinion.

My statement about broken LibORTP was somewhat futile. Just a guess. I see that an 0.23.0 implementation of rtp_session_set_local_addr uses     create_and_bind(addr,rtcp_port,&sockfamily,session->reuseaddr) if (rtp_port>0) and create_and_bind_random(addr,&sockfamily,&rtcp_port) elsewise. Whereas an 0.24.0+ implementation of rtp_session_set_local_addr differs significantly. Looks like there was an attempt to merge (?), maybe this functionality got lost in transition ?

I am calling from cell phone to SIP phone via LCR+FreeSWITCH. The audio is heard on mobile but not on SIP phone.


Regards,
Pavel.




On 04/27/2016 08:18 PM, Max wrote:

Thanks for looking into this. Some comments are inline.

On 04/22/2016 01:40 PM, Pavel Balashov wrote:


Hello!
I can confirm a compatiblity issue with LibORTP >= 0.24.0.

Here are some of my findings:

In /osmo-bts/src/common/rsl.c in /rsl_rx_ipac_XXcx/ there is a call to
libosmo-abis function:/osmo_rtp_socket_bind(lchan->abis_ip.rtp_socket,
ipstr, -1)./ I assume, that last argument "-1" means that the random
udp port should be selected for socket.

in /libosmo-abis/src/trau/osmo-rtp.c in a function /int
osmo_rtp_socket_bind(struct osmo_rtp_socket *rs, const char *ip, int
port)/ there is a call to LibORTP
/rtp_session_set_local_addr(rs->sess, ip, port, port+1)/. So as result
this function calls rtp_session_set_local_addr with last arguments
being equal to "-1" and "0".
/
/The LibORTP function///int rtp_session_set_local_addr (RtpSession *
session, const char * addr, int rtp_port, int rtcp_port)/ has a
folollowing description:/
/**
 *rtp_session_set_local_addr:
 *@session:        a rtp session freshly created.
 *@addr:        a local IP address in the xxx.xxx.xxx.xxx form.
 *@rtp_port:        a local port or -1 to let oRTP choose the port
randomly
 *@rtcp_port:        a local port or -1 to let oRTP choose the port
randomly
 *
  ...
**/

/So this results in calling////osmo_rtp_socket_bind/(...,-1) //->
///rtp_session_set_local_addr(...,-1,0) //what tries to bind rtp to
random udp port and rtcp to 0th udp port, but not to random port./
/I guess that rtcp socket is never created regardless of LibORTP
version. (there are periodic osmo-ortp(): network_error osmo-bts log
messages due to ICMP port unreachable messages received, besides those
mentioned in https://osmocom.org/issues/1662). So I suppose the
correct code should check port value and either calling
/rtp_session_set_local_addr(rs->sess, ip, port, port+1) /if port >0 or
else
calling /rtp_session_set_local_addr(rs->sess, ip, port, port) /?
/
/



Your're right. I've fixed that in max/ortp branch. Not yet in master
because there seems to be more issues in play - I'm still unable to hear
audio with ortp 0.25. The RTCP is not that important for our use-case -
even if it fails (as indicated by ICMP messages) it should not affect
actual voice in RTP streams. Anyway, I'll keep digging :)



//Also, after inspecting  sources of LibORTP it seems that the
implementation//of /rtp_session_set_local_addr/ has changed for
LibORTP >= 0.24.0/./ As I understand the functionality of selecting a
random UDP port is broken.



What makes you think that? I can see random UDP ports selected by oRTP
just fine in my test setup. Do you see it in pcap trace?



What results is one way audio.



Could you please share some more details on your test setup? Are you
calling between 2 phones connected to the same BTS? Or using echo test?
That 1-way audio you hear - which way does it come from?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160428/27d55c58/attachment.htm>


More information about the OpenBSC mailing list