16 Mar
2005
16 Mar
'05
2 a.m.
OK, but there are two sides of the conversation to test here for NAT.
Should nat_uac_test("8") be used in a reply_route or something?
(Actually this won't work because the re-INIVITE would need to have
the c= field in the SDP rewritten if the destination is NATed).
Anyhow, I mean if the original INVITE is from a NATed client, then I
can use client_nat_test() but on the destination side, I still need to
know if RTP proxying is needed.
How do I do this?
Regards,
Paul
On Wed, 16 Mar 2005 11:19:50 +1100, Zeus Ng <zeus.ng(a)isquare.com.au> wrote:
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(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx
Sent: Wednesday, 16 March 2005 9:03 AM
To: serusers(a)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(a)gmail.com> wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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(a)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