Hi, I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use: - I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this. - I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038. I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug? Best regards Neven Boric
use 1.4.x latest (1.4.20), traces in pcap and pastebin On Wed, Jul 8, 2015 at 3:23 PM, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618
Thanks. Here is a pcap and the pastebin is at: https://pastebin.freeswitch.org/24299 I realized that if I wait about 10 seconds with the first call on hold, and don't even attempt to transfer, FS will hangup both legs of the original call. Also, there is an error before FS decides to hangup: 2015-07-08 15:54:36.617835 [CRIT] switch_core_io.c:173 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media! Appreciate your help. Neven On Wed, Jul 8, 2015 at 11:03 AM, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
use 1.4.x latest (1.4.20), traces in pcap and pastebin
On Wed, Jul 8, 2015 at 3:23 PM, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Sincerely,
Giovanni Maruzzelli Cell : +39-347-2665618
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading. - I also tried with the 1.4 branch and hold/unhold works correctly, but now
attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4. On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre@gmail.com> wrote:
- I first tried with the 1.2 branch, as that was the version I was using
locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading.
Yes, I know it's not currently supported, but maybe somebody had the same problem and fixed it in a different way. Or maybe somebody could point me in the right direction to remove that final 'sendonly'.
- I also tried with the 1.4 branch and hold/unhold works correctly, but
now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4.
I will try with master and report back, thanks.
On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Ok, I tried with master, and something strange happened. I'm pretty sure it worked last night, but now I'm testing again and I'm getting the same behavior I described with 1.4. I don't even have to get a third phone involved. All I do is call from A to B, put B on hold and then wait, and about ten seconds later, FS will hangup both calls, as if some timeout was triggered. I get the same error on the log: 2015-07-09 14:36:43.506725 [CRIT] switch_core_io.c:93 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media! I also get no MOH on the phone that was put on hold. On Wed, Jul 8, 2015 at 3:41 PM, Neven Boric <nboric@yx.cl> wrote:
On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre@gmail.com> wrote:
- I first tried with the 1.2 branch, as that was the version I was using
locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading.
Yes, I know it's not currently supported, but maybe somebody had the same problem and fixed it in a different way. Or maybe somebody could point me in the right direction to remove that final 'sendonly'.
- I also tried with the 1.4 branch and hold/unhold works correctly, but
now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4.
I will try with master and report back, thanks.
On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I compared the logs between 1.2 and 1.4, and I'm pretty sure in 1.4 one of the threads is getting stuck until it times out. Here is the output for 1.4 right after I try to put the call on hold: 2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] sofia.c:6627 Channel sofia/internal/ 171@yx.cl entering state [ready][200] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3680 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3735 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3596 Set telephone-event payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:2507 Set Codec sofia/internal/171@yx.cl PCMA/8000 20 ms 160 samples 64000 bits 1 channels 2015-07-09 20:08:19.952352 [DEBUG] switch_core_codec.c:111 sofia/internal/ 171@yx.cl Original read codec set to PCMA:8 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3943 Set 2833 dtmf send/recv payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5179 AUDIO RTP [sofia/internal/171@yx.cl] 10.176.0.1 port 21846 -> 10.176.4.121 port 50140 codec: 8 ms: 20 2015-07-09 20:08:19.952352 [DEBUG] switch_rtp.c:3569 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5477 Set 2833 dtmf send payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5483 Set 2833 dtmf receive payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5505 sofia/internal/ 171@yx.cl Set rtp dtmf delay to 40 2015-07-09 20:08:19.972367 [DEBUG] switch_core_session.c:912 Send signal sofia/internal/140@10.50.100.16:5060 [BREAK] 2015-07-09 20:08:30.732483 [CRIT] switch_core_io.c:173 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media! Nothing happens for 10 seconds between 2015-07-09 20:08:19.972367 and 2015-07-09 20:08:30.732483, FS sends no MOH and then decides to hangup both calls. And here is the output for 1.2 in a similar situation. It's a different server with different extensions, but I tried to capture the exact same moment. 2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] sofia.c:5815 Channel sofia/internal/ sip:3315@172.17.100.86:5062 entering state [ready][200] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5282 Audio Codec Compare [PCMA:8:8000:20:64000]/[PCMA:8:8000:20:64000] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3190 Set Codec sofia/internal/sip:3315@172.17.100.86:5062 PCMA/8000 20 ms 160 samples 64000 bits 2015-07-09 20:02:28.214025 [DEBUG] switch_core_codec.c:111 sofia/internal/ sip:3315@172.17.100.86:5062 Original read codec set to PCMA:8 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5442 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3449 AUDIO RTP [sofia/internal/sip:3315@172.17.100.86:5062] 172.30.0.93 port 23690 -> 10.10.1.173 port 50692 codec: 8 ms: 20 2015-07-09 20:02:28.214025 [DEBUG] switch_rtp.c:2040 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3716 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3722 Set 2833 dtmf receive payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3749 sofia/internal/ sip:3315@172.17.100.86:5062 Set rtp dtmf delay to 40 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1852 (sofia/external/8781@10.20.1.125.6:5075) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_state_machine.c:415 (sofia/external/8781@10.20.1.125.6:5075) Running State Change CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:1351 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1854 (sofia/internal/ sip:3315@172.17.100.86:5062) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] ... lots of other things and then FS plays MOH correctly. As I mentioned, the same thing happens in master. Does anyone have an idea of what could be happening? I can make all the tests and provide any logs necessary. Thanks On Thu, Jul 9, 2015 at 11:42 AM, Neven Boric <nboric@yx.cl> wrote:
Ok, I tried with master, and something strange happened. I'm pretty sure it worked last night, but now I'm testing again and I'm getting the same behavior I described with 1.4. I don't even have to get a third phone involved. All I do is call from A to B, put B on hold and then wait, and about ten seconds later, FS will hangup both calls, as if some timeout was triggered. I get the same error on the log:
2015-07-09 14:36:43.506725 [CRIT] switch_core_io.c:93 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
I also get no MOH on the phone that was put on hold.
On Wed, Jul 8, 2015 at 3:41 PM, Neven Boric <nboric@yx.cl> wrote:
On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre@gmail.com> wrote:
- I first tried with the 1.2 branch, as that was the version I was using
locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading.
Yes, I know it's not currently supported, but maybe somebody had the same problem and fixed it in a different way. Or maybe somebody could point me in the right direction to remove that final 'sendonly'.
- I also tried with the 1.4 branch and hold/unhold works correctly, but
now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4.
I will try with master and report back, thanks.
On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Anyone, please? It seems very strange that I'm the only one having this issue. The bypass-media option doesn't seem to be so unpopular. On Fri, Jul 10, 2015 at 12:34 PM, Neven Boric <nboric@yx.cl> wrote:
I compared the logs between 1.2 and 1.4, and I'm pretty sure in 1.4 one of the threads is getting stuck until it times out.
Here is the output for 1.4 right after I try to put the call on hold:
2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] sofia.c:6627 Channel sofia/internal/ 171@yx.cl entering state [ready][200] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3680 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3735 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3596 Set telephone-event payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:2507 Set Codec sofia/internal/171@yx.cl PCMA/8000 20 ms 160 samples 64000 bits 1 channels 2015-07-09 20:08:19.952352 [DEBUG] switch_core_codec.c:111 sofia/internal/ 171@yx.cl Original read codec set to PCMA:8 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3943 Set 2833 dtmf send/recv payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5179 AUDIO RTP [sofia/internal/171@yx.cl] 10.176.0.1 port 21846 -> 10.176.4.121 port 50140 codec: 8 ms: 20 2015-07-09 20:08:19.952352 [DEBUG] switch_rtp.c:3569 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5477 Set 2833 dtmf send payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5483 Set 2833 dtmf receive payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5505 sofia/internal/ 171@yx.cl Set rtp dtmf delay to 40 2015-07-09 20:08:19.972367 [DEBUG] switch_core_session.c:912 Send signal sofia/internal/140@10.50.100.16:5060 [BREAK] 2015-07-09 20:08:30.732483 [CRIT] switch_core_io.c:173 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
Nothing happens for 10 seconds between 2015-07-09 20:08:19.972367 and 2015-07-09 20:08:30.732483, FS sends no MOH and then decides to hangup both calls.
And here is the output for 1.2 in a similar situation. It's a different server with different extensions, but I tried to capture the exact same moment.
2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] sofia.c:5815 Channel sofia/internal/ sip:3315@172.17.100.86:5062 entering state [ready][200] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5282 Audio Codec Compare [PCMA:8:8000:20:64000]/[PCMA:8:8000:20:64000] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3190 Set Codec sofia/internal/sip:3315@172.17.100.86:5062 PCMA/8000 20 ms 160 samples 64000 bits 2015-07-09 20:02:28.214025 [DEBUG] switch_core_codec.c:111 sofia/internal/ sip:3315@172.17.100.86:5062 Original read codec set to PCMA:8 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5442 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3449 AUDIO RTP [sofia/internal/sip:3315@172.17.100.86:5062] 172.30.0.93 port 23690 -> 10.10.1.173 port 50692 codec: 8 ms: 20 2015-07-09 20:02:28.214025 [DEBUG] switch_rtp.c:2040 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3716 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3722 Set 2833 dtmf receive payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3749 sofia/internal/ sip:3315@172.17.100.86:5062 Set rtp dtmf delay to 40 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1852 (sofia/external/8781@10.20.1.125.6:5075) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_state_machine.c:415 (sofia/external/8781@10.20.1.125.6:5075) Running State Change CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:1351 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1854 (sofia/internal/sip:3315@172.17.100.86:5062) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK]
... lots of other things and then FS plays MOH correctly.
As I mentioned, the same thing happens in master.
Does anyone have an idea of what could be happening? I can make all the tests and provide any logs necessary.
Thanks
On Thu, Jul 9, 2015 at 11:42 AM, Neven Boric <nboric@yx.cl> wrote:
Ok, I tried with master, and something strange happened. I'm pretty sure it worked last night, but now I'm testing again and I'm getting the same behavior I described with 1.4. I don't even have to get a third phone involved. All I do is call from A to B, put B on hold and then wait, and about ten seconds later, FS will hangup both calls, as if some timeout was triggered. I get the same error on the log:
2015-07-09 14:36:43.506725 [CRIT] switch_core_io.c:93 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
I also get no MOH on the phone that was put on hold.
On Wed, Jul 8, 2015 at 3:41 PM, Neven Boric <nboric@yx.cl> wrote:
On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre@gmail.com> wrote:
- I first tried with the 1.2 branch, as that was the version I was
using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading.
Yes, I know it's not currently supported, but maybe somebody had the same problem and fixed it in a different way. Or maybe somebody could point me in the right direction to remove that final 'sendonly'.
- I also tried with the 1.4 branch and hold/unhold works correctly, but
now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4.
I will try with master and report back, thanks.
On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Your first mistake is filing bugs on the mailing list. Its impossible to keep track of random mailing threads. https://freeswitch.org/jira On Mon, Jul 13, 2015 at 3:47 PM, Neven Boric <nboric@yx.cl> wrote:
Anyone, please? It seems very strange that I'm the only one having this issue. The bypass-media option doesn't seem to be so unpopular.
On Fri, Jul 10, 2015 at 12:34 PM, Neven Boric <nboric@yx.cl> wrote:
I compared the logs between 1.2 and 1.4, and I'm pretty sure in 1.4 one of the threads is getting stuck until it times out.
Here is the output for 1.4 right after I try to put the call on hold:
2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] sofia.c:6627 Channel sofia/internal/ 171@yx.cl entering state [ready][200] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3680 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3735 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3596 Set telephone-event payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:2507 Set Codec sofia/internal/171@yx.cl PCMA/8000 20 ms 160 samples 64000 bits 1 channels 2015-07-09 20:08:19.952352 [DEBUG] switch_core_codec.c:111 sofia/internal/ 171@yx.cl Original read codec set to PCMA:8 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3943 Set 2833 dtmf send/recv payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5179 AUDIO RTP [sofia/internal/171@yx.cl] 10.176.0.1 port 21846 -> 10.176.4.121 port 50140 codec: 8 ms: 20 2015-07-09 20:08:19.952352 [DEBUG] switch_rtp.c:3569 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5477 Set 2833 dtmf send payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5483 Set 2833 dtmf receive payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5505 sofia/internal/171@yx.cl Set rtp dtmf delay to 40 2015-07-09 20:08:19.972367 [DEBUG] switch_core_session.c:912 Send signal sofia/internal/140@10.50.100.16:5060 [BREAK] 2015-07-09 20:08:30.732483 [CRIT] switch_core_io.c:173 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
Nothing happens for 10 seconds between 2015-07-09 20:08:19.972367 and 2015-07-09 20:08:30.732483, FS sends no MOH and then decides to hangup both calls.
And here is the output for 1.2 in a similar situation. It's a different server with different extensions, but I tried to capture the exact same moment.
2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] sofia.c:5815 Channel sofia/internal/ sip:3315@172.17.100.86:5062 entering state [ready][200] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5282 Audio Codec Compare [PCMA:8:8000:20:64000]/[PCMA:8:8000:20:64000] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3190 Set Codec sofia/internal/sip:3315@172.17.100.86:5062 PCMA/8000 20 ms 160 samples 64000 bits 2015-07-09 20:02:28.214025 [DEBUG] switch_core_codec.c:111 sofia/internal/ sip:3315@172.17.100.86:5062 Original read codec set to PCMA:8 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5442 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3449 AUDIO RTP [sofia/internal/sip:3315@172.17.100.86:5062] 172.30.0.93 port 23690 -> 10.10.1.173 port 50692 codec: 8 ms: 20 2015-07-09 20:02:28.214025 [DEBUG] switch_rtp.c:2040 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3716 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3722 Set 2833 dtmf receive payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3749 sofia/internal/ sip:3315@172.17.100.86:5062 Set rtp dtmf delay to 40 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1852 (sofia/external/8781@10.20.1.125.6:5075) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_state_machine.c:415 (sofia/external/8781@10.20.1.125.6:5075) Running State Change CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:1351 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1854 (sofia/internal/sip:3315@172.17.100.86:5062) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK]
... lots of other things and then FS plays MOH correctly.
As I mentioned, the same thing happens in master.
Does anyone have an idea of what could be happening? I can make all the tests and provide any logs necessary.
Thanks
On Thu, Jul 9, 2015 at 11:42 AM, Neven Boric <nboric@yx.cl> wrote:
Ok, I tried with master, and something strange happened. I'm pretty sure it worked last night, but now I'm testing again and I'm getting the same behavior I described with 1.4. I don't even have to get a third phone involved. All I do is call from A to B, put B on hold and then wait, and about ten seconds later, FS will hangup both calls, as if some timeout was triggered. I get the same error on the log:
2015-07-09 14:36:43.506725 [CRIT] switch_core_io.c:93 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
I also get no MOH on the phone that was put on hold.
On Wed, Jul 8, 2015 at 3:41 PM, Neven Boric <nboric@yx.cl> wrote:
On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre@gmail.com> wrote:
- I first tried with the 1.2 branch, as that was the version I was
using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading.
Yes, I know it's not currently supported, but maybe somebody had the same problem and fixed it in a different way. Or maybe somebody could point me in the right direction to remove that final 'sendonly'.
- I also tried with the 1.4 branch and hold/unhold works correctly,
but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4.
I will try with master and report back, thanks.
On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
Hi,
I have been using FS for a long time on a local server without issues, but now I want to move to a remote server to support some new usage scenarios. I'm trying to use inbound-bypass-media=true to keep the audio out of the server. This mostly works, but I have two different issues, depending on which FS version I use:
- I first tried with the 1.2 branch, as that was the version I was using locally. The issue with that version is that when a phone holds and then unholds a call, I get no audio on the phone that started the hold. I found option bypass-media-after-hold, but realized that it was not included in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 from the master branch. Now FS correctly tries to restore direct media between the endpoints with reINVITEs, but unfortunately includes a 'sendonly' in the last SDP to the phone that unholds, so I still get no audio. I haven't found a way to fix this.
- I also tried with the 1.4 branch and hold/unhold works correctly, but now attended transfer doesn't work, FS after some time ends the call on the side that was put on hold waiting to be transferred. This time seems to be inconsistent, and sometimes the transfer actually works, so maybe it is a timing issue. This seems similar/related to FS-4038.
I can get logs and SIP captures, what would be the preferred way to provide them (pcap, inline text, pastebin)? Or maybe it's better to go ahead and file a bug?
Best regards Neven Boric
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
Filed bug FS-7834 On Mon, Jul 13, 2015 at 8:00 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Your first mistake is filing bugs on the mailing list. Its impossible to keep track of random mailing threads. https://freeswitch.org/jira
On Mon, Jul 13, 2015 at 3:47 PM, Neven Boric <nboric@yx.cl> wrote:
Anyone, please? It seems very strange that I'm the only one having this issue. The bypass-media option doesn't seem to be so unpopular.
On Fri, Jul 10, 2015 at 12:34 PM, Neven Boric <nboric@yx.cl> wrote:
I compared the logs between 1.2 and 1.4, and I'm pretty sure in 1.4 one of the threads is getting stuck until it times out.
Here is the output for 1.4 right after I try to put the call on hold:
2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal sofia/internal/171@yx.cl [BREAK] 2015-07-09 20:08:19.952352 [DEBUG] sofia.c:6627 Channel sofia/internal/ 171@yx.cl entering state [ready][200] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3680 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3735 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3596 Set telephone-event payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:2507 Set Codec sofia/internal/171@yx.cl PCMA/8000 20 ms 160 samples 64000 bits 1 channels 2015-07-09 20:08:19.952352 [DEBUG] switch_core_codec.c:111 sofia/internal/171@yx.cl Original read codec set to PCMA:8 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:3943 Set 2833 dtmf send/recv payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5179 AUDIO RTP [sofia/internal/171@yx.cl] 10.176.0.1 port 21846 -> 10.176.4.121 port 50140 codec: 8 ms: 20 2015-07-09 20:08:19.952352 [DEBUG] switch_rtp.c:3569 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5477 Set 2833 dtmf send payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5483 Set 2833 dtmf receive payload to 101 2015-07-09 20:08:19.952352 [DEBUG] switch_core_media.c:5505 sofia/internal/171@yx.cl Set rtp dtmf delay to 40 2015-07-09 20:08:19.972367 [DEBUG] switch_core_session.c:912 Send signal sofia/internal/140@10.50.100.16:5060 [BREAK] 2015-07-09 20:08:30.732483 [CRIT] switch_core_io.c:173 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
Nothing happens for 10 seconds between 2015-07-09 20:08:19.972367 and 2015-07-09 20:08:30.732483, FS sends no MOH and then decides to hangup both calls.
And here is the output for 1.2 in a similar situation. It's a different server with different extensions, but I tried to capture the exact same moment.
2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK] 2015-07-09 20:02:28.214025 [DEBUG] sofia.c:5815 Channel sofia/internal/ sip:3315@172.17.100.86:5062 entering state [ready][200] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5282 Audio Codec Compare [PCMA:8:8000:20:64000]/[PCMA:8:8000:20:64000] 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3190 Set Codec sofia/internal/sip:3315@172.17.100.86:5062 PCMA/8000 20 ms 160 samples 64000 bits 2015-07-09 20:02:28.214025 [DEBUG] switch_core_codec.c:111 sofia/internal/sip:3315@172.17.100.86:5062 Original read codec set to PCMA:8 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:5442 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3449 AUDIO RTP [sofia/internal/sip:3315@172.17.100.86:5062] 172.30.0.93 port 23690 -> 10.10.1.173 port 50692 codec: 8 ms: 20 2015-07-09 20:02:28.214025 [DEBUG] switch_rtp.c:2040 Starting timer [soft] 160 bytes per 20ms 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3716 Set 2833 dtmf send payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3722 Set 2833 dtmf receive payload to 101 2015-07-09 20:02:28.214025 [DEBUG] sofia_glue.c:3749 sofia/internal/ sip:3315@172.17.100.86:5062 Set rtp dtmf delay to 40 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1852 (sofia/external/8781@10.20.1.125.6:5075) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_state_machine.c:415 (sofia/external/8781@10.20.1.125.6:5075) Running State Change CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:1351 Send signal sofia/external/8781@10.20.1.125.6:5075 [BREAK] 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1854 (sofia/internal/sip:3315@172.17.100.86:5062) State Change CS_HIBERNATE -> CS_CONSUME_MEDIA 2015-07-09 20:02:28.223984 [DEBUG] switch_core_session.c:933 Send signal sofia/internal/sip:3315@172.17.100.86:5062 [BREAK]
... lots of other things and then FS plays MOH correctly.
As I mentioned, the same thing happens in master.
Does anyone have an idea of what could be happening? I can make all the tests and provide any logs necessary.
Thanks
On Thu, Jul 9, 2015 at 11:42 AM, Neven Boric <nboric@yx.cl> wrote:
Ok, I tried with master, and something strange happened. I'm pretty sure it worked last night, but now I'm testing again and I'm getting the same behavior I described with 1.4. I don't even have to get a third phone involved. All I do is call from A to B, put B on hold and then wait, and about ten seconds later, FS will hangup both calls, as if some timeout was triggered. I get the same error on the log:
2015-07-09 14:36:43.506725 [CRIT] switch_core_io.c:93 sofia/internal/ 140@10.50.100.16:5060 reading on a session with no media!
I also get no MOH on the phone that was put on hold.
On Wed, Jul 8, 2015 at 3:41 PM, Neven Boric <nboric@yx.cl> wrote:
On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre@gmail.com> wrote:
- I first tried with the 1.2 branch, as that was the version I was > using locally. The issue with that version is that when a phone holds and > then unholds a call, I get no audio on the phone that started the hold. I > found option bypass-media-after-hold, but realized that it was not included > in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 > from the master branch. Now FS correctly tries to restore direct media > between the endpoints with reINVITEs, but unfortunately includes a > 'sendonly' in the last SDP to the phone that unholds, so I still get no > audio. I haven't found a way to fix this.
Which probably means there's other commits required. 1.2 is EOL and no longer supported, 1.4 is the current stable release. I wouldn't spend any time getting 1.2 working, and instead work on upgrading.
Yes, I know it's not currently supported, but maybe somebody had the same problem and fixed it in a different way. Or maybe somebody could point me in the right direction to remove that final 'sendonly'.
- I also tried with the 1.4 branch and hold/unhold works correctly, > but now attended transfer doesn't work, FS after some time ends the call on > the side that was put on hold waiting to be transferred. This time seems to > be inconsistent, and sometimes the transfer actually works, so maybe it is > a timing issue. This seems similar/related to FS-4038. >
Also see if you can replicate it on master, as that's close to the upcoming 1.6 release and will have a lot of changes over 1.4.
I will try with master and report back, thanks.
On 8 July 2015 at 14:23, Neven Boric <nboric@yx.cl> wrote:
> Hi, > > I have been using FS for a long time on a local server without > issues, but now I want to move to a remote server to support some new usage > scenarios. I'm trying to use inbound-bypass-media=true to keep the audio > out of the server. This mostly works, but I have two different issues, > depending on which FS version I use: > > - I first tried with the 1.2 branch, as that was the version I was > using locally. The issue with that version is that when a phone holds and > then unholds a call, I get no audio on the phone that started the hold. I > found option bypass-media-after-hold, but realized that it was not included > in the 1.2 branch, so I "ported" commits 3ecb504, 8fa385b and e4e9b1b9f93 > from the master branch. Now FS correctly tries to restore direct media > between the endpoints with reINVITEs, but unfortunately includes a > 'sendonly' in the last SDP to the phone that unholds, so I still get no > audio. I haven't found a way to fix this. > > - I also tried with the 1.4 branch and hold/unhold works correctly, > but now attended transfer doesn't work, FS after some time ends the call on > the side that was put on hold waiting to be transferred. This time seems to > be inconsistent, and sometimes the transfer actually works, so maybe it is > a timing issue. This seems similar/related to FS-4038. > > I can get logs and SIP captures, what would be the preferred way to > provide them (pcap, inline text, pastebin)? Or maybe it's better to go > ahead and file a bug? > > Best regards > Neven Boric > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org > http://www.freeswitchsolutions.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://confluence.freeswitch.org > http://www.cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE: > http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org >
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Anthony Minessale
-
Giovanni Maruzzelli
-
Neven Boric
-
Steven Ayre