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
_______________________________________________ Users mailing list Users@rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/users
