[Serusers] How to send PSTN CALLs to a NATED PSTN GW?

Alberto Cruz acruz at tekbrain.com
Fri Jul 14 20:00:49 CEST 2006

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

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 at
> 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 
> You call fix_nated_register(), which will set an (integer) avp 
> "received" to a.b.c.d:p.  When save() is called, 
> user at 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 at 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-)

More information about the sr-users mailing list