[asterisk-bugs] [JIRA] (ASTERISK-28864) RTP Timestamp not increasing after several transfers and codec changes
nappsoft (JIRA)
noreply at issues.asterisk.org
Thu Apr 30 01:28:25 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-28864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
nappsoft updated ASTERISK-28864:
--------------------------------
Attachment: ast_translate.patch
> RTP Timestamp not increasing after several transfers and codec changes
> ----------------------------------------------------------------------
>
> Key: ASTERISK-28864
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28864
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_rtp_asterisk
> Affects Versions: 16.9.0
> Reporter: nappsoft
> Labels: patch
> Attachments: ast_translate.patch
>
>
> After facing the following issue in production I was able to reproduce it in the lab:
> Our real world procedure:
> - Incoming call (G711a) going to a queue
> - pickup the channel (so not answering an INVITE, but doing a PickupChan) with a different codec (Opus in our case, didn't test with others)
> - placing the call into a queue again with an attended ast-transfer
> - the call is answered (G711a) by an agent (not with a pickup this time), using a PJSIP based softphone
> - the transfer is executed. Now both channels use G711a
> So now audio will no longer need to be transcoded. (The problem does not seem to happen when we use G711a for all clients all the time).
> What now happens is that we could observe one-way-audio or no audio at all. However this was not caused by a network issue but by wrong rtp timestamps: rtp timestamps in the outgoing stream suddenly were not increased anymore.
> I've added some logging and could observe the following behavior: the delivery time used in calc_txstamp was going back in time in res_rtp_asterisk.c. (80000ms each time).
> It seems like the problems were caused by the fact that the timestamps on rx side were lower than before after the transfer. I was able to get rid of the issue by patching translate.c
> Please note that the issue could also be influenced by the fact that we use a slightly patched version of the opus codec. However the fact that asterisk seems to struggle when f->delivery is (for whatever reason) lower than path->nextin is a problem worth looking at I guess.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list