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-)