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

[Greger V. Teigre]

:-) Thanks for enlightening me, Alberto. Sometimes one has to work under 
less-than ideal conditions. I hope you figure it out!
g-)

Alberto Cruz wrote:
> 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 at 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 at 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 at 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-)
>>
>
>