[Freeswitch-users] Some problems with bypass-media

Neven Boric nboric at yx.cl
Thu Jul 9 18:42:12 MSD 2015


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 at 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 at yx.cl> wrote:

>
>
> On Wed, Jul 8, 2015 at 2:17 PM, Steven Ayre <steveayre at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150709/eac2ccce/attachment.html 


Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list