[OpenSIPS-Users] OpenSIPS+MediaProxy mangling ACKs?

[Jock McKechnie]

On Wed, Aug 24, 2011 at 2:24 AM, Saúl Ibarra Corretgé
<saul at ag-projects.com>wrote:

> Hi,
>
>
> > Good call, Saúl.
> > I had a _lot_ of problems getting MediaProxy to work initially so I ended
> up using someone else's config.
> >
> > And this appears to be part of the problem - I'm using a config that
> works, but I don't know what it's up to. After removing all sorts of bits
> and pieces and adding stuff back I've found that if I remove the
> onreply_route that it _appears_ to work precisely as I expect it.
> OpenSIPS/MediaProxy is properly handling the media and no screwy ACKs.
> >
> > The onreply_route was:
> > onreply_route[1] {
> >         if (status =~ "(183)|(2[0-9][0-9])") {
> >                 if (client_nat_test("1")) {
> >                         fix_contact();
> >                         }
> >                 }
> >         }
> >
> > Will the removal of this cause any major issues? (The whole config is
> still here: http://pastebin.com/b2FGgTRX).
> >
>
> If you want to use the separated functions you'll need to contemplate the
> case in which the caller it not behind NAT but the callee is. Also, Is the
> callee is behind NAT you need to fix the contact header for him, and you can
> only do this in the onreply_route.
>
> Your config looks simple, so why not go for engage_mediaproxy, which will
> call use_media_proxy and end_media_session automagically? In my experience,
> cases where no NAT traversal (at the RTP level) is needed are so narrow that
> it's usually better to just do it always.
>
> Hey Saul;

Actually, I did - the issue doesn't appear to be with mediaproxy being
enabled but the nathelper doing fix_contact() twice. I've removed all of
mediaproxy - problem still occurs. If I pull the above, and leave mediaproxy
in (using engage_media_proxy() as you suggested which is, indeed, the nicer
way to deal with it;) everything works exactly as expected.

I now understand what this section does, thank you. Would it not be up to
the callee's SBC to correctly handle NAT headers for itself? (Keep in mind
these calls are being sent to VoIP carriers like Bandwidth.com and Level3,
so they should know what the heck they're doing)
Or should I rephrase: Can I not rely upon our vendors, in this case, doing
the right thing and taking the necessity for me to double-check them out...
thereby fixing whatever it is that is on crack here?

 - JP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110824/d249ea44/attachment.htm>