ASTERISK-17744: RTP timestamp skewed after call transfer or call unhold

[Home]

Summary: ASTERISK-17744: RTP timestamp skewed after call transfer or call unhold

Reporter: xxot-alex (xxot) Labels:

Date Opened: 2011-04-23 18:50:32 Date Closed: 2013-01-21 06:41:53.000-0600

Priority: Minor Regression? No

Status: Closed/Complete Components: Core/RTP

Versions: 1.8.3 Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) timestamp_issue_bug.pcap

Description: 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?

Comments: By: xxot-alex (xxot) 2011-04-23 18:59:31

In the attached dump packet number 1229 has SSRC=0x4756a8b8 Seq=29308 Timestamp=57280
Next packet from the same RTP stream: number 1242 has SSRC=0x4756a8b8 Seq=29309 Timestamp=2396350872
By: David Woolley (davidw) 2011-04-26 05:33:39

We've noticed this on earlier versions, but the only impact appeared to be on Wireshark's interpretation.

At the time, my feeling was that the real problem was a failure to change the source ID, but I can't remember if we fully checked the RFCs.
By: xxot-alex (xxot) 2011-04-26 08:46:17

We have this as real issue on version 1.8.3. The thing is that we had a lot of cisco 7960(SCCP) which are connected to SCCP gateway which is connected to asterisk. And these timestamp's jumps make 7960 crazy. There is a screenshot from 7960: http://i54.tinypic.com/2a9nsjc.jpg after call transfer was made on asterisk. The only one reason in this jitter is a wrong timestamps which asterisk generate. I believe, that most PSTN gateways don't pay attention on timestamps these phones do it.
By: David Woolley (davidw) 2011-04-26 09:04:24

The timestamps should jump. Assuming that the SCCP phones are correctly implemented, the problem is that they are not seeing a change in source, so not expecting the timestamps to jump to those from the new source. There is, however, a real change in source.

Asterisk can't simply override the timstamps, because it has no control over them when directmedia is in use, so a re-invite out would cause a change from Asterisk's hypothetical faked timestamps to the true timestamps for the source.
By: xxot-alex (xxot) 2011-04-27 07:47:14

All SIP phones which are connected to asterisk behind the NAT and we have no directmedia here. RTP source, actually, asterisk itself.
By: David Woolley (davidw) 2011-04-27 08:14:31

Whether or not you use direct media is not particularly relevant. Direct media is relevant because any solution has to work for those people who do use direct media.

Please remember that bug reports are not a mechanism for getting quick solutions.
By: Matt Jordan (mjordan) 2013-01-21 06:41:44.428-0600

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.
By: David Woolley (davidw) 2013-01-21 09:07:39.792-0600

The marker bit indicates optional points where a latency buffer can be dumped. Alhthough source changes are one such point, the marker bits is not transmitted reliably and should not be interpreted as a source change. As reseting a latency buffer is a discretionary action, it doesn't matter that marker bits can get lost. Lost SSRC changes confuse at least some Cisco phones and wireshark.

What we did, to keep the Cisco phones happy, was to increment the SSRC every time the marker bit got set, but that is a dirty solution.

The marker bit is not a surrogate for SSRC.

The specific case that upset our Ciscos was a change from internally sourced music on hold (via a beep) to through audio when a queue was answered by an agent. I think this was the agent side for AgentLogin, but it could have been either side. Unfortunately, we are locked into an old version of Asterisk which makes active bug reporting more and more difficult.