Klaus,

Thanks. You're right, I don't think mediaproxy has any such test. Anyhow, late last night I was discussing this with Zeus Ng and he shared his code with how he handles this.

Here is verbatim, what he told me. It seems to work, but I hope it doesn't break anything.

Regards, Paul

How about something like this.

With the initial INVITE,

... Route processing ... if (caller is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); }

call nathelper or mediaproxy

t_on_reply(nat reply route); t_relay();

In your reply route,

if (callee is natted) { subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/'); call nathelper or mediaproxy ... Other processing ...

In your loose route,

if (loose_route()) { if (method=="INVITE") { if (search("my_ser_detect_nat=yes") || (sdp in private address )) { call nathelper or mediaproxy } } on reply route t_relay() }

On Wed, 16 Mar 2005 15:25:35 +0100, Klaus Darilion klaus.mailinglists@pernau.at wrote:

Hi Paul!

If you use the nathelper module, you can use force_rtpproxy with the 'l' parameter. Check nathelper.c for documentation.

I don't know if there is an equivalent feature in the mediaproxy module.

regards, klaus

Java Rockx wrote:

...

Hi All.

I'm using ser-0.9.1.

Is there a way to determine if mediaproxy is in use for an existing SIP call so that re-INVITE messages can avoid losing audio when one or the other SIP UAs are NATed?

We do not proxy RTP streams unless one or more SIP UAs are NATed. But on re-INVITE messages I cannot figure out how to test the destination of the re-INVITE for the UAs NAT status.

I've scoured the archives and found a few related articles http://lists.iptel.org/pipermail/serdev/2004-March/001515.html http://lists.iptel.org/pipermail/serusers/2004-March/006806.html

But nothing has led me to a solution. I cannot just use lookup("location") and test the nat_flag since that won't always work on re-INVITEs. A mediaproxy function for something like is_existing_session() would be awesome to lookup the Call-ID in the existing mediaproxy sessions.

What am I missing?

Regards, Paul

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hello,

Andreas Sikkema wrote:

What I've seen is, is that this is a bug/feature in the mediaproxy itself where a new INVITE will be ignored on an existing call. I've fixed this on our development proxy a long time ago and can't remember how much I had to fix.

We had this problems especially for handling codec switches, for example from G.729/G.711 to T.38 and back, and also for conditional call forwards, where the second INVITE had another destination IP for RTP.

I posted a fix some time ago, see http://lists.iptel.org/pipermail/serdev/2004-October/002991.html Sorry, never got concrete feedback from ag-projects about this.

But note that we've faced some other problems, especially for T.38: Mediaproxy waits for RTP packets from both parties before starting to relay the traffic, but in T.38 the receiver only answers when it gets some T.38 traffic, so we had to force the forwarding of RTP packets in rtphandler.py:handle_read() to the visible IP of the other party before that one could sign in.

Hope this helps, Andy