[Serusers] LCR Backport Example For ser-0.9

Zeus Ng zeus.ng at isquare.com.au
Wed Mar 16 01:19:50 CET 2005


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
> 




More information about the sr-users mailing list