[RTPproxy Users] Dealing with rtp streams that arrive before OK's and 183's

[john thompson]

I'm dealing with a voip carrier that has a bad  habit of sending rtp streams
a few seconds before sending the associated Session Progress sip packet or
OK packet.

As an example

0 secs --   Us ----invite---> carrier
1 secs --- Us <---rtp ringback audio --- carrier
4 secs --- Us <------Session Progress 183 -- Carrier
10 secs --- Us <-----rtp audio from destination --- Carrier
11 secs --- US <----- OK --------------- Carrier


The end result of this call is that rtpproxy queues up the 3 seconds of
audio before we get the 183, then sends it all out in a burst after the 183
arrives (and the originating client starts sending rtp), and then for the
rest of the call, the audio from the carrier to us is lagged by about a
second.  The person on the destination end talks, and the rtp proxy sends
the audio to the originating client after a 1 second delay, and this goes on
throughout the rest of the call.  There's no lag at all in the other
direction.

Is there a way to get rtpproxy to just discard any rtp packets sent before
the bridge is created instead of queuing them?  Or is there some other
solution to the lag problem?

Thanks,
John Thompson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rtpproxy.org/pipermail/users/attachments/20090811/790a195e/attachment.htm