[Serusers] LCR Backport Example For ser-0.9

[Java Rockx]

Zeus,

Thanks for that code snippet. That works like a charm!!!!

I just hope altering the from header doesn't break something.

Thanks again.
Paul


On Tue, 15 Mar 2005 22:22:01 -0500, Java Rockx <javarockx at gmail.com> wrote:
> I did not think altering the From: header in anyway was legal.
> 
> If it is not legal, could the ;nat=yes tag be added to a Record-Route header?
> 
> Regards,
> Paul
> 
> 
> On Wed, 16 Mar 2005 14:18:46 +1100, Zeus Ng <zeus.ng at isquare.com.au> wrote:
> > 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()
> >  }
> >
> > This does work for me most of the time. However, there are odd situation
> > that this does not work.
> >
> > Zeus
> >
> > > -----Original Message-----
> > > From: Java Rockx [mailto:javarockx at gmail.com]
> > > Sent: Wednesday, 16 March 2005 12:01 PM
> > > To: Zeus Ng
> > > Cc: serusers at lists.iptel.org
> > > Subject: Re: [Serusers] LCR Backport Example For ser-0.9
> > >
> > >
> > > 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
> > > > >
> > > >
> > > >
> > >
> >
> >
>