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@yy.com;tag=1234 the same as xx@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@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@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@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