[asterisk-bugs] [JIRA] (ASTERISK-23142) Large timestamp skew in RTP stream during blind transfer

[David Woolley (JIRA)]

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

David Woolley commented on ASTERISK-23142:
------------------------------------------

On further analysis, ASTERISK-12042 only applies to timestamp and seqno, but the field that actually propagates the timestamp information is delivery and the problem we are having with this looks like it is that if a smoother is present, and there is a partial frame in its memory, it will continue to dead reckon the output value of delivery, based only on sample counts, ignoring the input one.  When there is a gap in the media, Lync sees a negative timestamp step because the value of delivery hasn't accounted for the gap, and resets its jitter buffer, dumping an extra second of media.

I haven't found a fix for this in any SVN version but our working version is rather obsolete, so I may not be able to test this on a supported version.

> Large timestamp skew in RTP stream during blind transfer
> --------------------------------------------------------
>
>                 Key: ASTERISK-23142
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23142
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 11.6.0, 11.7.0
>            Reporter: Filip Frank
>         Attachments: asterisk_rtp_large_transfer_skew.patch, iptel207setting.txt, rtp_instance_debug.patch, rtp_timestamp_jump.pcap
>
>
> I have problem with asterisk 11, I call from phone A (ip 10.76.17.130 - iptel207) to phone B(iptel106). After answer the call on B, i use blind transfer asterisk feature to phone C(iptel500). Problem is after bridge with A and C, the timestamps in RTP from asterisk to phone A jumps. In first RTP packet with jumped timestamp the market bit is set, but SSRC is not changed. This is test situation, but in real i have a problem if A is Ericsson IMS(operator O2). They drop audio from our asterisk after timestamp jump and A dont hear  C. I my attached pcap trace bad RTP is with SSRC 0x445FBF7D. I see in wireshark big skew too....
> I found this in RTP RFC3550:
> " All packets from a synchronization source form part of the same
>       timing and sequence number space, so a receiver groups packets by
>       synchronization source for playback."
> Then I think timestamps cant jump without SSRC change. We not use direct media. All RTPs flow over asterisk.



--
This message was sent by Atlassian JIRA
(v6.2#6252)