Using checkval for Call Routing with Sippy B2BUA
Hello, i am using FreeRadius 1.1.3 and want to use it for Call Routing. The Sippy B2BUA will send AAA Requests to RADIUS and i want the routing based on the Called-Station-Id Attribute. For the beginning i would like to configure the routes in the users-File and later switch to an sql backend. This is my users-File: b2b Called-Station-Id == 555,Called-Station-Id == 557,Auth-Type := Accept h323-ivr-in = 'Routing:12345@192.168.1.1;expires=30;Codecs:alaw,g.726' b2b Called-Station-Id == 556,Called-Station-Id == 558,Auth-Type := Accept h323-ivr-in = 'Routing:12345@192.168.1.2;expires=30;Codecs:alaw,g.726' The Calls will always come from the same user and the called number will have to decide what SIP Server to use. If i have only one Called-Station-Id in the check pairs line, i get the Access-Accept with the reply data. But since one route can have a lot of numbers i need to be able to have several Called-Station-Id Entrys. From the description of the checkval attribute it appeared to me the correct solution. Apart from this the different number ranges are conncected to different end users, which i have to find. This will be an accounting issue. How can this be solved with Freeradius ? The real user is not known when the INVITE reaches Sippy. Sippy sends the request to Freeradius with a lot of information, from which Called-Station-Id will indicate what SIP Server to use and what End User is associated with the call. Just want to clarify the whole procedure: I have several incoming SIP Servers, which sends SIP calls to Sippy. Each SIP Server will control a certain number range and will send its servername as Username. The SIP Server have no infomation about which number belongs to which end user, they forward all calls to Sippy. The Radius Server will have the information what numbers are associated with a certain end user and to which sip server a call have to be sent. The Authorize Request from Sippy should confirm wether the destination number is valid (is configured for an end user) and replys with the correct sip server to use and with a special codec list for the call. If the number is not configured, a Access-Reject is send and the call is aborted. I hope i made myself clear ;) Kind regards, -- Tobias Wolf
i am using FreeRadius 1.1.3 and want to use it for Call Routing.
For the beginning i would like to configure the routes in the users-File and later switch to an sql backend.
b2b Called-Station-Id == 555,Called-Station-Id == 557,Auth-Type := Accept
With that version you won't be able to use sql/unlang workaround for huntgroups. You will have to use huntgroups file or upgrade. b2b Huntgroup-Name == "hg1", Auth-Type := Accept etc. And in huntgroups file: hg1 Called-Station-Id == 555 hg1 Called-Station-Id == 557 Ivan Kalik Kalik Informatika ISP
Tobias Wolf wrote:
i am using FreeRadius 1.1.3 and want to use it for Call Routing.
Upgrade to 2.1.3.
If i have only one Called-Station-Id in the check pairs line, i get the Access-Accept with the reply data.
But since one route can have a lot of numbers i need to be able to have several Called-Station-Id Entrys. From the description of the checkval attribute it appeared to me the correct solution.
2.1.3 has expanded capabilities that make this configuration much easier.
How can this be solved with Freeradius ?
Upgrade, and parameterize the policies.
The Radius Server will have the information what numbers are associated with a certain end user and to which sip server a call have to be sent.
How is this information stored and managed? A database? Flat-text files? Decide how that information is represented and stored first. Then, create policies that reference that information. Alan DeKok.
Alan DeKok schrieb:
Tobias Wolf wrote:
i am using FreeRadius 1.1.3 and want to use it for Call Routing.
Upgrade to 2.1.3.
I think i will do this ;)
If i have only one Called-Station-Id in the check pairs line, i get the Access-Accept with the reply data.
But since one route can have a lot of numbers i need to be able to have several Called-Station-Id Entrys. From the description of the checkval attribute it appeared to me the correct solution.
2.1.3 has expanded capabilities that make this configuration much easier.
Can you please, give me a pointer to this "expanded capabilties"? I have studied the Wiki for freeswitch for a solution how to implement the configuration i have in mind, and all i have found was the solution with checkval.
How can this be solved with Freeradius ?
Upgrade, and parameterize the policies.
I think i do not quite get what is a policy for you. An Entry in the Users File, maybe?
The Radius Server will have the information what numbers are associated with a certain end user and to which sip server a call have to be sent.
How is this information stored and managed? A database? Flat-text files?
For the beginning i planned to start with text files, since i will not have many numbers and users to manage, but later to switch to a database. Many thanks to all the helpful suggestions ;) Regards, -- Tobias Wolf Leiter Softwareentwicklung / Kommunikationslösungen Evision GmbH Wittekindstr. 105 44139 Dortmund Tel: +49 (0)231 - 47790 307 Fax: +49 (0)231 - 47790 500 http://www.evision.de This electronic mail transmission and any accompanying attachments contain confidential information intended only for the use of the individual or entity named above. Any dissemination, distribution, copying or action taken in reliance on the contents of this communication by anyone other than the intended recipient is strictly prohibited. If you have received this communication in error please immediately delete the E-mail and notify the sender at the above E-mail address. Thank you. Hövener & Trapp Evision GmbH, Dortmund - HRB Nr.12477, Registergericht Dortmund - Geschäftsführer Christoph Begall
If i have only one Called-Station-Id in the check pairs line, i get the Access-Accept with the reply data.
But since one route can have a lot of numbers i need to be able to have several Called-Station-Id Entrys. From the description of the checkval attribute it appeared to me the correct solution.
2.1.3 has expanded capabilities that make this configuration much easier.
Can you please, give me a pointer to this "expanded capabilties"? I have studied the Wiki for freeswitch for a solution how to implement the configuration i have in mind, and all i have found was the solution with checkval.
You don't want checkwal, you want huntgroups. In 2.x huntgroups can be implemented with unlang/sql and not use huntgroups file. http://wiki.freeradius.org/SQL_Huntgroup_HOWTO Example is for NAS-IP-Address - adapt it for Called-Station-Id. Ivan Kalik Kalik Informatika ISP
Tobias Wolf wrote:
Can you please, give me a pointer to this "expanded capabilties"? I have studied the Wiki for freeswitch for a solution how to implement the configuration i have in mind, and all i have found was the solution with checkval.
See "man unlang".
Upgrade, and parameterize the policies.
I think i do not quite get what is a policy for you. An Entry in the Users File, maybe?
No. Policies are rules you want to apply.. "if this, then that..". Alan DeKok.
On Wed, Jan 7, 2009 at 11:51 AM, Tobias Wolf <tobias.wolf@evision.de> wrote:
Hello,
i am using FreeRadius 1.1.3 and want to use it for Call Routing.
The Sippy B2BUA will send AAA Requests to RADIUS and i want the routing based on the Called-Station-Id Attribute.
For the beginning i would like to configure the routes in the users-File and later switch to an sql backend.
This is my users-File:
b2b Called-Station-Id == 555,Called-Station-Id == 557,Auth-Type := Accept h323-ivr-in = 'Routing:12345@192.168.1.1;expires=30;Codecs:alaw,g.726'
b2b Called-Station-Id == 556,Called-Station-Id == 558,Auth-Type := Accept h323-ivr-in = 'Routing:12345@192.168.1.2;expires=30;Codecs:alaw,g.726'
The Calls will always come from the same user and the called number will have to decide what SIP Server to use.
If i have only one Called-Station-Id in the check pairs line, i get the Access-Accept with the reply data.
But since one route can have a lot of numbers i need to be able to have several Called-Station-Id Entrys. From the description of the checkval attribute it appeared to me the correct solution.
Apart from this the different number ranges are conncected to different end users, which i have to find. This will be an accounting issue.
How can this be solved with Freeradius ?
The real user is not known when the INVITE reaches Sippy. Sippy sends the request to Freeradius with a lot of information, from which Called-Station-Id will indicate what SIP Server to use and what End User is associated with the call.
Just want to clarify the whole procedure: I have several incoming SIP Servers, which sends SIP calls to Sippy. Each SIP Server will control a certain number range and will send its servername as Username. The SIP Server have no infomation about which number belongs to which end user, they forward all calls to Sippy.
The Radius Server will have the information what numbers are associated with a certain end user and to which sip server a call have to be sent.
The Authorize Request from Sippy should confirm wether the destination number is valid (is configured for an end user) and replys with the correct sip server to use and with a special codec list for the call. If the number is not configured, a Access-Reject is send and the call is aborted.
I hope i made myself clear ;)
Some questions: SIP proxies are not making authentication, the authentication is being done only by B2BUA? For granting access you don't care if the caller is authorized to make the call, you only care if destination is valid? And finally just a tip: You should return h323-ivr-in attribute to Sippy b2bua inside Cisco-AVPair attribute. You need something like this in users file Cisco-AVPair = 'h323-ivr-in=Routing:12345@192.168.1.1;expires=30;Codecs:alaw,g.726' Regards Luciano
Hi, Luciano Afranllie schrieb:
Some questions:
SIP proxies are not making authentication, the authentication is being done only by B2BUA? For granting access you don't care if the caller is authorized to make the call, you only care if destination is valid?
This is correct. All incoming voip traffic comes from SIP Server which are always allowed to access the B2BUA, but it is uncertain if the Destination is valid and, if it is valid, which route it should be forwarded to. Regards, -- Tobias Wolf
participants (4)
-
Alan DeKok -
Luciano Afranllie -
tnt＠kalik.net -
Tobias Wolf