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
Hi Sipos, On Sat, Sep 19, 2015 at 5:05 PM, Sipos Csaba <sipos.csaba@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=20... 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
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@gmail.com> Címzett: "Sipos Csaba" <sipos.csaba@kvk.uni-obuda.hu> Másolatot kap: "OpenBSC Mailing List" <openbsc@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@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=20... 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
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@kvk.uni-obuda.hu> Címzett: "Alexander Chemeris" <alexander.chemeris@gmail.com> Másolatot kap: "OpenBSC Mailing List" <openbsc@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@gmail.com> Címzett: "Sipos Csaba" <sipos.csaba@kvk.uni-obuda.hu> Másolatot kap: "OpenBSC Mailing List" <openbsc@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@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=20... 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
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@kvk.uni-obuda.hu> Címzett: "Alexander Chemeris" <alexander.chemeris@gmail.com> Másolatot kap: "OpenBSC Mailing List" <openbsc@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@kvk.uni-obuda.hu> Címzett: "Alexander Chemeris" <alexander.chemeris@gmail.com> Másolatot kap: "OpenBSC Mailing List" <openbsc@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@gmail.com> Címzett: "Sipos Csaba" <sipos.csaba@kvk.uni-obuda.hu> Másolatot kap: "OpenBSC Mailing List" <openbsc@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@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=20... 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
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.
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.
On 22 Apr 2016, at 14:28, Pavel Balashov <psb1979@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@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
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@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
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?
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:
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@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
participants (5)
-
Alexander Chemeris -
Holger Freyther -
Max -
Pavel Balashov -
Sipos Csaba