[asterisk-bugs] [JIRA] (ASTERISK-28898) bridge_softmix: Conference bridge not passing silent rtp packets
Jonathan Hunter (JIRA)
noreply at issues.asterisk.org
Mon May 18 09:03:25 CDT 2020
[ 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)
More information about the asterisk-bugs
mailing list