No Problem Greger, I know it is stupid but I have to deal with the
financial guy and the CEO about the badwidth costs.
Here in my country is very difficult to get huge bandwidth at good price
in some places it is beacuse ADSL is the only option to do it but in
these case if you wan a Public Fixed IP you should pay an extra charge
that in the best of the case is 30% of the Bandwidth
cost.
Thak you
Alberto Cruz
Greger V. Teigre wrote:
Inline.
Well, yes
no... it's a hack. You are sending calls to many different
uris or one? And route(1) does a lookup("location")?
Then it will work if you are only sending to one uri. You see, if
your gw is NATed, a received parameter will be added to the contact
in location table. This received parameter will be used for
sending, even though the ruri is another. fix_nated_register() does
this "magic" for REGISTER.
Yes we are sending calls to different uris this means we are calling
to different PSTN numbers. It is because we are using the
"uri=~001[1-9][0-9]{9}@.*" value.
Route(1) is applying the lookup("location")
Ok, just wanted to be sure.
For
random numbers, you can then change the uri to the actual
destination uri (B-number) and the message will be forwarded to the
received ip and port. This will NOT work if the GW is not marked as
NATed in your location.
I don't understand very well this part. Could you give me an example?
UA registers from source address a.b.c.d:p, but has Contact:
user@192.168.0.10:5060
nat_uac_test("16") will detect this by checking the IP address in Via
against the source ip:port (The Via should then also have
192.168.0.10:5060).
You call fix_nated_register(), which will set an (integer) avp
"received" to a.b.c.d:p. When save() is called,
user@192.168.0.10:5060 is stored as contact, but the received avp is
also stored.
Later, a message with aor matching UA's comes in and you call
lookup("location"). The ruri is now sip:user@192.168.0.10:5060. Also,
the dst_ip and dst_port variables are set (not visible in ser.cfg)
You then call t_relay() and it will see that dst_ip and dst_port are
set and thus forward to that address instead of using the ruri.
So, the hack is that you can rewrite the ruri after lookup to whatever
the original ruri was (with the DID the GW expects) and still use
t_relay() to send to the GW's registered address... Not nice, it works
(I think!), but that's the penalty of doing such a stupid thing as
having a GW behind a NAT without static IP mapping ;-) (sorry
Alberto, no offense, but it is really hard to understand why you would
want to have a GW like that)
g-)