asterisk users - Apr 2006 - RTP Timestamp errors

Hi list,

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


Erik

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!