| Summary: | ASTERISK-01641: Timestamps in some RTP streams do not increment | ||
| Reporter: | veejoe (veejoe) | Labels: | |
| Date Opened: | 2004-05-17 09:13:12 | Date Closed: | 2011-06-07 14:04:41 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | On some calls, the RTP stream generated by Asterisk has timestamps that do not increment. This causes problems with some SIP user agents. Problem most apparent when Asterisk handles an incoming call from chan_capi to the SIP agent. The effect of this varies between SIP agents: on the Cisco ATA-186 voice is stuttered and robotic, while on the Cisco 7960 there is no incoming audio at all. The X-lite softphone however suffers no major impact. ****** ADDITIONAL INFORMATION ****** Call traces captured using Ethereal show that on a successful call the timestamp starts at 0 and increments by a value suitable for the codec and packet interval. On the failed call, the timestamp is an extremely large number (e.g. 4143246816) and does not increment at all. Inspecting rtp.c, there are a couple of occurrences of the unsigned int return value from calc_txstamp() being assigned into a signed int variable (lines 920 and 988 as per CVS-HEAD 05/15/04); I have changed these to test. Since it would take anywhere up to 48 hours after restart of Asterisk before the problem occurred, I will report my results in a bugnote. | ||
| Comments: | By: Mark Spencer (markster) 2004-05-17 09:39:01 You man reopen if this occurs with a call other than chan_capi. This issue has already been seen with chan_capi not clearing the delivery field before passing its frames up. You may discuss it with the chan_capi author. | ||