16 Mar
2005
16 Mar
'05
5:01 a.m.
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(a)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(a)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@gmail.com]
Sent: Wednesday, 16 March 2005 12:01 PM
To: Zeus Ng
Cc: serusers(a)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(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:
> > 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
> > >
> >
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>