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

[Joshua Colp (JIRA)]

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

Joshua Colp updated ASTERISK-23142:
-----------------------------------

    Affects Version/s: 13.18.4

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