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

Greger V. Teigre

11 Jul 11 Jul

4:49 p.m.

You mean the GW registers itself with your SER server?! If that is the case, just rewrite the uri to the aor of the gw (the sip uri it registers with) and then do lookup("location") g-) Alberto Cruz wrote:

...

Hi guys maybe this have been asked before. I have the following: * I have an ADSL Internet access with a public dynamic IP. * I have a broadband router in order to share the Internet access using NAT. * I have a VoIP GW that supports register connected behind the NAT. When the GW registers itself SER knows its source IP and UDP port. Does anybody knows how to forward the PSTN calls to the GW when it is behind a NAT? Regards Alberto Cruz _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Reply

Greger V. Teigre

4:56 a.m.

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. 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. This is a very bad hack for something that should be a simple thing. If the GW is behind a NAT with a static IP (I hope!) and the NAT allocation is static, you can rewritehostport("201.133.85.16:5060") as if the GW is public. Make any sense? g-) Alberto Cruz wrote:

...

Yes the GW registers itself with my SER server. According to your tip I have the following: My GW is registered at location as ~~~Contact(0x404c54c0)~~~ domain : 'location' aor : '5527350900' Contact : 'sip:5527350900@201.133.85.162:5060' Expires : 761 q : Call-ID : 'E1A37F8C-2BE711D6-8020EB34-A0107B2E' Do you mean I could have the following block at my ser.cfg: if ((uri=~"sip:001[1-9][0-9]{9}@.*")) { rewriteuri("sip:5527360900@mysipdomain"); avp_write("i:45", "inv_timeout"); route(1); break; }; And it's all? Regards Alberto Cruz Greger V. Teigre wrote:

You mean the GW registers itself with your SER server?! If that is the case, just rewrite the uri to the aor of the gw (the sip uri it registers with) and then do lookup("location") g-) Alberto Cruz wrote:

Hi guys maybe this have been asked before. I have the following: * I have an ADSL Internet access with a public dynamic IP. * I have a broadband router in order to share the Internet access using NAT. * I have a VoIP GW that supports register connected behind the NAT. When the GW registers itself SER knows its source IP and UDP port. Does anybody knows how to forward the PSTN calls to the GW when it is behind a NAT? Regards Alberto Cruz _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Reply

Greger V. Teigre

14 Jul 14 Jul

7:24 p.m.

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

Reply

Greger V. Teigre

16 Jul 16 Jul

7:39 p.m.

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

Reply