[asterisk-bugs] [JIRA] (ASTERISK-28898) bridge_softmix: Conference bridge not passing silent rtp packets

[Jonathan Hunter (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250819#comment-250819 ] 

Jonathan Hunter edited comment on ASTERISK-28898 at 5/18/20 9:02 AM:
---------------------------------------------------------------------

Hi Joshua,

I recompiled 16.10 with G711_NEW_ALGORITHM so build deps was;

MENUSELECT_BUILD_DEPS=bridge_holding app_cdr func_periodic_hook app_confbridge
 res_monitor res_speech res_agi res_stasis res_adsi res_smdi res_odbc 
res_crypto res_xmpp res_pjsip res_pjsip_pubsub res_pjsip_session 
res_rtp_multicast res_http_websocket res_curl app_chanspy func_cut 
func_groupcount func_uri res_ael_share res_ari res_ari_model 
res_stasis_recording res_stasis_playback res_stasis_answer 
res_stasis_snoop res_stasis_device_state func_curl 
res_odbc_transaction res_pjproject res_sorcery_config 
res_sorcery_memory res_sorcery_astdb res_statsd 
res_pjsip_outbound_publish res_calendar res_fax
res_hep res_phoneprov DONT_OPTIMIZE G711_NEW_ALGORITHM

Which I assume was correct and I reinstalled asterisk with make/make install, I then retested and unfortunately behaviour is still the same.

Jon



was (Author: jhunter at voxboxcoms.co.uk):
Hi Joshua,

I recompiled 16.10 with G711_NEW_ALGORITHM so build deps was;


> bridge_softmix: Conference bridge not passing silent rtp packets
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-28898
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28898
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_softmix, Channels/chan_sip/General, Resources/res_ari_bridges
>    Affects Versions: 16.8.0, 16.10.0
>         Environment: debian 9 Vmware machine
>            Reporter: Jonathan Hunter
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: CoreshowChanneloutputissue.txt, CoreshowChanneloutputworks.txt, debug28898issue.pcap, debug28898works.pcap, debug_log_28898issue, debug_log_28898works, OverviewTopology-OverviewTopology.pdf
>
>
> Hi Guys,
> I raised this issue in the community  and was recommended to open a ticket relating to this.
> I have an interesting issue, where when a call is initiated using ARI on 
> Asterisk 16.8/16/10 , the call connects fine and there is two way audio.
> The originator of the call is a sip client, and the called party is a mobile/cell phone.
> I wondered if there are any settings I am missing in relation to how ‘silent rtp’ (not comfort noise please see itu spec) is handled as the call uses codec G711A, and when the called party hits the mute button, not all the ‘silent rtp’ packets are passed across channels so after a number of seconds the sip client hears echo (their own breathing and typing on keyboard) and looking at the RTP streams not all the silent rtp packets are passed end to end, it appears some are dropped/not passed by Asterisk, and this only happens when we record the call using /bridges/{bridgeId}/record, if we dont record the silent rtp packets are honoured end to end and we dont have any echo.
> This issue I am seeing (and the SSRC remains consistent and there is no packet loss) is that the ‘silent rtp’ (payload all d5) being sent into Asterisk
> from the carrier channel, is for example 16 seconds, and initially the channel to the sip client device has this ‘silent rtp’ sent to it, however it is
> not for the full duration of time its sent into Asterisk in the carrier channel, it is in some examples 4 seconds but this time can vary (not consistent)
> and only happens when we instruct ARI to record the channel for example;
> Channel Recorder/ARI-0000001d;2 joined ‘simple_bridge’ stasis-bridge <6122d8f1-9706-4522-8371-539ad1036193>
> Bridge 6122d8f1-9706-4522-8371-539ad1036193: switching from simple_bridge technology to softmix
> If we dont record the channels this scenario doesnt happen and we get the same duration of ‘silent rtp’ on both the Carrier channel and the sip client channel, so in the example above it would be 16 seconds of silent rtp on both channels as opposed to a shorter duration on the sip client channel.
> There are no changes to SSRC, ports etc, the only change is the payload changes from all d5 to what could be considered a normal payload without any obvious changes I can see when running verbose logs
> Again this only happens when we record so be great to understand why that is the case.
> We can reproduce and provide traces as required in terms of the scenario.
> Thanks
> Jon



--
This message was sent by Atlassian JIRA
(v6.2#6252)