[asterisk-bugs] [JIRA] (ASTERISK-28864) RTP Timestamp not increasing after several transfers and codec changes

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-28864:
-------------------------------------

    Assignee: Asterisk Team  (was: nappsoft)
      Status: Triage  (was: Waiting for Feedback)

> 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
>            Assignee: Asterisk Team
>              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)