[Serusers] LCR Backport Example For ser-0.9

[Java Rockx]

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 at 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 at 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 at lists.iptel.org
> > [mailto:serusers-bounces at lists.iptel.org] On Behalf Of Java Rockx
> > Sent: Wednesday, 16 March 2005 9:03 AM
> > To: serusers at 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 at 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 at 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 at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> >
> 
>