[OpenSIPS-Users] mediaproxy/rtpproxy problem with reinvites
Jeff Pyle
jpyle at fidelityvoice.com
Fri Oct 31 03:28:43 CET 2008
Hello,
I'm making progress on my OpenSER 1.3.2 to OpenSIPS 1.4.x upgrade. The
catalyst for the upgrade was to diagnose an OpenSER/Mediaproxy 1.8
problem where media was bouncing all over the place. Here is the
original issue (no NAT unless specified):
An Asterisk box sends and INVITE to OpenSER. OpenSER looks it up and
finds it belongs to a NATed user. It statefully forwards the INVITE...
the call sets up normally. Mediaproxy has been invoked because of the
callee's NATed condition. Immediately after the call sets up, Asterisk
issues a re-INVITE to allow the caller and the callee to exchange RTP
directly. Well, almost, with the Mediaproxy involved. All the INVITES
and 200s and ACKs are exchanged correctly.
Now, the weird part. The callee's RTP is hitting Mediaproxy and
forwarding directly to the caller. This is correct. The caller's audio
is hitting Mediaproxy, but Mediaproxy is forwarding it to the Asterisk
box, not to the callee. The Asterisk box then in turn forwards it back
to the caller. So at this point the caller is receiving both the
callee's audio and his own. And the callee hears nothing.
That was the original issue. I attempted to upgrade to OpenSIPS +
Mediaproxy 2.1, only to find gobs of gnutls library dependencies I
couldn't knowledgably satisfy on Fedora 7. Ok, so I rework the route
script for nathelper/rtpproxy. After several days of educational
frustration, I am to this point: The original scenario appears to work
properly. But, if the caller comes from one of my PSTN carrier
partner's gateways, the funkiness returns. Sometimes. I've been able
to get a network capture (including media) of a good call and a bad
call. The only difference I see is that in the good call, the Asterisk
box squeaks through a single RTP packet to rtpproxy before the 200 OK to
its reinvite comes in from the NATed callee.
How *should* rtpproxy/mediaproxy handle reinvites? I only got this far
by using unforce_rtp_proxy, then force_rtp_proxy on a loose-routed
INVITE w/ SDP (in other words a reinvite). Should that be necessary?
Might the "s" swap flag be helpful in this scenario somewhere?
A simple solution would be to disable the reinvites on Asterisk, but
that doesn't scale well enough for my application.
Does anyone know of any resources they might be able to point me
towards?
Thanks,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20081030/c0fdb84c/attachment.htm
More information about the Users
mailing list