Half sided calls

Max msuraev at sysmocom.de
Fri Apr 29 14:21:03 UTC 2016

Thanks for your feedback. It should be fixed in libosmo-abis now. Let me
know if it still doesn't work for you.

On 04/28/2016 03:50 PM, Pavel Balashov wrote:
> 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.

This one is not covered by the fix above so you'll occasionally will see
icmp reports for rtcp messages. Feel free to open separate ticket at
http://projects.osmocom.org/issues if you think this got to be fixed as

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

Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte 

More information about the OpenBSC mailing list