[Freeswitch-users] Some problems with bypass-media

Tue Jul 14 19:11:43 MSD 2015

Filed bug FS-7834

On Mon, Jul 13, 2015 at 8:00 PM, Anthony Minessale <
anthony.minessale at 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 at 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 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> _________________________________________________________________________
>> 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
>>
>
>
>
> --
> 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 at conference.freeswitch.org  ☎ +19193869900
>
> https://www.youtube.com/watch?v=9XXgW34t40s
> https://www.youtube.com/watch?v=NLaDpGQuZDA
>
> _________________________________________________________________________
> 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/20150714/c61398b0/attachment-0001.html 