You won't be able to do lookup most of the time with re-INVITE if it falls into loose_route as the R-URI may have changed to sip:user@dest.ip.address. (The same applies to case without loose route as well)
With nathelper, you can do nat_uac_test("8") to test for private address in the SDP part and do rtpproxy according. Don't think mediaproxy has this test.
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, 16 March 2005 9:03 AM To: serusers@lists.iptel.org; Juha Heinanen Subject: Re: [Serusers] LCR Backport Example For ser-0.9
Ahhh, I found my mistake, but can someone verify my thought process??
I'm using mediaproxy and I only proxy RTP streams if the caller or the callee are behind a NAT device.
So during a re-INVITE, I cannot just t_relay() the message because the RTP streams will end up at unreachable IP addresses if either SIP UA is NATed.
I can use client_nat_test("3") to test the caller's NAT settings, and for the callee I have to use lookup("location") and test my nat_flag setting.
But do I need to call revert_uri() after lookup("location") when processing re-INVITEs???
Regards, Paul
On Tue, 15 Mar 2005 16:17:38 -0500, Java Rockx javarockx@gmail.com wrote:
Yep. I agree.
But does this mean for **any** SIP message that
loose_route() returns
TRUE, I simply call t_relay() and then stop processing via a break command?
I can't remember, but I thought I ran in to some cases
where even when
loose_route() returned TRUE, I still had to do some other
processing.
Regards, Paul
On Tue, 15 Mar 2005 20:13:40 +0200, Juha Heinanen jh@tutpro.com wrote:
Java Rockx writes:
I thought I had mine right, but then I realized that some
re-INVITE > messages were not being handled properly and
calls were
being > disconnected.
you should not use or need to use lcr modules functions for re-invites. re-invites are in-dialog requests that are forwarded based on route headers.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers