Hello,
if you follow the sr-dev mailing list, you may have noticed some new features added in master branch (for the 3.1.0). I will send more details about each, now: remote user registration.
The uac module can register in behalf of users to remote servers. The user details (credentials, local and remote username/domain) are loaded from database. The module sends registration at start-up and then refreshes just before expiration time. If the REGISTER is challenged for authentication, uac will re-send the REGISTER with proper credentials.
A typical scenario is when users have accounts to many voip providers and they want to receive calls to those accounts via your sip server (inbound traffic). Of course, the user has to give details such as username/password to you.
Other use case can be dynamic interconnection/peering. you can imagine a scalable solution where you have a traffic dispatcher and worker servers. When an worker becomes active, it registers to traffic dispatcher for receiving traffic... and examples can continue.
Hope will help you in various cases! Readme at: http://sip-router.org/docbook/sip-router/branch/master/modules_k/uac/uac.htm...
SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql
Cheers, Daniel
28 jan 2010 kl. 15.52 skrev Daniel-Constantin Mierla:
Hello,
if you follow the sr-dev mailing list, you may have noticed some new features added in master branch (for the 3.1.0). I will send more details about each, now: remote user registration.
The uac module can register in behalf of users to remote servers. The user details (credentials, local and remote username/domain) are loaded from database. The module sends registration at start-up and then refreshes just before expiration time. If the REGISTER is challenged for authentication, uac will re-send the REGISTER with proper credentials.
A typical scenario is when users have accounts to many voip providers and they want to receive calls to those accounts via your sip server (inbound traffic). Of course, the user has to give details such as username/password to you.
Other use case can be dynamic interconnection/peering. you can imagine a scalable solution where you have a traffic dispatcher and worker servers. When an worker becomes active, it registers to traffic dispatcher for receiving traffic... and examples can continue.
Hope will help you in various cases! Readme at: http://sip-router.org/docbook/sip-router/branch/master/modules_k/uac/uac.htm...
SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql
Great! I needed this yesterday and now I don't even have to code it myself. THanks!
/O
On 1/29/10 9:05 AM, Olle E. Johansson wrote:
28 jan 2010 kl. 15.52 skrev Daniel-Constantin Mierla:
Hello,
if you follow the sr-dev mailing list, you may have noticed some new features added in master branch (for the 3.1.0). I will send more details about each, now: remote user registration.
The uac module can register in behalf of users to remote servers. The user details (credentials, local and remote username/domain) are loaded from database. The module sends registration at start-up and then refreshes just before expiration time. If the REGISTER is challenged for authentication, uac will re-send the REGISTER with proper credentials.
A typical scenario is when users have accounts to many voip providers and they want to receive calls to those accounts via your sip server (inbound traffic). Of course, the user has to give details such as username/password to you.
Other use case can be dynamic interconnection/peering. you can imagine a scalable solution where you have a traffic dispatcher and worker servers. When an worker becomes active, it registers to traffic dispatcher for receiving traffic... and examples can continue.
Hope will help you in various cases! Readme at: http://sip-router.org/docbook/sip-router/branch/master/modules_k/uac/uac.htm...
SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql
Great! I needed this yesterday
code was committed about 5 days ago :-) ...
Cheers, Daniel
and now I don't even have to code it myself. THanks!
Perhaps this could be of relevance: There is an IETF working group called MARTINI attempting to standardize this:
http://www.ietf.org/mail-archive/web/sip-ops/current/msg00038.html
-Jan
On 29-01 10:29, Daniel-Constantin Mierla wrote:
On 1/29/10 9:05 AM, Olle E. Johansson wrote:
28 jan 2010 kl. 15.52 skrev Daniel-Constantin Mierla:
Hello,
if you follow the sr-dev mailing list, you may have noticed some new features added in master branch (for the 3.1.0). I will send more details about each, now: remote user registration.
The uac module can register in behalf of users to remote servers. The user details (credentials, local and remote username/domain) are loaded from database. The module sends registration at start-up and then refreshes just before expiration time. If the REGISTER is challenged for authentication, uac will re-send the REGISTER with proper credentials.
A typical scenario is when users have accounts to many voip providers and they want to receive calls to those accounts via your sip server (inbound traffic). Of course, the user has to give details such as username/password to you.
Other use case can be dynamic interconnection/peering. you can imagine a scalable solution where you have a traffic dispatcher and worker servers. When an worker becomes active, it registers to traffic dispatcher for receiving traffic... and examples can continue.
Hope will help you in various cases! Readme at: http://sip-router.org/docbook/sip-router/branch/master/modules_k/uac/uac.htm...
SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql
Great! I needed this yesterday
code was committed about 5 days ago :-) ...
Cheers, Daniel
and now I don't even have to code it myself. THanks!
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Lunes, 1 de Febrero de 2010, Jan Janak escribió:
Perhaps this could be of relevance: There is an IETF working group called MARTINI attempting to standardize this
MARTINI? Ok, I already understand how some RFC's were born...
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Jan Janak -
Olle E. Johansson