[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=225176#comment-225176 ] 

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

I think the real problem here is that Asterisk is failing to pass the SSRC through and timestamps should be interpreted relative to a particular SSRC.  We did a hack for this by adding an option that added one to the transmitted SSRC whenever there was a source change (actually attempt to set the marker bit).  However we found that whilst this helped with some peers, it caused problems for others.

The transfer_skew patch, here, would actually be undesirable for anyone dealing with Lync.  We are debugging an older version of Asterisk that seems to be failing to honour the incoming timestamps and we are getting situation where a gap is introduced by Lync (it turns a single comfort noise frame into a silence frame followed by a gap in the media.  Our Asterisk is behaving as this patch would have it do, and Lync does not like the result, when the stream is fed back to it.  It goes into a recovery mode and deletes a second's worth of media after the original gap.

> 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)