[asterisk-bugs] [JIRA] (ASTERISK-17744) RTP timestamp skewed after call transfer or call unhold

[David Woolley (JIRA)]

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

David Woolley commented on ASTERISK-17744:
------------------------------------------

The marker bit indicates optional points where a latency buffer can be dumped.  Alhthough source changes are one such point, the marker bits is not transmitted reliably and should not be interpreted as a source change. As reseting a latency buffer is a discretionary action, it doesn't matter that marker bits can get lost.  Lost SSRC changes confuse at least some Cisco phones and wireshark.

What we did, to keep the Cisco phones happy, was to increment the SSRC every time the marker bit got set, but that is a dirty solution.

The marker bit is not a surrogate for SSRC.

The specific case that upset our Ciscos was a change from internally sourced music on hold (via a beep) to through audio when a queue was answered by an agent.  I think this was the agent side for AgentLogin, but it could have been either side.  Unfortunately, we are locked into an old version of Asterisk which makes active bug reporting more and more difficult.

                
> RTP timestamp skewed after call transfer or call unhold
> -------------------------------------------------------
>
>                 Key: ASTERISK-17744
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17744
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Core/RTP
>    Affects Versions: 1.8.3
>            Reporter: xxot-alex
>            Severity: Minor
>         Attachments: timestamp_issue_bug.pcap
>
>
> During incoming call from outside on asterisk after call transfer (which is performed on asterisk) to another extension remote party lost incoming audio channel (one way audio). We find out that the reason is connected with RTP timestamp which is jumped to huge abnormal values after transfer or putting call on hold. This issue was described here
> https://issues.asterisk.org/view.php?id=11491
> and I believe here: https://issues.asterisk.org/view.php?id=17007
> But there was bug in version 1.4. In 1.8.3.3 we have the same: timestamps skewed to crazy values. In documentation to RTP there is an information that RTP Marker should be set if RTP source is changed. It is really set here, but many phones use timestamps for counting jitter and don't pay attention on RTP Marker. This is documented bug in phones Cisco 7960 and it is still not fixed. Is there any chance to fix this issue in asterisk and keep RTP timestamps stable even after call transfer?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira