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

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-17744:
----------------------------------------

I came across this issue while looking through open issues against the RTP engine. As it is, I don't see an issue with Asterisk's current behavior - the changes in timestamps correspond with a SSRC change, and those packets show that we flip the Marker bit appropriately.

As far as Asterisk changing the SSRC when it doesn't technically need to do so (such as in a transition from native to core bridging), that doesn't seem to be happening here. Other issues have noted this problem, but from all the information we have on this issue, it appears as if Asterisk has to change the SSRC due to either a media change internally or a media change communicated from the SCCP gateway.

As such, I'm closing this out as "Won't Fix". If there is a specific behavior you'd like changed, please describe what that is, provide a patch that changes it, and contact a bug marshal and we'll be happy to reopen this issue.
                
> 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