2 May
2005
2 May
'05
11:17 a.m.
Hi all!
We've two SERs balanced via DNS-SRV, and Contacts are replicated via SIP
between the Registrars. Now I've implemented transparent NAT support,
but there's a "small" problem :o)
Let's say UAC-1 registers at SER-1, which replicates the contact to SER-2.
Outgoing calls from UAC-1 via SER-1 or SER-2 work great, and so do calls
from PSTN via SER-1 to UAC-1.
But since there's no NAT-binding for UAC-1 to SER-2, incoming calls from
SER-2 to UAC-1 can't work.
Does anybody know how to address this issue?
Thanks,
Andy
2 May
2 May
11:37 a.m.
Andreas Granig writes:
But since there's no NAT-binding for UAC-1 to
SER-2, incoming calls from
SER-2 to UAC-1 can't work.
what do you mean by "there is no nat binding"?
i have noticed that if you call fix_contact() and then t_replicate(),
t_replicate doesn't replicate the fixed request, but the original one.
perhaps someone can confirm this.
if true, t_replicate is useless if the client is behind nat and must be
replaced by t_relay or some other function.
-- juha
12:13 p.m.
Hi!
Juha Heinanen wrote:
Andreas Granig writes:
Sorry for the misunderstanding. What I meant is:
UAC-1 sends a SIP-Register to SER-1, so NAT is opened for UAC-1 <->
SER-1. But since UAC-1 doesn't send something to SER-2, NAT is never
opened between UAC-1 and SER-2, which is what I meant with "no
NAT-binding". Because of this SER-2 can't send a SIP-Request to UAC-1
because it's blocked by the NAT-device.
Andy
But since there's no NAT-binding for UAC-1 to
SER-2, incoming calls from
SER-2 to UAC-1 can't work.
what do you mean by "there is no nat binding"?
12:25 p.m.
Andreas Granig writes:
UAC-1 sends a SIP-Register to SER-1, so NAT is opened
for UAC-1 <->
SER-1. But since UAC-1 doesn't send something to SER-2, NAT is never
opened between UAC-1 and SER-2, which is what I meant with "no
NAT-binding". Because of this SER-2 can't send a SIP-Request to UAC-1
because it's blocked by the NAT-device.
yes, that indeed sounds like a problem. when contact of uac-1 is nated
and memory only, ser-2 should use ser-1's address as source address for
requests to uac-1. the other option might be to make ser-1 to send an
options request to uac-1 using ser-2's address in contact.
perhaps somebody else has better suggestions?
-- juha
12:29 p.m.
the other option might be to make ser-1 to send an options request to
uac-1 using ser-2's address in contact.
should have been "in via header".
-- juha
2:07 p.m.
Juha Heinanen wrote:
the other option might be to make ser-1 to send an
options request to
uac-1 using ser-2's address in contact.
should have been "in via header".
How would you do this best?
Since the source address and the source port have to match SER-1's
address, IMHO you can't just use an external script to perform this
directly without SER-1, because you can't bind to SER-1's address.
If you inject the OPTIONS into SER-1 via FIFO or sipsak/sipp, the
request goes thru, but SER-1 adds it's address as topmost Via, so the
response always comes back to SER-1 first. Is it possible to suppress
the insertion of the own Via-Header?
Or even better: is there a way to send the OPTIONS from inside the
SER-Config without calling or using external scripts? Don't think so
(beside writing a module)...
Suggestions?
Andy
4:31 p.m.
This is a hack, but:
You can redirect the REGISTER request to the 2nd server. SER-1 receives
a REGISTER and processes it with save_noreply(). It then redirects the
REGISTER method to the 2nd server using sl_send_reply("301", "Moved
Permamently"); The 2nd server will detect that the REGISTER has been
redirected and will generate 200 OK (a parameter in the request-uri
could be used for the detection).
If you set the expires to a short value (using max_expires parameter of
registrar module) than the user agent can keep NAT bindins open to both
servers.
Note:
1) The user agent has to support REGISTER/3xx (not all of them do)
2) I did not test this.
3) It really is a hack.
Jan.
On 02-05-2005 13:07, Andreas Granig wrote:
Juha Heinanen wrote:
the other option might be to make ser-1 to send
an options request to
uac-1 using ser-2's address in contact.
should have been "in via header".
How would you do this best?
Since the source address and the source port have to match SER-1's
address, IMHO you can't just use an external script to perform this
directly without SER-1, because you can't bind to SER-1's address.
If you inject the OPTIONS into SER-1 via FIFO or sipsak/sipp, the
request goes thru, but SER-1 adds it's address as topmost Via, so the
response always comes back to SER-1 first. Is it possible to suppress
the insertion of the own Via-Header?
Or even better: is there a way to send the OPTIONS from inside the
SER-Config without calling or using external scripts? Don't think so
(beside writing a module)...
Suggestions?
Andy
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3:26 p.m.
Jan Janak wrote:
You can redirect the REGISTER request to the 2nd
server. SER-1 receives
a REGISTER and processes it with save_noreply(). It then redirects the
REGISTER method to the 2nd server using sl_send_reply("301", "Moved
Permamently"); The 2nd server will detect that the REGISTER has been
redirected and will generate 200 OK (a parameter in the request-uri
could be used for the detection).
Nice idea, but unfortunately it isn't supported by our ATAs (Mediatrix
2102) and linphone for example. Both don't send another register to the
address given in the Contact-Header.
The only solution I currently see is Juha's idea with relaying an
OPTIONS via the second SER, but it also doesn't work because of the
Via-Header added by SER.
Isn't there a way to tell SER to NOT insert a Via when relaying the
OPTIONS request?
Andy
3:30 p.m.
This is exactly the same problem discussed in another thread on load
balancing and scalability. Klaus Darilion described a scanario for load
balancing using ser. However, we run into the same NAT issues as you have
discussed in this thread:
http://lists.iptel.org/pipermail/serusers/2005-April/018240.html
One option is to make sure that NAT bindings are open. This will be a hack
no matter what you do as long as the client does not support using SRV with
equal weigths as *concurrent* servers, i.e. the client registers with
both/all servers. I believe this is not the intention of the spec.
The other option is to always use the SER server where the client registered
for INVITEs to that client. Klaus suggested Contact manipulation and
implementation of the Path header to accomplish this. The problem is
(surprise) that such implementation can also be characterized as hacks. In
the above thread, I suggested using the following algorithm to simulate Path
in a registration server (I don't know if it will work...):
<Quote>
record_route();
if(method=="REGISTER") {
if(src_ip==server1) {
save("location_server1"); # Does save reply to Contact or to
srcip:port?
} else if(src_ip==server2) {
save("location_server2");
}
break;
}
if(INVITE for one of our clients) {
if(lookup("location_server1")){
t_relay_to_udp("outbound proxy1");
} else
if(lookup("location_server")){
t_relay_to_udp("outbound proxy2");
} else {
sl_reply("404", "User not found");
break;
}
}
Thus, faking Path by using src_ip and storing the location in different
tables.
I'm not sure how save() is implemented (where it replies).
</Quote>
Of course, you will still have dependency on a single server for all users
registered on that server. Thus, you must use a Linux HA type setup (or what
I would prefer: Let each public IP delivered by _sip SRV by the virtual IP
of an LVS-based cluster as discussed in the above thread).
Comments?
g-)
Jan Janak wrote:
This is a hack, but:
You can redirect the REGISTER request to the 2nd server. SER-1
receives a REGISTER and processes it with save_noreply(). It then
redirects the REGISTER method to the 2nd server using
sl_send_reply("301", "Moved Permamently"); The 2nd server will
detect
that the REGISTER has been redirected and will generate 200 OK (a
parameter in the request-uri could be used for the detection).
If you set the expires to a short value (using max_expires parameter
of registrar module) than the user agent can keep NAT bindins open to
both servers.
Note:
1) The user agent has to support REGISTER/3xx (not all of them do)
2) I did not test this.
3) It really is a hack.
Jan.
On 02-05-2005 13:07, Andreas Granig wrote:
Juha Heinanen wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers the other option might be to make ser-1 to send
an options request
to uac-1 using ser-2's address in contact.
should have been "in via header".
How would you do this best?
Since the source address and the source port have to match SER-1's
address, IMHO you can't just use an external script to perform this
directly without SER-1, because you can't bind to SER-1's address.
If you inject the OPTIONS into SER-1 via FIFO or sipsak/sipp, the
request goes thru, but SER-1 adds it's address as topmost Via, so the
response always comes back to SER-1 first. Is it possible to suppress
the insertion of the own Via-Header?
Or even better: is there a way to send the OPTIONS from inside the
SER-Config without calling or using external scripts? Don't think so
(beside writing a module)...
Suggestions?
Andy
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3:57 p.m.
Greger V. Teigre wrote:
The other option is to always use the SER server where
the client
registered for INVITEs to that client. Klaus suggested Contact
manipulation and implementation of the Path header to accomplish this.
I've already thought about rewriting the Contact-Header with the address
of the currently processing SER before replicating it, to force all
calls via the same SER. But this solution will work around the
redundancy won by using SRV, so it would be useless to use SRV anyway.
And I also want to avoid load balancers, heartbeat and other standby
solutions.
Andy
4:18 p.m.
Andreas Granig wrote:
Greger V. Teigre wrote:
Yes, I agree. IP-based services are often loosely coupled, making it easier
to create redundancy and scalability. The NAT-problem makes a tight
coupling...
The other option is to always use the SER server
where the client
registered for INVITEs to that client. Klaus suggested Contact
manipulation and implementation of the Path header to accomplish
this.
I've already thought about rewriting the Contact-Header with the
address of the currently processing SER before replicating it, to
force all calls via the same SER. But this solution will work around
the redundancy won by using SRV, so it would be useless to use SRV
anyway. And I also want to avoid load balancers, heartbeat and
other standby
solutions.
:-) well, I don't like standby solutions either, but I like some of the
characteristics of load balancing. If you have two data centers (using SRV
to load balance/make redundancy on the client side), and each data center is
a small LVS cluster, it is very easy to add servers to increase capacity.
Anyway, it's just two different ways of achieving the same thing. However,
SRV is not supported in all clients, so no matter where you turn there's a
downside...
I like the idea of using OPTIONS. If you find a way to solve that, it
may very well become a best practice. However, you need to make sure the
NAT binding is open before you send the INVITE from SER-2, so you either
have to continously send OPTIONS to all your clients or you have to make
sure that SER-1 sends the OPTIONS right before you send the INVITE from
SER-2, which brings you full circle: you're reliant on SER-1...
Maybe an extension to nathelper would be the way to go? Maxim added
support for sending different types of SIP messages instead of an empty UDP.
An extension to nathelper could take a flat file with IPs of your other
servers and send a series of OPTIONS messages instead of one. I have no
idea how this will impact the load on the server though.
g-)
4:50 p.m.
Greger V. Teigre wrote:
I haven't found a good documentation for building a SIP-Cluster using
LVS, but I'm looking forward to find one on onsip.org soon ;o)
Unfortunately I don't have the time to play around a little with LVS for
myself.
And I also
want to avoid load balancers, heartbeat and other standby
solutions.
:-) well, I don't like standby solutions either, but I like some of the
characteristics of load balancing. If you have two data centers (using
SRV to load balance/make redundancy on the client side), and each data
center is a small LVS cluster, it is very easy to add servers to
increase capacity. I like the idea of using OPTIONS. If you find a way
to solve that, it
may very well become a best practice. However, you need to make sure
the NAT binding is open before you send the INVITE from SER-2, so you
either have to continously send OPTIONS to all your clients or you have
to make sure that SER-1 sends the OPTIONS right before you send the
INVITE from SER-2
Well, the basic idea is to send an OPTION like the following sipp-based
template directly after receiving and replicating a REGISTER from SER-1
to UAC-1, which will send the reply back via SER-2 (assuming I get rid
of the Via-Header of SER-1):
<send>
<![CDATA[
OPTIONS sip:[service]@[remote_ip] SIP/2.0
Via: SIP/2.0/[transport] [field0]:[field1]
Via: SIP/2.0/[transport] [local_ip]:[local_port]
To: <sip:[service]@[remote_ip]:[remote_port]>
From: <sip:foo@[remote_ip]:[remote_port]>
Contact: <sip:foo@[local_ip]:[local_port]>;transport=[transport]
Call-ID: [call_id]
CSeq: 1 OPTIONS
Content-Length: 0
]]>
</send>
where field0 is the IP of SER-2, field1 the port of SER-2.
The reply from UAC-1 to SER-2 will open the NAT, and SER-2 will be able
to continuously send UDP pings for keeping the NAT opened. So SER-1 can
die now without effecting UAC-1's reachability.
That's for the theory so far :o)
Of course there are some other issues like registrations while one of
the SERs is down, so no NAT-bindings can be established, or the
NAT-bindings will time out while one SER is down, and the UACs are
unreachable for the recovered SER.
Maybe it's really time to evaluate iptelorg's SOP/SRR solution ;o)
Andy
5:57 p.m.
Greger V. Teigre writes:
I like the idea of using OPTIONS. If you find a
way to solve that, it
may very well become a best practice. However, you need to make sure the
NAT binding is open before you send the INVITE from SER-2, so you either
have to continously send OPTIONS to all your clients or you have to make
sure that SER-1 sends the OPTIONS right before you send the INVITE from
SER-2, which brings you full circle: you're reliant on SER-1...
assuming that somehow nat binding has been opened from the sip ua to
ser-2, ser-2 will automatically keep that binding open by sending the
small udp packets like it does for all clients behind nat. so you don't
need to keep on sending options or relying on ser-1 once ser-2 has got
access to the sip ua.
but may the options hack will not work at all even if we could hack the
via header, because options reply from the sip ua to ser-2 would not
necessarily come from the same source port as the register request to
ser-1. my understanding is that in case of symmetric nats, each src
ip/dst ip pair gets mapped by the nat to different source ports.
so ser-2 should somehow know to listed for the options reply even if it
didn't send the options request and then change the destination port in
its memory based location table for that sip ua. this hack would be
mother of all hacks.
Maybe an extension to nathelper would be the way to
go? Maxim added
support for sending different types of SIP messages instead of an
empty UDP.
An extension to nathelper could take a flat file with IPs of your other
servers and send a series of OPTIONS messages instead of one. I have no
idea how this will impact the load on the server though.
sending the options request could be done one way or another, but see
above.
-- juha
5:45 p.m.
Greger V. Teigre writes:
The other option is to always use the SER server where
the client
registered for INVITEs to that client.
that would be ok for load balancing but not for redundancy, i.e., if
client's ser dies, the other cannot be used as backup.
Thus, faking Path by using src_ip and storing the
location in different
tables.
if you like to do that with two proxies, i don't think you would need
two tables, since you could check if FL_MEM flag is set for the contact
and if so, forward the request to the other proxy.
Of course, you will still have dependency on a single
server for all users
registered on that server.
exactly.
Thus, you must use a Linux HA type setup (or what
I would prefer: Let each public IP delivered by _sip SRV by the virtual IP
of an LVS-based cluster as discussed in the above thread).
i need to check your thread in case you have a LVS based solution that
works.
-- juha
6:09 p.m.
Jan Janak writes:
You can redirect the REGISTER request to the 2nd
server. SER-1 receives
a REGISTER and processes it with save_noreply(). It then redirects the
REGISTER method to the 2nd server using sl_send_reply("301", "Moved
Permamently"); The 2nd server will detect that the REGISTER has been
redirected and will generate 200 OK (a parameter in the request-uri
could be used for the detection).
in addition that clients have to support 301 for register request, they
would also need to retain unknown request uri params, which many don't
do.
If you set the expires to a short value (using
max_expires parameter of
registrar module) than the user agent can keep NAT bindins open to both
servers.
nat bindings could be kept open by the small udp packets that are
automatically sent to clients behind nats by nathelper/mediaproxy
modules.
-- juha
6:17 p.m.
Jan Janak writes:
You can redirect the REGISTER request to the 2nd
server. SER-1 receives
a REGISTER and processes it with save_noreply(). It then redirects the
REGISTER method to the 2nd server using sl_send_reply("301", "Moved
Permamently"); The 2nd server will detect that the REGISTER has been
redirected and will generate 200 OK (a parameter in the request-uri
could be used for the detection).
the detection part could possibly be done without any r-uri params as
follows: before updating contact in db location table and generating
301, ser checks from db if contact has been updated "recently" and if so
it would only do memory update and would not generate 301.
-- juha
3 May
3 May
9:55 a.m.
Juha Heinanen wrote:
the other option might be to make ser-1 to send an
options request to
uac-1 using ser-2's address in contact.
should have been "in via header".
Nice idea, never thought of this before. But I see also some problems:
1. If the client is configured to use symmetric signaling, it will send
the response back to ser-1.
2. If the client sends the response back to ser-2, the port on the NAT
may be different than the port for communicating with ser-1. Thus, the
replicated location (port) stored in ser-2 will be different to the NAT
binding for ser-2.
regards,
klaus
10:09 a.m.
Klaus Darilion wrote:
Juha Heinanen wrote:
I was also surprised about the solutions like redirecting registers or
routing options via ser-2, and they look quite promising at first
glance. But unfortunately the former isn't supported by our (and a lot
of others, I fear) UACs and the latter will result in quite a big hack,
apart from the problems when one ser goes down and can't keep the nat
binding opened. And both won't scale very well IMHO.
So maybe I'll have a look at an LVS solution after all to present only
one public IP to the UACs.
Andy
should have been "in via header".
Nice idea, never thought of this before. But I see also some problems:
10:13 a.m.
Klaus Darilion writes:
2. If the client sends the response back to ser-2, the
port on the NAT
may be different than the port for communicating with ser-1. Thus, the
replicated location (port) stored in ser-2 will be different to the NAT
binding for ser-2.
yes, i figured this out too yesterday.
even if we would do what jan suggested, i.e., use 301 to make sip ua
send another register request to ser-2, location table entry for this
sip ua would be different in ser-1 and ser-2, because nat would not use
the same port for ser-1 and ser-2.
this means that if one ser goes down and comes back up again, it cannot
get its location memory populated from the other ser's location db. if
it uses its own location db, chances are high that it is not up to data
anymore and thus not all sip uas are anymore reachable via this ser.
in summary: a load balancing solution that at the same time is redundant
is not possible using the participating sers alone. some intelligent
front end help is needed and i'm not convinced yet that even that could
be done.
-- juha
11:25 a.m.
Juha Heinanen wrote:
in summary: a load balancing solution that at the same
time is redundant
is not possible using the participating sers alone. some intelligent
front end help is needed and i'm not convinced yet that even that could
be done.
What about this (maybe a special case):
I was just thinking about STUN, and AFAIK this relies on a NAT device
not matching the source IP of a datagram, so the client opens a NAT
binding to an STUN server to determine an external IP/port pair which is
filled in the Contact header. The Proxy then can also send SIP requests
to this external IP/port which is forwarded to the client by the NAT
device. Is this basically correct?
If so, it theoretically should work with transparent NAT handling on two
SERs too, if both SERs know the external IP/port of UAC-1.
I also think I know now why it didn't work for me: SER-1 got the request
from UAC-1 and stored the contact IP and the received IP in the location
table. SER-2 got the replicated register but stored SER-1's IP as
received IP:
On SER-1 (2.2.2.2 is the external IP of UAC-1, 3.3.3.3 is the IP of SER-1):
mysql root@ser> select * from location where username='018904449'\G
*************************** 1. row ***************************
username: 018904449
domain:
contact: sip:018904449@192.168.34.187:50600
received: sip:2.2.2.2:50600
expires: 2005-05-03 10:19:17
q: -1.00
callid: 1338383826(a)192.168.34.187
cseq: 2
last_modified: 20050503101557
replicate: NULL
state: NULL
flags: 1
user_agent: Linphone-1.0.1/eXosip
1 row in set (0.00 sec)
And on SER-2:
mysql root@ser> select * from location where username='018904449'\G
*************************** 1. row ***************************
username: 018904449
domain:
contact: sip:018904449@192.168.34.187:50600
received: sip:3.3.3.3:46236;transport=TCP
expires: 2005-05-03 10:19:15
q: -1.00
callid: 1338383826(a)192.168.34.187
cseq: 2
last_modified: 20050503101555
replicate: NULL
state: NULL
flags: 1
user_agent: Linphone-1.0.1/eXosip
1 row in set (0.00 sec)
My config basically looks like this (NAT-flag is "2"):
if (method=="REGISTER")
{
if(is not from Peer-SER-IP)
{
if(!search("^Contact: \*") && client_nat_test("7"))
{
setflag(2);
fix_nated_register();
force_rport();
append_hf("Natted: yes\r\n");
}
if(!www_authorize("<auth domain>", "subscriber"))
{
www_challenge("<auth domain>", "0");
break;
}
if(!check_to())
{
sl_send_reply("403", "Use To=id next time");
break;
}
consume_credentials();
if(!save("location"))
{
sl_reply_error();
break;
}
forward_tcp("<Peer-SER-IP>", 5060);
}
else
{
if(is_present_hf("Natted"))
{
setflag(2);
fix_nated_register();
force_rport();
}
save_noreply("location");
}
break;
}
I'll investigate the problem and report back here. Or do I miss
something important?
Andy
11:35 a.m.
Andreas Granig writes:
If so, it theoretically should work with transparent
NAT handling on two
SERs too, if both SERs know the external IP/port of UAC-1.
yes, but symmetric nat would not forward packets to uac from the ip
address of the other ser even if it sends them to the external ip/port
of the uac.
-- juha
12:05 p.m.
Juha Heinanen wrote:
Yes, and also (port-)restricted cone NAT won't work...
UPnP isn't widespread enough and cascading NAT won't work too (just want
to be shure to take into account all possibilities ;o) )
Ok, so the conclusion is to use a clustered solution with one public IP
and some kind of heartbeat.
Well, thanks for the insights anyway.
Andy
If so, it
theoretically should work with transparent NAT handling on two
SERs too, if both SERs know the external IP/port of UAC-1.
yes, but symmetric nat would not forward packets to uac from the ip
address of the other ser even if it sends them to the external ip/port
of the uac.
12:05 p.m.
It boils down to the following: For the 'OPTIONS with manipulated via' idea
to work, we need to make sure that:
a) SER-1 and SER-2 keeps separate location for UACs because symmetric NATs
will give you IP:port1 and IP:port2 as NAT ports
b) The only way to establish a NAT binding in a symmetric NAT is for the UAC
to send a UDP packet to both SER-1 and SER-2, and each SER needs to store
this info
c) NAT bindings need to be kept open, but each SER can do this for its "own"
UACs using nathelper or mediaproxy's ping functionality
- So, if UAC-1 registers with SER-1, SER-1 should send an OPTIONS message to
UAC-1 with SER-2 in Via (as noted earlier, if UAC-1 responds to received
IP:port, this will not work, but let's assume we can control this).
- SER-2 should receive a replication from SER-1 and store the user and
location
- SER-2 should recognize the OPTIONS message as a location update to the
registration and change UAC-1's location in its own database with the
received IP:port from UAC-1's message. This should be encapsulated like
this:
if(method=="OK" && search("detect that this is a location
update")) {
if(!registered("location")) {
reply("Fake!!");
} else {
save_noreply("location");
}
}
- Of course, the registration on SER-1 must include sending the faked via
OPTIONS message to UAC-1.
- And, as Juha pointed out, the databases are now out of sync and a server
that goes down cannot get the database from another. But unless it is
possible to match interface IP with the location for each UAC (so that
multiple interface IP/location pairs can be stored), I cannot see a way to
get around this.
Anything I have forgotten?
I have been in dialog with the maintainer of IPVS (LVS load scheduler) with
regards to a call-id scheduler (similar to F5/Cisco). So far it seems
promising, but somebody must implement a UDP scheduler with payload parsing.
g-)
Juha Heinanen wrote:
Andreas Granig writes:
If so, it theoretically should work with
transparent NAT handling on
two SERs too, if both SERs know the external IP/port of UAC-1.
yes, but symmetric nat would not forward packets to uac from the ip
address of the other ser even if it sends them to the external ip/port
of the uac.
-- juha
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:18 p.m.
Andreas Granig wrote:
Juha Heinanen wrote:
That's fine. There is no problem with STUN-traverseable NATs. But there
are problems with symmetric NAT and restricted NAT.
in summary: a load balancing solution that at the
same time is redundant
is not possible using the participating sers alone. some intelligent
front end help is needed and i'm not convinced yet that even that could
be done.
What about this (maybe a special case):
I was just thinking about STUN, and AFAIK this relies on a NAT device
not matching the source IP of a datagram, so the client opens a NAT
binding to an STUN server to determine an external IP/port pair which is
filled in the Contact header. The Proxy then can also send SIP requests
to this external IP/port which is forwarded to the client by the NAT
device. Is this basically correct?
If so, it theoretically should work with transparent NAT handling on two
SERs too, if both SERs know the external IP/port of UAC-1. I also think I know now why it didn't work for me:
SER-1 got the request
from UAC-1 and stored the contact IP and the received IP in the location
table. SER-2 got the replicated register but stored SER-1's IP as
received IP:
True, ser-2 does not use fix_... for REGISTERs received from ser-1.
regards,
klaus
2 May
2 May
12:05 p.m.
andreas,
i tested again and calling t_replicate after calling fix_contact did
sent out the fixed register request.
what was the problem you had?
-- juha
3 May
3 May
10 a.m.
Juha Heinanen wrote:
andreas,
i tested again and calling t_replicate after calling fix_contact did
sent out the fixed register request.
what was the problem you had?
AFAIK fix_contact makes problems with clients which likes to see the
Contact header unmodified. Thus, fix_nated_register() is more suitable.
But this does not change the replacted message. Thus, is this logic
possible?
if (REGISTEER && NATed) {
fix_nated_register
save
fix_contact
t_replicate
}
regards,
klaus
7149
days inactive
7150
days old
26 comments
5 participants
participants (5)
-
Andreas Granig -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Klaus Darilion