16 Mar
2005
16 Mar
'05
5:37 a.m.
Well, legal or not, I can't say. I agree that we shall not touch the From,
To header. But, I try to fool myself to interpret it like this. The URI part
CANNOT be changed. Adding a tag should do little harm.
From my understanding, you can't change record
route header because SER use
it to do comparison. That's why I try to hack the
From, To header. BUT, a
big BUT, don't use this method unless necessary. I've seem UA doing strict
on the rule and refuse to treat <xx(a)yy.com>;tag=1234 the same as
<xx(a)yy.com>;tag=1234;nat=yes and break the call. This is no fault to the UA.
It's just following the rule. However, it breaks my NAT handling for
re-INVITE in loose route which change media IP or port. For on hold call (IP
0.0.0.0) and re-INVITE that just change codec and not touching IP or port, I
just ignore them.
-----Original Message-----
From: Java Rockx [mailto:javarockx@gmail.com]
Sent: Wednesday, 16 March 2005 2:22 PM
To: Zeus Ng
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] LCR Backport Example For ser-0.9
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
> >
> >