[Home]

Summary:ASTERISK-21920: IAX trunk timestamps set to zero when it's bridged SIP channel wraps RTP timestamps
Reporter:Gerhard (gleroux555)Labels:
Date Opened:2013-06-19 07:29:03Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_iax2
Versions:1.8.22.0 13.18.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax.conf
( 1) issue_21920_full_log
( 2) rtpwrapiaxissue_logB.pcap
( 3) rtpwrapiaxissue-bothrtpandiaxstreams.pcap
( 4) sip.conf
Description:I have a Asterisk 1.8.22.0 box, with a SIP trunk to a Voip provider, and an IAX trunk (trunked, trunktimestamps enabled) to a client's PBX.

The client places a call that arrives at Asterisk via IAX, and then the call goes via SIP to the telco. A RTP stream is now being received from the telco.
When this RTP stream's (from the telco) timestamp wraps (at 4 294 967 295), the IAX trunk timestamp transmitted from Asterisk is ZERO from then on, until the end of the call.

I suspect this is done by the following code lines, which tries to prevent timestamps with negative values from being inserted in the IAX tx stream, without checking for RTP timestamp wrapping:


chan_iax2.c :
{noformat}
Line 5940:
if (ms < 0) {
ms = 0;
}

Line 5947
if (ms < 0)
ms = 0;
{noformat}


See the tcpdump capture file supplied (the 1.8.22.0 Asterisk box has IP 192.168.200.222, the telco has IP 192.168.200.10, and the client has IP 192.168.200.5):

At 12.854s into the capture, the RTP timestamp wraps.
Correspondingly in the IAX trunk packet at 12.867s into the capture, the trunk timestamp is 0, and stays 0 (in the previous trunk packet the timestamp was still 10132)


Comments:By: Gerhard (gleroux555) 2013-06-19 07:30:26.346-0500

tcpdump of both RTP and IAX streams.
By: Rusty Newton (rnewton) 2013-06-25 19:02:14.377-0500

@Gerhard can you provide an Asterisk full log (VERBOSE 5, DEBUG 5, and RTP debug on) for the same scenario, with a PCAP of the call?

Thanks!
By: Gerhard (gleroux555) 2013-06-26 01:47:03.949-0500

In the log file "issue_21920_full_log", on line 1215, the rtp timestamp from voip provider wraps  [Jun 26 10:35:44]


16.086s into pcap file "rtpwrapiaxissue_logB.pcap" : the rtp timestamp wraps.
16.087s into pcap file "rtpwrapiaxissue_logB.pcap" : the iax trunk timestamp becomes and stays zero.
By: Rusty Newton (rnewton) 2013-06-26 09:59:31.488-0500

Looks like a bug to me. Thanks for the data and pointing out where the issue occurs. That is extremely helpful.

By the way? What timing interface are you using? https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

Can you also post your sanitized iax.conf and sip.conf files?

Thanks!
By: Rusty Newton (rnewton) 2013-06-26 10:05:22.600-0500

I keep coming up with more questions. Do you have a way to reproduce the timestamp wrapping with RTP, or does it just happen frequently on SIP calls to your provider?
By: Gerhard (gleroux555) 2013-06-26 10:13:19.318-0500

Hi!

1. Timing interface: When I run "timing test" inside of the CLI, it says "Using the 'timerfd' timing module for this test.".

2. Regarding the reproduction: The answer is BOTH. We get frequent wraps from our provider, and also, I have modded and compiled asterisk 1.6 on a separate box so that forces the RTP timestamp to a value high enough so that it wraps after 10 seconds. The latter setup is what I use for logging this bug, and I can reproduce the error at will.

3. I'll post the conf-files right after this.
By: Gerhard (gleroux555) 2013-06-26 10:48:59.846-0500

iax.conf and sip.conf attached.
By: Rusty Newton (rnewton) 2013-07-01 15:47:46.867-0500

Thanks again for all the info. The issue is acknowledged and is ready for a developer to look at when they are available.
By: Gerhard (gleroux555) 2013-07-03 02:43:09.249-0500

Thanks for the feedback. Any idea as to how soon this might be resolved?  And would the resolution of the issue result in a patch being issued for Asterisk 1.8.22.0? (I don't know how the process of issue resolution works)
By: Rusty Newton (rnewton) 2013-07-09 15:44:34.148-0500

@Gerhard

bq. Any idea as to how soon this might be resolved?

Nope. There are hundreds of issues in the queue and priorities jump around weekly depending on what is affecting the most people, whether issues are security related, etc.

bq.  And would the resolution of the issue result in a patch being issued for Asterisk 1.8.22.0? (I don't know how the process of issue resolution works)

A patch would be committed to trunk plus any branch where the issue occurs. You would see the patch come down into the latest release version of your branch. So that would be a 1.8.X version released after the patch was committed.

Right now a patch doesn't exist. The issue is waiting for any developer to take a look at it, when they are able. Someone could jump on it tomorrow or it could be months. If you can submit a patch, that could make things easier (depending on whether the patch is accurate to the issue and whether it has side-effects or not).
By: Gerhard (gleroux555) 2013-07-10 01:15:24.404-0500

Ok, I understand. Thanks for the feedback.
By: Alec Davis (alecdavis) 2013-07-10 04:53:51.793-0500

What I'm missing here is what is the symptom?

If I'm on the right track, the RTP RFC 3550 says that the initial value for RTP 'SHOULD' be random. So could at times start close to the max.
Thus the wrap around time for an audio call at 160 samples at 20ms rate, could be from 6.21 days (if initial timestamp = 0) down to seconds or less.

Two approaches I can see;
  1). At the source, limit the upper random value of the initial RTP timestamp to 0x7FFFFFFF, that will allow an audio call 3 days long as the minimum.
  2). On our side, we need to work in modular arithmetic (refer RFC3550 and NTP wrap around), record the initial timestamp, then work with the difference of the delivered timestamp and the initial timestamp. I think....
 
By: Gerhard (gleroux555) 2013-07-10 06:05:22.968-0500

Hi Alec,

The symptom is very bad audio, due to the (I think) iax jitterbuffer that gets trunk-timestamps that are all zero from the point of the bridged RTP stream timestamp wrapping.  Typically the client has a SIP phone registered on his pbx, and this SIP stream has very high jitter due to the IAX jitter buffer not knowing what to do with the trunk-timestamps suddenly becoming zero from a certain point in a call.

Regarding approach (1) suggested by you: We unfortunately have no way of forcing the source (an international telco) to implement something like limiting the upper random value; according to them, they are implementing an RFC correctly, and will not even consider changing their implementation to accommodate customer equipment that incorrectly handles RTP wrapping.

By: Gerhard (gleroux555) 2013-07-24 06:25:21.027-0500

Is there a way that our company can pay for support to have this issue fixed sooner?
By: Rusty Newton (rnewton) 2013-07-24 15:11:37.394-0500

@Gerhard,

[Bug Bounties|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties] are allowed on the #asterisk-dev list. Please see the wiki for more info on that.  That would probably be your best bet other than searching the web for Asterisk developers for hire.