[Home]

Summary:ASTERISK-06749: [patch] outgoing RTP stream has a big timestamp gap after Asterisk recieves a reinvite on the other leg
Reporter:E. Versaevel (erikje)Labels:
Date Opened:2006-04-11 01:24:06Date Closed:2006-05-11 04:07:13
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.2.6-rtp-timestamp-20060415.patch
Description:As requested by Kevin P Fleming, i allso report this to the buglist:

I know * generates it's outgoing RTP stream based on the incomming RTP stream, i'm having some audio problems after i recieve an rtp reinvite from my
carrier.

Situation:

Phone -- Asterisk A --- Asterisk B --- Carrier --- PSTN

Asterisk A: reinvite = no
Asterisk B: reinvite = no

If i dial out on phone via asterisk A, Asterisk B relay's the INVITE to the carrier, after the PSTN answers the call the carrier sends a reinvite to
Asterisk B to change the ip to one of the the Media Gateways of the carrier, the media gateway however sends RTP with a completely different timestamp
to Asterisk B, so Asterisk B copies that timstamp and Asterisk A gets an audio hickup.

IE

asterisk B recieves:                                           asterisk B sends to A
sequence 1 timestamp  0 SSRC 1234 from ip 1.2.3.4              sequence 1 timestamp 0 SSRC 4321 from ip Asterisk B
sequence 2 timestamp 30 SSRC 1234 from ip 1.2.3.4              sequence 2 timestamp 30 SSRC 4321 from ip Asterisk B
sequence 3 timestamp 60 SSRC 1234 from ip 1.2.3.4              sequence 3 timestamp 60 SSRC 4321 from ip Asterisk B

so far, so good, but then Asterisk B recieves a reinvite from the carrier and start to send this rtp to Asterisk A

sequence 500 timestamp 500000 SSRC 5678 from ip 1.2.3.4              sequence 4 timestamp 500000 SSRC 1234 from ip Asterisk B
sequence 501 timestamp 500030 SSRC 5678 from ip 1.2.3.4              sequence 5 timestamp 500030 SSRC 1234 from ip Asterisk B
sequence 502 timestamp 500060 SSRC 5678 from ip 1.2.3.4              sequence 6 timestamp 500060 SSRC 1234 from ip Asterisk B

IMHO Asterisk B should change it SSRC to tell Asterisk A the RTP source has changed (and fix this timestamp gap)?


Kevin replied:
Erik wrote:


>> IMHO Asterisk B should change it SSRC to tell Asterisk A the RTP source has changed (and fix this timestamp gap)?

That's an interesting question; since Asterisk is not actually a proxy,
in point of fact the SSRC has _not_ changed, since Asterisk B is still
the source of the RTP stream headed to Asterisk A.

However, I can see some value in the RTP stack noticing that the SSRC
has changed and sending some sort of 'control frame' through the
Asterisk core notifying the other channel(s) of the intentional
timestamp discontinuity... I don't think anyone has identified this
problem and offered any solution previously, though, so we'll need to
see if we can make some time to get this resolved during this release
cycle. Please open a report on our bug tracker with these details (and
my reply) so we won't lose track of it... thanks!
Comments:By: E. Versaevel (erikje) 2006-04-11 07:22:16

Woh, it gets even better :)


Got RTP packet from 212.29.174.81:15864 (type 8, seq 16050, ts 12480, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16051, ts 12640, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16052, ts 12800, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16053, ts 12960, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16054, ts 13120, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16055, ts 13280, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16056, ts -697163040, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16057, ts -697162880, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16058, ts -697162720, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16059, ts -697162560, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16060, ts -697162400, len 160)
Got RTP packet from 212.29.174.81:15864 (type 8, seq 16061, ts -697162240, len 160)
By: E. Versaevel (erikje) 2006-04-11 08:47:18

According to RTP by Colin Perkings (ISBN: 0672322498) and i quote:

"The timestamp is derived from a media clock that must increase in a liniar and monotonic fasion... the RTP timestamp must form a continuous sequence and must not be reset.. this show that an RTP reciever cannot tell from te rtp headers that a change has occurred."

Asterisk B is informed of the new media session, Asterisk A however has 1 continuous RTP session with Asterisk B and should recieve a linear increasing timestamp.
By: Kevin P. Fleming (kpfleming) 2006-04-11 15:15:37

That's actually a bigger issue... and much harder to implement. What does the RFC say about SSRC changing in the middle of a session?
By: E. Versaevel (erikje) 2006-04-12 05:15:55

I did notice that Asterisk genereates a continous stream of sequence numbers, so generating timestamps shouldn't be that hard i think. About changing SSRC, i don't think that a good idea, as the SSRC (ie the rtp source for asterisk A) isn't changed.
By: Jorrit Kronjee (jorrit at infopact nl) 2006-04-28 02:30:20

I've uploaded a patch that should fix the problem with changing SSRC fields. Right now, as far as I can see, asterisk doesn't take the SSRC into account. However, I do want to stress that I see this patch as a quick fix and not as a structural change.
By: Serge Vecher (serge-v) 2006-05-03 10:23:03

jorrit: do you have a disclaimer on file with Digium? If not, can you please file one -- see bug guideliness for how to do that...

Thanks.
By: Jorrit Kronjee (jorrit at infopact nl) 2006-05-04 08:44:32

I've just faxed a disclaimer to the fax no. as mentioned in the guidelines.
By: Serge Vecher (serge-v) 2006-05-04 09:03:47

thanks!
By: Serge Vecher (serge-v) 2006-05-10 15:28:32

erikje: please test the attached patch and report if it fixes the issue. Thanks!
By: E. Versaevel (erikje) 2006-05-11 02:16:26

vechers, i'm a collegue of Jorrit
By: Mark Spencer (markster) 2006-05-11 03:48:04

Fixed in SVN trunk #26759.  Thanks!
By: Kevin P. Fleming (kpfleming) 2006-05-11 04:07:12

Backported to 1.2 as well.