[Freeswitch-users] Some problems with bypass-media

Tue Jul 14 00:47:48 MSD 2015

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 at 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 at yx.cl [BREAK]
> 2015-07-09 20:08:19.952352 [DEBUG] switch_core_session.c:1061 Send signal
> sofia/internal/171 at yx.cl [BREAK]
> 2015-07-09 20:08:19.952352 [DEBUG] sofia.c:6627 Channel sofia/internal/
> 171 at 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 at 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 at 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 at 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 at 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 at 10.50.100.16:5060 [BREAK]
> 2015-07-09 20:08:30.732483 [CRIT] switch_core_io.c:173 sofia/internal/
> 140 at 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 at 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 at 172.17.100.86:5062 [BREAK]
> 2015-07-09 20:02:28.214025 [DEBUG] sofia.c:5815 Channel sofia/internal/
> sip:3315 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 10.20.1.125.6:5075 [BREAK]
> 2015-07-09 20:02:28.223984 [DEBUG] switch_ivr_bridge.c:1854
> (sofia/internal/sip:3315 at 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 at 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 at 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 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/20150713/f0cdeb54/attachment-0001.html 