Hi,
I have set up the SER and its working. The only problem is I cant get the routing logic to simultaneously route to either the User Loc or the PSTN. Its only doing one of the other.
I am new to SIP, can u show me a sample script that will do both at the same time?
Best regards,
Phillip
Hi,
This is an example, one of the many scripts I've written over the last several months. Many of these parts have been copied from the iptel.org example, which is very good for learning.
It will route to REGISTERed phones and to PSTN numbers. If you forward your PSTN gateway to this server, it will route incoming PSTN calls as well. This script does authentication with the user agents. It also does accounting, call INVITE and BYE to syslog.
---greg
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/exec.so" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/textops.so"
modparam("usrloc","db_mode",2) modparam("usrloc","db_url", "sql://ser:xxxxxx@localhost/ser")
modparam("acc", "log_level", 1) modparam("acc", "acc_flag", 1 ) modparam("auth","db_url", "sql://ser:xxxxxx@localhost/ser")
# # this is the main routing block for augustvoice.net # this block can handle any routing request, local or foreign #
route { # # check to see if the message has been around too long # probably means that it is looping # if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Too Many Hops"); break; };
# # make sure the length of the message isn't too long! # if (len_gt( max_len )) { sl_send_reply("513", "Wow -- Message too large"); break; };
# # rewrite the From stuff # rewriteFromRoute();
if (method=="REGISTER") { route(1); break; };
if(method=="INVITE" | method=="BYE") { setflag(2); };
# now check if it's about PSTN destinations through our gateway; if (uri=~"sip:[0-9]{10}@.*") { route(3); break; };
# now check if it's about LD PSTN destinations through our gateway; if (uri=~"sip:1[0-9]{10}@.*") { route(3); break; };
# check for native destinations if (lookup("location")) { log(1,"found location"); };
if(isflagset(2)) { log(1,"TRACE: addRecordRoute()"); addRecordRoute(); };
# turn on local delivery accounting if(method=="INVITE" | method=="BYE") { log(1,"TRACE: turn on accounting for INVITE or BYE"); setflag(1); };
append_hf("P-hint: USRLOC\r\n"); if(!t_relay()) { sl_reply_error(); break; }; }
# # route[1], REGISTER block # REGISTER messages destined for our realm are forwarded here. # after a successful registration a customer can receive calls. # route[1] { if(!www_authorize("augustvoice.net", "subscriber")) { www_challenge("augustvoice.net", "0"); break; };
# if(!check_to()) # { # log("LOG: To Cheating attempt\n"); # sl_send_reply("403","That is ugly -- use To=id next time"); # break; # };
log("here is a register"); if(!save("location")) { sl_reply_error(); }; break; }
# # route[2], offnet requests # route[2] { log(1,"TRACE:In route[2]"); if(!(src_ip==PSTN.GATEWAY.IP.ADDRESS) & !(proxy_authorize("augustvoice.net","subscriber"))) { log(1, "source ip is PSTN.GATEWAY.IP.ADDRESS"); if(method=="ACK") { log("LOG: failed outbound authentication for ACK\n"); } else if(method=="CANCEL") { log("LOG: failed outbound authentication for CANCEL\n"); } else { proxy_challenge("augustvoice.net","0"); break; }; } else { log(1, "NOT from IP address PSTN.GATEWAY.IP.ADDRESS"); }; }
# route[3], logic for calls to the PSTN route[3] { log(1,"TRACE:In route[3]");
if(!(src_ip==PSTN.GATEWAY.IP.ADDRESS | method=="ACK" | method=="CANCEL" | method=="BYE")) { if(!www_authorize("augustvoice.net","subscriber")) { www_challenge("augustvoice.net","0"); break; } # let's check from=id ... avoids accounting confusion else if (method=="INVITE" & !check_from()) { log("LOG: From Cheating attempt\n"); sl_send_reply("403", "That is ugly -- use From=id next time (gw)"); break; }; };
# we passed all authorization checks for PSTN -- move on! # tag this transaction for accounting setflag(1);
# requests to gateway must be record-routed because the GW accepts # only reqeusts coming from our proxy if (isflagset(2) || method=="INVITE" || method=="BYE") { addRecordRoute(); };
# if you have passed through all the checks, let your call go to GW!
rewritehostport("PSTN.GATEWAY.IP.ADDRESS:5060");
append_hf("P-hint: GATEWAY\r\n"); if (!t_relay()) { sl_reply_error(); break; }; } -----------------cut---------------
-----Original Message----- From: serusers-admin@iptel.org [mailto:serusers-admin@lists.iptel.org] On Behalf Of Phillip Haynes Sent: Thursday, January 30, 2003 2:57 PM To: serusers@lists.iptel.org Subject: [Serusers] Routing to the PSTN
Hi,
I have set up the SER and its working. The only problem is I cant get the routing logic to simultaneously route to either the User Loc or the PSTN. Its only doing one of the other.
I am new to SIP, can u show me a sample script that will do both at the same time?
Best regards,
Phillip
I'm trying to forward to a VOIP gateway hosted by Nikotel. They are keying on the @domain in the to-uri. I cannot get the to-uri to rewrite to their domain. What is the trick? I just got off the phone with someone at Nikotel and they said that iptel is working with their gateway.
Another similar question. My setup works by: 1) My customer sends an invite for 9725551212@mydomain.com 2) I authenticate with my customer with www-authorize 3) I forward the packet using least cost routing, normally to an external sip gateway. Hoever, the SIP INVITE request that I'm forwarding has become polluted with my authentication with my customer. Is there some way to remove that authentication from the INVITE before relaying to SIP PSTN gateway? 4) Is there someway to change the To: uri to be 9725551212@SIPGATEWAY.com???
---greg Greg Fausak
Greg, comments inline.
On 30-01 16:16, Greg Fausak wrote:
I'm trying to forward to a VOIP gateway hosted by Nikotel. They are keying on the @domain in the to-uri. I cannot get the to-uri to rewrite to their domain.
To URI cannot be rewritten. Only Request URI can be changed. Proxy is not supposed to touch To header URI because it must not change.
What is the trick? I just got off the phone with someone at Nikotel and they said that iptel is working with their gateway.
What exactly is the problem ? Do you have some ngrep dump of the message exchange with the gateway ? Could you provide us with more details ?
Another similar question. My setup works by:
- My customer sends an invite for 9725551212@mydomain.com
- I authenticate with my customer with www-authorize
- I forward the packet using least cost routing, normally to an external sip gateway. Hoever, the SIP INVITE request that I'm forwarding has become polluted with my authentication with my customer. Is there some way to remove that authentication from the INVITE before relaying to SIP PSTN gateway?
Yes, there is function consume_credentials in auth module which removes the authorized credentials. What version of ser do you have ? If I recall correctly there was a bug in the function in older versions, I will send you a patch if necessarry.
regards, Jan.
Jan,
Greg, comments inline.
On 30-01 16:16, Greg Fausak wrote:
I'm trying to forward to a VOIP gateway hosted by Nikotel. They are keying on the @domain in the to-uri. I cannot get the to-uri to rewrite to their domain.
To URI cannot be rewritten. Only Request URI can be changed. Proxy is not supposed to touch To header URI because it must not change.
What is the trick? I just got off the phone with someone at Nikotel and they said that iptel is working with their gateway.
What exactly is the problem ? Do you have some ngrep dump of the message exchange with the gateway ? Could you provide us with more details ?
Well, the problem was that the nikotel gateway was using the to uri, and the to uri had to match theirs.
Now I am getting 'proxy required' messages. While I was writing this That was fixed, now I'm struggling with another problem, but it looks Like I don't need to change the to--uri anymore.
Another similar question. My setup works by:
- My customer sends an invite for 9725551212@mydomain.com
- I authenticate with my customer with www-authorize
- I forward the packet using least cost routing, normally to an external sip gateway. Hoever, the SIP INVITE request that I'm forwarding has become polluted with my authentication with my customer. Is there some way to remove that
authentication
from the INVITE before relaying to SIP PSTN gateway?
Yes, there is function consume_credentials in auth module which removes the authorized credentials. What version of ser do you have ? If I recall correctly there was a bug in the function in older versions, I will send you a patch if necessarry.
My version is ser-0.8.10, which has the consume credentials call. I tried it and it works perfectly. I remember seeing this in the README In the modules directory, I just forgot...Thanks,
---greg
regards, Jan.
At 11:16 PM 1/30/2003, Greg Fausak wrote:
I'm trying to forward to a VOIP gateway hosted by Nikotel. They are keying on the @domain in the to-uri. I cannot get the to-uri to rewrite to their domain. What is the trick? I just got off the phone with someone at Nikotel and they said that iptel is working with their gateway.
Well, I would personally not recommend to use "To" for some call-processing decisions -- request uri is thought for that purpose and has great flexibility which To does not have for many reasons.
Another similar question. My setup works by:
- My customer sends an invite for 9725551212@mydomain.com
- I authenticate with my customer with www-authorize
- I forward the packet using least cost routing, normally
to an external sip gateway. Hoever, the SIP INVITE request that I'm forwarding has become polluted with my authentication with my customer. Is there some way to remove that authentication from the INVITE before relaying to SIP PSTN gateway?
consume_credentials should be able to remove verified credentials.
- Is there someway to change the To: uri to be
9725551212@SIPGATEWAY.com???
Generally, everything is doable, the question is whether it would not be better to make the company change its mind, and use r-rui (rather than creating some patchwork.)
-jiri
That's a matter of creating a reasonable numbering plan. You need to distinguish between PSTN destinations and IP destnations in URIs for your domain. For example, you may wish to reserve usernames beginning with "9" for PSTN and everything else for user location.
if (uri=~"sip:9[0-9]*foo.bar"){ # destinations beginning with 9 go to a gateway strip(1); seturihost("gateway.foo.bar"); } else { # everything else is searched in user location table # if not found, return 404 and stop if (!lookup("location")) { sl_send_reply("404", "user offline"); break; } # the contact from user location database will be used otherwise }; # whether we put gateway or something from user location database in current # uri, forward to it now t_relay();
-jiri
At 09:57 PM 1/30/2003, Phillip Haynes wrote:
Hi,
I have set up the SER and its working. The only problem is I cant get the routing logic to simultaneously route to either the User Loc or the PSTN. Its only doing one of the other.
I am new to SIP, can u show me a sample script that will do both at the same time?
Best regards,
Phillip
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan writes:
That's a matter of creating a reasonable numbering plan. You need to distinguish between PSTN destinations and IP destnations in URIs for your domain. For example, you may wish to reserve usernames beginning with "9" for PSTN and everything else for user location.
or use enum.
-- juha