19 Sep
2015
19 Sep
'15
4:05 p.m.
Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and
Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The
downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr
x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f
n=1284764 to
transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f
n=1284764 to
transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx=
0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr
x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx=
0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr
x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f
n=1284768 to
transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f
n=1284768 to
transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
19 Sep
19 Sep
8:09 p.m.
Hi Sipos,
On Sat, Sep 19, 2015 at 5:05 PM, Sipos Csaba
<sipos.csaba(a)kvk.uni-obuda.hu> wrote:
I am in the process of creating the Wiki page for
Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
Any reason it's specific to B2x0? Configuration should be 99% common
for all SDR devices and I think it makes more sense to have a single
page for that, like the old network_from_scratch.
I am quite close, both data and calls are working, but
the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half
sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr
x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f
n=1284764 to
transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f
n=1284764 to
transmit.
Log message suggests that downlink doesn't receive a frame from RTP
side and thus transmits a filler frame. So it seems like your downlink
doesn't work rather than uplink.
It's not clear what do you mean that a call is half sided? According
to the logs, downlink frames are not served at both timeslots, so you
should not hear anything on both sides of the call.
I'd suggest checking that your uplink works, e.g. by looking at
osmo-trx logs. If you have the latest one, it should output a warning
if Rx side is saturated, which is the most possible reason for the
issue.
Another possible issue is codec. I have tested only with GSM-FR so
far. If you enable more debugging in osmo-bts, you should be able to
see decoding result at least for gsm-fr codec. I recommend you enable
at least NOTICE level for L1C and see if there are any fail messages
from here:
http://cgit.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/gsm0503_coding.c?h=2…
One more thing - which branch are you testing with? I've been testing
201509-fairwaves-rebase. If you're using something else - I'd be
curious what happens if you try 201509-fairwaves-rebase.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
20 Sep
20 Sep
11:10 a.m.
Dear Alexander,
Any reason it's specific to B2x0?
Not really, now that UmTRX also uses the standard UHD branch, it should be the same. The
only reason is that I have a B200 and a B210 (finally) to test, but I dont have for
example a UmTRX, so I cant validate my method against that piece of hardware.
So it seems like your downlink doesn't work rather
than uplink.
Trust me, its the uplink which is not working. When I used LCR (through MISDN and
chan_lcr) to hook OpenBSC to Asterisk, I was able to hear both the test music and a test
tone, but the echo test was not working. When I left LCR and Asterisk out (just two
mobiles calling each other) I was not able to hear anything. I am using normal Full Rate
calls (no AMR, no EFR, no HR).
Anyway is this the desired way to hook OpenBSC to Asterisk? I know LCR also have a SIP
method to connect to Asterisk, but I never figured that out and have good experience with
the MISDN method.
which branch are you testing with?
For Osmo-BTS I used Fairwaves/master, for Osmo-TRX I used the master branch (the
fiarwaves/master is still not compiling due to the compile time instruction set issue we
identified a few weeks ago). I can try fairwaves/rebase for Osmo-BTS if you want.
I'd suggest checking that your uplink works
I use RX gain 12, the MS TX power is limited to 20dBm and I also have a duplex filter.
With this setup "show lchan" say the uplink is around -47dBm the downlink is
around -67dBm. The TRX log does not indicate any saturation issue (or any other problems
during the call).
Will try and enable the extra logging and try to extract some meaningful information from
that first, after that will try fairwaves/rebase.
Thanks for your help!
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Alexander Chemeris" <alexander.chemeris(a)gmail.com>
Címzett: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Szombat, 2015. Szeptember 19. 20:09:54
Tárgy: Re: Half sided calls
Hi Sipos,
On Sat, Sep 19, 2015 at 5:05 PM, Sipos Csaba
<sipos.csaba(a)kvk.uni-obuda.hu> wrote:
I am in the process of creating the Wiki page for
Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
Any reason it's specific to B2x0? Configuration should be 99% common
for all SDR devices and I think it makes more sense to have a single
page for that, like the old network_from_scratch.
I am quite close, both data and calls are working, but
the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half
sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr
x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f
n=1284764 to
transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f
n=1284764 to
transmit.
Log message suggests that downlink doesn't receive a frame from RTP
side and thus transmits a filler frame. So it seems like your downlink
doesn't work rather than uplink.
It's not clear what do you mean that a call is half sided? According
to the logs, downlink frames are not served at both timeslots, so you
should not hear anything on both sides of the call.
I'd suggest checking that your uplink works, e.g. by looking at
osmo-trx logs. If you have the latest one, it should output a warning
if Rx side is saturated, which is the most possible reason for the
issue.
Another possible issue is codec. I have tested only with GSM-FR so
far. If you enable more debugging in osmo-bts, you should be able to
see decoding result at least for gsm-fr codec. I recommend you enable
at least NOTICE level for L1C and see if there are any fail messages
from here:
http://cgit.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/gsm0503_coding.c?h=2…
One more thing - which branch are you testing with? I've been testing
201509-fairwaves-rebase. If you're using something else - I'd be
curious what happens if you try 201509-fairwaves-rebase.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
11:35 a.m.
Hi Alexander,
Just attached the log with the L1C set to notice level. For this test I did not used
"-m" nor "-P", just pure OpenBSC with two phones calling each other.
I would highlight the following line:
<0014> trau/osmo_ortp.c:132 osmo-ortp(52995): network_error
From the very beggining I get a sense that maybe the
RTP is not working (I got half sided calls on SIP with asterisk previously because of RTP
port issues). I am using ORTP version 0.24.2 maybe it is too new?
One more thing: I am using the master branch of Libosmo-Abis. Can that be a problem?
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu>
Címzett: "Alexander Chemeris" <alexander.chemeris(a)gmail.com>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Vasárnap, 2015. Szeptember 20. 11:10:54
Tárgy: Re: Half sided calls
Dear Alexander,
Any reason it's specific to B2x0?
Not really, now that UmTRX also uses the standard UHD branch, it should be the same. The
only reason is that I have a B200 and a B210 (finally) to test, but I dont have for
example a UmTRX, so I cant validate my method against that piece of hardware.
So it seems like your downlink doesn't work rather
than uplink.
Trust me, its the uplink which is not working. When I used LCR (through MISDN and
chan_lcr) to hook OpenBSC to Asterisk, I was able to hear both the test music and a test
tone, but the echo test was not working. When I left LCR and Asterisk out (just two
mobiles calling each other) I was not able to hear anything. I am using normal Full Rate
calls (no AMR, no EFR, no HR).
Anyway is this the desired way to hook OpenBSC to Asterisk? I know LCR also have a SIP
method to connect to Asterisk, but I never figured that out and have good experience with
the MISDN method.
which branch are you testing with?
For Osmo-BTS I used Fairwaves/master, for Osmo-TRX I used the master branch (the
fiarwaves/master is still not compiling due to the compile time instruction set issue we
identified a few weeks ago). I can try fairwaves/rebase for Osmo-BTS if you want.
I'd suggest checking that your uplink works
I use RX gain 12, the MS TX power is limited to 20dBm and I also have a duplex filter.
With this setup "show lchan" say the uplink is around -47dBm the downlink is
around -67dBm. The TRX log does not indicate any saturation issue (or any other problems
during the call).
Will try and enable the extra logging and try to extract some meaningful information from
that first, after that will try fairwaves/rebase.
Thanks for your help!
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Alexander Chemeris" <alexander.chemeris(a)gmail.com>
Címzett: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Szombat, 2015. Szeptember 19. 20:09:54
Tárgy: Re: Half sided calls
Hi Sipos,
On Sat, Sep 19, 2015 at 5:05 PM, Sipos Csaba
<sipos.csaba(a)kvk.uni-obuda.hu> wrote:
I am in the process of creating the Wiki page for
Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
Any reason it's specific to B2x0? Configuration should be 99% common
for all SDR devices and I think it makes more sense to have a single
page for that, like the old network_from_scratch.
I am quite close, both data and calls are working, but
the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half
sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr
x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f
n=1284764 to
transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f
n=1284764 to
transmit.
Log message suggests that downlink doesn't receive a frame from RTP
side and thus transmits a filler frame. So it seems like your downlink
doesn't work rather than uplink.
It's not clear what do you mean that a call is half sided? According
to the logs, downlink frames are not served at both timeslots, so you
should not hear anything on both sides of the call.
I'd suggest checking that your uplink works, e.g. by looking at
osmo-trx logs. If you have the latest one, it should output a warning
if Rx side is saturated, which is the most possible reason for the
issue.
Another possible issue is codec. I have tested only with GSM-FR so
far. If you enable more debugging in osmo-bts, you should be able to
see decoding result at least for gsm-fr codec. I recommend you enable
at least NOTICE level for L1C and see if there are any fail messages
from here:
http://cgit.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/gsm0503_coding.c?h=2…
One more thing - which branch are you testing with? I've been testing
201509-fairwaves-rebase. If you're using something else - I'd be
curious what happens if you try 201509-fairwaves-rebase.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
12:31 p.m.
Dear Alexander,
Sorry for the lots of mails :-)
I found the issue, but first let me go through what I did:
1. Osmo-BTS fiarwaves_rebase: I tried it. it compiles fine, but the problem is the same.
2. I tried to use fairwaves/master for Libosmo-abis, but the Fairwaves/master branch of
OpenBSC is not compiling with the Fairwaves/master branch of Libosmo-abis. This is the
error log:
CC abis_nm.o
CC abis_nm_vty.o
CC abis_om2000.o
CC abis_om2000_vty.o
CC abis_rsl.o
CC bsc_rll.o
CC paging.o
CC bts_ericsson_rbs2000.o
CC bts_ipaccess_nanobts.o
In file included from bts_ipaccess_nanobts.c:39:0:
/usr/local/include/osmocom/abis/ipaccess.h:7:8: error: redefinition of âstruct
ipaccess_unitâ
struct ipaccess_unit {
^
In file included from bts_ipaccess_nanobts.c:38:0:
/usr/local/include/osmocom/gsm/ipa.h:11:8: note: originally defined here
struct ipaccess_unit {
^
make[3]: *** [bts_ipaccess_nanobts.o] Error 1
make[3]: Leaving directory `/root/osmocom/openbsc/openbsc/src/libbsc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/osmocom/openbsc/openbsc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/osmocom/openbsc/openbsc'
make: *** [all] Error 2
3. I tried to revert LibORTP to an older version, so I reverted from 0.24.2 to 0.22.0,
recompiled everything and now the voice calls are working fine.
So there is definitely a compatiblity issue with ORTP version 0.24.2 and the compile
script is not taking care of that.
Now I am using Libosmo-abis master, OpenBSC Fairwaves/master, Osmo-BTS fairwaves_rebase
and Osmo-TRX master and everything seems to work on a B200.
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu>
Címzett: "Alexander Chemeris" <alexander.chemeris(a)gmail.com>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Vasárnap, 2015. Szeptember 20. 11:35:17
Tárgy: Re: Half sided calls
Hi Alexander,
Just attached the log with the L1C set to notice level. For this test I did not used
"-m" nor "-P", just pure OpenBSC with two phones calling each other.
I would highlight the following line:
<0014> trau/osmo_ortp.c:132 osmo-ortp(52995): network_error
From the very beggining I get a sense that maybe the
RTP is not working (I got half sided calls on SIP with asterisk previously because of RTP
port issues). I am using ORTP version 0.24.2 maybe it is too new?
One more thing: I am using the master branch of Libosmo-Abis. Can that be a problem?
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu>
Címzett: "Alexander Chemeris" <alexander.chemeris(a)gmail.com>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Vasárnap, 2015. Szeptember 20. 11:10:54
Tárgy: Re: Half sided calls
Dear Alexander,
Any reason it's specific to B2x0?
Not really, now that UmTRX also uses the standard UHD branch, it should be the same. The
only reason is that I have a B200 and a B210 (finally) to test, but I dont have for
example a UmTRX, so I cant validate my method against that piece of hardware.
So it seems like your downlink doesn't work rather
than uplink.
Trust me, its the uplink which is not working. When I used LCR (through MISDN and
chan_lcr) to hook OpenBSC to Asterisk, I was able to hear both the test music and a test
tone, but the echo test was not working. When I left LCR and Asterisk out (just two
mobiles calling each other) I was not able to hear anything. I am using normal Full Rate
calls (no AMR, no EFR, no HR).
Anyway is this the desired way to hook OpenBSC to Asterisk? I know LCR also have a SIP
method to connect to Asterisk, but I never figured that out and have good experience with
the MISDN method.
which branch are you testing with?
For Osmo-BTS I used Fairwaves/master, for Osmo-TRX I used the master branch (the
fiarwaves/master is still not compiling due to the compile time instruction set issue we
identified a few weeks ago). I can try fairwaves/rebase for Osmo-BTS if you want.
I'd suggest checking that your uplink works
I use RX gain 12, the MS TX power is limited to 20dBm and I also have a duplex filter.
With this setup "show lchan" say the uplink is around -47dBm the downlink is
around -67dBm. The TRX log does not indicate any saturation issue (or any other problems
during the call).
Will try and enable the extra logging and try to extract some meaningful information from
that first, after that will try fairwaves/rebase.
Thanks for your help!
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Alexander Chemeris" <alexander.chemeris(a)gmail.com>
Címzett: "Sipos Csaba" <sipos.csaba(a)kvk.uni-obuda.hu>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Szombat, 2015. Szeptember 19. 20:09:54
Tárgy: Re: Half sided calls
Hi Sipos,
On Sat, Sep 19, 2015 at 5:05 PM, Sipos Csaba
<sipos.csaba(a)kvk.uni-obuda.hu> wrote:
I am in the process of creating the Wiki page for
Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
Any reason it's specific to B2x0? Configuration should be 99% common
for all SDR devices and I think it makes more sense to have a single
page for that, like the old network_from_scratch.
I am quite close, both data and calls are working, but
the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half
sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr
x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f
n=1284764 to
transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f
n=1284764 to
transmit.
Log message suggests that downlink doesn't receive a frame from RTP
side and thus transmits a filler frame. So it seems like your downlink
doesn't work rather than uplink.
It's not clear what do you mean that a call is half sided? According
to the logs, downlink frames are not served at both timeslots, so you
should not hear anything on both sides of the call.
I'd suggest checking that your uplink works, e.g. by looking at
osmo-trx logs. If you have the latest one, it should output a warning
if Rx side is saturated, which is the most possible reason for the
issue.
Another possible issue is codec. I have tested only with GSM-FR so
far. If you enable more debugging in osmo-bts, you should be able to
see decoding result at least for gsm-fr codec. I recommend you enable
at least NOTICE level for L1C and see if there are any fail messages
from here:
http://cgit.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/gsm0503_coding.c?h=2…
One more thing - which branch are you testing with? I've been testing
201509-fairwaves-rebase. If you're using something else - I'd be
curious what happens if you try 201509-fairwaves-rebase.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
22 Apr
22 Apr
1:40 p.m.
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) ?
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 results is one way audio.
Regards,
Pavel.
2:28 p.m.
Some clarification - my post was intended as a reply to this message :
http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html
I'd inserted email header 'In-Reply-To:
<864880037.819106.1442745090880.JavaMail.zimbra@kvk.uni-obuda.hu><mailto:864880037.819106.1442745090880.JavaMail.zimbra@kvk.uni-obuda.hu>'
which points to message-id of the aforementioned post, hoping that my post will be glued
to an existing thread of September 2015.
But looks like this naive approach doesn't work.
Regards,
Pavel.
On 04/22/2016 02: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) ?
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 results is one way audio.
Regards,
Pavel.
4:51 p.m.
On 22 Apr 2016, at 14:28, Pavel Balashov
<psb1979(a)hotmail.com> wrote:
Hi pavel,
Some clarification - my post was intended as a reply to this message :
http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html
I'd inserted email header 'In-Reply-To:
<864880037.819106.1442745090880.JavaMail.zimbra(a)kvk.uni-obuda.hu>' which points
to message-id of the aforementioned post, hoping that my post will be glued to an
existing thread of September 2015.
But looks like this naive approach doesn't work.
thanks for having a look at it. Did you consider opening/discussion with oRTP upstream as
well? In our application I don't think RTCP is a requirement so the -1 + 1 should not
be a big issue.
For a call which ports are actually being bound (ip+port)? What is being advertized on
RSL? Where are the actual RTP frames going?
holger
27 Apr
27 Apr
7:18 p.m.
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(a)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
28 Apr
28 Apr
3:50 p.m.
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?
29 Apr
29 Apr
4:21 p.m.
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
well.
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:
--
Max Suraev <msuraev(a)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
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?
2920
days inactive
3143
days old
10 comments
5 participants
participants (5)
-
Alexander Chemeris -
Holger Freyther -
Max -
Pavel Balashov -
Sipos Csaba