[Freeswitch-users] Some problems with bypass-media

Anthony Minessale anthony.minessale at gmail.com
Tue Jul 14 03:00:09 MSD 2015 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150713/eaf5a87b/attachment-0001.html

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