14 Jan
2003
14 Jan
'03
9:46 a.m.
Few more notes on this construct:
a it takes two servers in series; the first one in chain makes the
NAT fixing job, the other one acts as proxy/registrar; the reason is
the NAT changes to a request are only used to generate outoging request
and do not affect registrar; thus, you first need to send the updated
request out; one could still have only one server running (be it easier
or not) with a routing policy, which makes the request pass the same
server in two rounds -- first one de-natifying, the second real one
b it takes generating symmetric replies and accepting rport in relayed
replies -- I think that is a reasonable thing to add to ser core
c the routing policy needs to be set up in such a way, the de-natifying
instance of SER is always in the path -- otherwise subsequent inbound
requests would be routed based-on Contact directly to NAT, would not
use symmetric path opened by initial REGISTERs and fail;
the denatifier thus needs to use record-routing
d for the same reason, all initial inbound requests to natted users proxied
by the main server need to be statically routed to the de-natifier
-Jiri
the examples bellow demonstrate in ascii charts some more details;
A:B is address:port of natted phone, X:Y the natted A:B, C:D that of
denatifier
network setting:
fone F: A:B NAT N: X:Y proxy D proxy P
~
/------\ ~ /-------------\ /--------------\
|phone | -------->~----------->|denattifying |--------------->|registrar/ |
\------/ ~ |ser/outbound | |inbound proxy |
~ |proxy | \--------------/
\-------------/\ ^
\ /
\----> outbound /
domains
1) registers go from F, are rewritten by D and processed at P
2) INVITEs from F visit D, Contact is rewritten, rport is introduced,
request is record-routed, so that other party's request visit D too;
3) INVITEs from outside visit first P, contacts rewritten previously
by D are put in r-uri, requests are forwarded statically to D,
and D forwardes by uri to the fone F
At 06:27 PM 1/10/2003, Maxim Sobolev wrote:
On Fri, Jan 10, 2003 at 03:37:46PM +0200, Maxim Sobolev
wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
Sounds reasonably - I'll do it that way.
I am planning add a new nathelper module, which will export the
following functions:
add_rport() - insert a rport= parameter into the first Via field
fix_nated_contact() - replaces host:port in Contact field with host:port
we received this message from
add_direction_passive() - adds direction=passive option to the SDP
Then it would be possible to do the following at the very top of config
before any other REGISTER/INVITE processing:
if (method == "INVITE" || method == "REGISTER") {
if (search("User-Agent: Cisco ATA.*") {
add_rport();
if (method == "INVITE") {
add_direction_passive();
};
if (method == "REGISTER") {
fix_nated_contact();
};
};
};
Does it sound reasonably for you?
-Maxim
Thanks!
-Maxim
On Fri, Jan 10, 2003 at 02:15:11PM +0100, Jan Janak wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers On 10-01 14:32, Maxim Sobolev wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Folks,
I need an advise on how to better implement one feature, which isn't
currently present in SER. We need to allow UAs behind NAT properly
register with the registrar - by "properly" I mean that host:port portion
of URI in Contact field should not be used, but host:port the request
came from should be used instead. By definition we know that those UAs
will support symmetric SIP signalling, so that this scheme will work just
fine.
In my opinion there are two ways to do it: either add new rewritecontact*
family of functions similar to rewritehost ones. or add a new flag for
the save() function. This is where I need your help - which implementation
looks better for you (or maybe you have even some better idea), since
we are really interested in inclusion of our changes into the mainline to
reduce our local hacks.
This should be implemented as a standalone module for ser. I want to keep
registrar clean, it should not be aware of NATs. So, create a new module
for ser that will contain all the NAT traversal helper functions, the
functions will be then called from the config script.
That includes modifications of contact, adding rport to Via and so on.
regards, Jan.