On 6/21/2010 5:51 AM, Stanisław Pitucha wrote: > I've done some experiments with the asymmetric setup in rtpproxy and I > see some issues with the way it works when the server starts writing the > rtp before it accepts the call itself. > > Due to the fact rtpproxy reads only the sockets it monitors, it will > queue up some packets even if it should not care about them (or should > relay immediately, depending on the config. For example if the calling > side advertises (through the proxy) that it waits on IP1:PORT1, proxy > relays IP_PROXY:PORT_PROXY. The destination sends the packet DATA1 to > that address, but it's not forwarded yet (not even received - it stays > in the socket buffer). > Then the callee advertises it's own IP2:PORT2, and sends another packet > DATA2. The rtpproxy sees a complete session now and starts relaying the > stream -- and it relays both DATA1 and DATA2. > It doesn't really matter for one or two packets, but for some reason > some PBXes work like that and customers are complaining that they can > get up to 5 seconds of buffered ringing in 2-3ms spacing just as soon as > the call is accepted by the other side - which then the phones actually > accept and start playing out in some cases (or it just trashes their > jitterbuffer for some time). > > I've tried to start discarding the packets, but so far rtpproxy seems > quite confusing:) > > It can be verified with a quick test - here's the source file: > http://bitbucket.org/viraptor/rtpp_test/src/9fb3818963b5/rtpproxy_test.py > > If you run it against rtpproxy running on udp:127.0.0.1:9999, the > test_relay_rtp_asymmetric will fail. It expects the first pair.recv1() > to fail (channel not completely constructed yet) and then to receive the > first packet sent*after* the channel is ready (i.e. `data2`). The > `data1` packet is expected to be discarded. > > Are you planning to fix that behaviour, or is it a "feature"?
I would say it's issue with those PBXes, that start generating RTP way before before sending 200 OK or 183 Session Progress. In the perfect word I'd suggest fixing that instead. However, we don't live in the perfect world, so that I understand the need for some solution to address this issue. > Actually, it wasn't that bad to change. I've forked your repo on github > for this commit: > http://github.com/viraptor/RTPproxy/commit/993c4f7f5f18b2bbe19229e660d06b4ecb3171f5 > > I hope you can include in the main release if it works for you :) Well, while this change could work for your case, but I think it throws baby along with water. Current non-dequeue behavior is intended to compensate for the signaling propagation delays, when UAS sends back SDP and starts emitting RTP immediately. The SDP could be delayed a little bit (processing delays here and there, etc), so that if we discard RTP we could end up loosing first 1-2 seconds of conversation. Better option is to relay this media back to the UAC, but in the presence of NAT this media is likely to be discarded there anyway since UAC has not started sending RTP and therefore hole on the NAT is not open yet. Therefore, more "correct" workaround would be to remove "if (sp->complete != 0)" check and let RTPproxy to relay this media instead of discarding it. Proper fix would probably entail dequeuing packets from the socket buffer and storing them in some kind of temporary queue, either discarding them or forwarding to the UAC after they have been there for certain amount of time (i.e. 0.2-0.5 second). This would provide proper SDP delay compensation without screwing UAC's jitter buffer in the cases like yours. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: [email protected] Skype: SippySoft _______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
