[Serusers] LCR Backport Example For ser-0.9

[Zeus Ng]

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 at yy.com>;tag=1234 the same as
<xx at 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 at gmail.com] 
> Sent: Wednesday, 16 March 2005 2:22 PM
> To: Zeus Ng
> Cc: serusers at 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 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
> > >
> > >