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

[Olle Johansson (JIRA)]

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

Olle Johansson commented on ASTERISK-23142:
-------------------------------------------

There is definitely a problem here. For some reason we take the incoming time stamp as the source of timing. On my system we suddenly jump backwards in time. My call scenario:

Alice calls bob
Alice puts Bob on hold
Asterisk plays moh for bob
 -> Every RTP packet has a TS that follows Alices incoming TS + 160 which is fine
Alice unholds bob
 -> Asterisk suddenly takes the incoming TS as a source and resets TS on the outbound call leg

I also think the HAS_TIMING_INFO is the problem here. It overrides all other checks if the TS is sane
and just jumps in time. I wonder where that code came from, what it is supposed to solve. As Matt say
the RTP streams are unrelated and taking the timing from the FR as exact timing is bad.

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