Hi,
please consider the addition of these features to master branch.
you can view the full PR in https://github.com/kamailio/kamailio/pull/91
the purpose of these additional features is to provide better information to configuration script to help in complex routing decisions and adding custom headers based on rich information.
registrar - add user xavp on successful registered call
this commit adds the contact xavp when we call registered() it acts like lookup without rewriting uri or appending branches it acts like lookup_to_dest without appending branches
benefits, used in conjuction with usrloc param xavp_contact prior to this commit, we would have to use sqlops to make a select directly into location_attrs, but not all sb engines support raw query or we would need to call lookup causing the unnecessary and unwanted set of the ruri.
modparam("usrloc", "xavp_contact", "ulattrs") .. if(registered("location", "$fu") ) { $xavp(ulattrs=>my extended information about the contact) }
before if( registered("location", "$fu") ) { ## lookup_to_dset("location", "$fu") ## not available lookup("location", "$fu") $xavp(ulattrs=>my extended information about the contact)
registrar - add optional avp params for usrloc comparison
reg_received_avp - match with received field reg_contact_avp - match with contact field
this commit adds 2 optional params to be used on the registered function
prior to this commit, the only restriction available when calling registered was by using a call-id. the 2 params added allow the match to be more restrictive . by received column . by contact column
registrar - add xavp to reg_fetch_contacts
modparams("usrloc", "xavp_contact", "ulattrs");
this commit adds the usrloc xavp_contact to the returned structure.
reg_fetch_contacts("location", "$fu", "caller"); xlog("L_INFO", "$fu xavp = $ulc(caller=>received)"); xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");
Thank You
Hello,
some comments inline.
On 17/02/15 23:25, Luis Azedo wrote:
Hi,
please consider the addition of these features to master branch.
you can view the full PR in https://github.com/kamailio/kamailio/pull/91
the purpose of these additional features is to provide better information to configuration script to help in complex routing decisions and adding custom headers based on rich information.
registrar - add user xavp on successful registered call
this commit adds the contact xavp when we call registered() it acts like lookup without rewriting uri or appending branches it acts like lookup_to_dest without appending branches
benefits, used in conjuction with usrloc param xavp_contact prior to this commit, we would have to use sqlops to make a select directly into location_attrs, but not all sb engines support raw query or we would need to call lookup causing the unnecessary and unwanted set of the ruri.
modparam("usrloc", "xavp_contact", "ulattrs") .. if(registered("location", "$fu") ) { $xavp(ulattrs=>my extended information about the contact) }
before if( registered("location", "$fu") ) { ## lookup_to_dset("location", "$fu") ## not available lookup("location", "$fu") $xavp(ulattrs=>my extended information about the contact)
will this add the xavp only for first valid contact found in location table? Or for all contacts (e.g., when a user is registered with many phones)?
registrar - add optional avp params for usrloc comparison
reg_received_avp - match with received field reg_contact_avp - match with contact field
this commit adds 2 optional params to be used on the registered function
prior to this commit, the only restriction available when calling registered was by using a call-id. the 2 params added allow the match to be more restrictive . by received column . by contact column
I see that the match on call-id was added by Henning back in 2008, haven't used it.
My concern here is about adding too many avps parameters which can endup in loops across the list of avps to see if they are defined or not.
I am thinking of having a different implementation that is better in terms of performances and flexibility, like: - extend the registered parameters to take one more as flags - here will be a bitmask of what matching rules to be applied (e.g., 1 - callid matching, 2 - received matching, 4 - contact matching) - add the values for matching as part of xavp_cfg avp (e.g., say xavp_cfg is set to 'reg', then will be $xavp(reg=>match_callid) = "..."; $xavp(reg=>match_received) = "..." ...)
Practically the search for the values to be match will be done only if the appropriate flag is set.
The avp for matching call id should be removed.
In the future, adding another matching rule will be adding a new flag and an inner attribute/value for xavp_cfg.
What do you think?
registrar - add xavp to reg_fetch_contacts
modparams("usrloc", "xavp_contact", "ulattrs");
this commit adds the usrloc xavp_contact to the returned structure. reg_fetch_contacts("location", "$fu", "caller"); xlog("L_INFO", "$fu xavp = $ulc(caller=>received)"); xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");
I think this can be done also conditionally -- I would add a new parameter to reg_fetch_contacts where we can specify this behaviour as a flag.
Thanks for these contributions and let's see if others have other ideas or commends on my proposal to get to a solution that is fair from performance/feature ratio point of view.
Cheers, Daniel
Hi Daniel,
thank you for the contribution.
see inline
________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Daniel-Constantin Mierla [miconda@gmail.com] Sent: Wednesday, February 18, 2015 3:51 AM To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hello,
some comments inline.
On 17/02/15 23:25, Luis Azedo wrote: Hi,
please consider the addition of these features to master branch.
you can view the full PR in https://github.com/kamailio/kamailio/pull/91
the purpose of these additional features is to provide better information to configuration script to help in complex routing decisions and adding custom headers based on rich information.
registrar - add user xavp on successful registered call
this commit adds the contact xavp when we call registered() it acts like lookup without rewriting uri or appending branches it acts like lookup_to_dest without appending branches
benefits, used in conjuction with usrloc param xavp_contact prior to this commit, we would have to use sqlops to make a select directly into location_attrs, but not all sb engines support raw query or we would need to call lookup causing the unnecessary and unwanted set of the ruri.
modparam("usrloc", "xavp_contact", "ulattrs") .. if(registered("location", "$fu") ) { $xavp(ulattrs=>my extended information about the contact) }
before if( registered("location", "$fu") ) { ## lookup_to_dset("location", "$fu") ## not available lookup("location", "$fu") $xavp(ulattrs=>my extended information about the contact)
will this add the xavp only for first valid contact found in location table? Or for all contacts (e.g., when a user is registered with many phones)?
A : it will add the xavp for the first contact found since registered function exits on first match.
registrar - add optional avp params for usrloc comparison
reg_received_avp - match with received field reg_contact_avp - match with contact field
this commit adds 2 optional params to be used on the registered function
prior to this commit, the only restriction available when calling registered was by using a call-id. the 2 params added allow the match to be more restrictive . by received column . by contact column
I see that the match on call-id was added by Henning back in 2008, haven't used it.
My concern here is about adding too many avps parameters which can endup in loops across the list of avps to see if they are defined or not.
I am thinking of having a different implementation that is better in terms of performances and flexibility, like: - extend the registered parameters to take one more as flags - here will be a bitmask of what matching rules to be applied (e.g., 1 - callid matching, 2 - received matching, 4 - contact matching) - add the values for matching as part of xavp_cfg avp (e.g., say xavp_cfg is set to 'reg', then will be $xavp(reg=>match_callid) = "..."; $xavp(reg=>match_received) = "..." ...)
Practically the search for the values to be match will be done only if the appropriate flag is set.
The avp for matching call id should be removed.
In the future, adding another matching rule will be adding a new flag and an inner attribute/value for xavp_cfg.
What do you think?
A : i like this approach. trying that.
registrar - add xavp to reg_fetch_contacts
modparams("usrloc", "xavp_contact", "ulattrs");
this commit adds the usrloc xavp_contact to the returned structure.
reg_fetch_contacts("location", "$fu", "caller"); xlog("L_INFO", "$fu xavp = $ulc(caller=>received)"); xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");
I think this can be done also conditionally -- I would add a new parameter to reg_fetch_contacts where we can specify this behaviour as a flag.
A : instead of a parameter, we could add a parameter "return_xavp_on_match" (or better naming) that would control the addition of the xavp in registered and reg_fetch_contacts. in reg_fetch_contacts the xavp is returned for each contact (not like in registered). i added it since we are already doing it in the lookup and lookup_to_dset.
Thanks for these contributions and let's see if others have other ideas or commends on my proposal to get to a solution that is fair from performance/feature ratio point of view.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
Hi,
made this commit to the pull request. i think it answers all questions, comments appreciated.
registrar - match changes
add param match_flags bit mask 1 callid 2 received 3 contact
add param match_return_flags - bit mask 1 add contact xavp in registered adds or sets into the transaction in reg_fetch_contacts adds to plc structure
changes to registered check the match_flags bit mask value and tries to find correspondent field in xavp_cfg matches with the fields found
also looks for match_flags, match_return_flags in xavp_cfg to override the params
preserves existing behaviour removes reg_callid_avp
________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Luis Azedo [luis@2600hz.com] Sent: Wednesday, February 18, 2015 4:44 AM To: miconda@gmail.com; Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hi Daniel,
thank you for the contribution.
see inline
________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Daniel-Constantin Mierla [miconda@gmail.com] Sent: Wednesday, February 18, 2015 3:51 AM To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hello,
some comments inline.
On 17/02/15 23:25, Luis Azedo wrote: Hi,
please consider the addition of these features to master branch.
you can view the full PR in https://github.com/kamailio/kamailio/pull/91
the purpose of these additional features is to provide better information to configuration script to help in complex routing decisions and adding custom headers based on rich information.
registrar - add user xavp on successful registered call
this commit adds the contact xavp when we call registered() it acts like lookup without rewriting uri or appending branches it acts like lookup_to_dest without appending branches
benefits, used in conjuction with usrloc param xavp_contact prior to this commit, we would have to use sqlops to make a select directly into location_attrs, but not all sb engines support raw query or we would need to call lookup causing the unnecessary and unwanted set of the ruri.
modparam("usrloc", "xavp_contact", "ulattrs") .. if(registered("location", "$fu") ) { $xavp(ulattrs=>my extended information about the contact) }
before if( registered("location", "$fu") ) { ## lookup_to_dset("location", "$fu") ## not available lookup("location", "$fu") $xavp(ulattrs=>my extended information about the contact)
will this add the xavp only for first valid contact found in location table? Or for all contacts (e.g., when a user is registered with many phones)?
A : it will add the xavp for the first contact found since registered function exits on first match.
registrar - add optional avp params for usrloc comparison
reg_received_avp - match with received field reg_contact_avp - match with contact field
this commit adds 2 optional params to be used on the registered function
prior to this commit, the only restriction available when calling registered was by using a call-id. the 2 params added allow the match to be more restrictive . by received column . by contact column
I see that the match on call-id was added by Henning back in 2008, haven't used it.
My concern here is about adding too many avps parameters which can endup in loops across the list of avps to see if they are defined or not.
I am thinking of having a different implementation that is better in terms of performances and flexibility, like: - extend the registered parameters to take one more as flags - here will be a bitmask of what matching rules to be applied (e.g., 1 - callid matching, 2 - received matching, 4 - contact matching) - add the values for matching as part of xavp_cfg avp (e.g., say xavp_cfg is set to 'reg', then will be $xavp(reg=>match_callid) = "..."; $xavp(reg=>match_received) = "..." ...)
Practically the search for the values to be match will be done only if the appropriate flag is set.
The avp for matching call id should be removed.
In the future, adding another matching rule will be adding a new flag and an inner attribute/value for xavp_cfg.
What do you think?
A : i like this approach. trying that.
registrar - add xavp to reg_fetch_contacts
modparams("usrloc", "xavp_contact", "ulattrs");
this commit adds the usrloc xavp_contact to the returned structure.
reg_fetch_contacts("location", "$fu", "caller"); xlog("L_INFO", "$fu xavp = $ulc(caller=>received)"); xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");
I think this can be done also conditionally -- I would add a new parameter to reg_fetch_contacts where we can specify this behaviour as a flag.
A : instead of a parameter, we could add a parameter "return_xavp_on_match" (or better naming) that would control the addition of the xavp in registered and reg_fetch_contacts. in reg_fetch_contacts the xavp is returned for each contact (not like in registered). i added it since we are already doing it in the lookup and lookup_to_dset.
Thanks for these contributions and let's see if others have other ideas or commends on my proposal to get to a solution that is fair from performance/feature ratio point of view.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
I haven't seen any updates to the doc files - or did I miss them?
/O
On 19 Feb 2015, at 14:08, Luis Azedo luis@2600hz.com wrote:
Hi,
made this commit to the pull request. i think it answers all questions, comments appreciated.
registrar - match changes add param match_flags bit mask 1 callid 2 received 3 contact
add param match_return_flags - bit mask 1 add contact xavp in registered adds or sets into the transaction in reg_fetch_contacts adds to plc structure
changes to registered check the match_flags bit mask value and tries to find correspondent field in xavp_cfg matches with the fields found
also looks for match_flags, match_return_flags in xavp_cfg to override the params
preserves existing behaviour removes reg_callid_avp
From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Luis Azedo [luis@2600hz.com] Sent: Wednesday, February 18, 2015 4:44 AM To: miconda@gmail.com; Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hi Daniel,
thank you for the contribution.
see inline
From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Daniel-Constantin Mierla [miconda@gmail.com] Sent: Wednesday, February 18, 2015 3:51 AM To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hello,
some comments inline.
On 17/02/15 23:25, Luis Azedo wrote:
Hi,
please consider the addition of these features to master branch.
you can view the full PR in https://github.com/kamailio/kamailio/pull/91
the purpose of these additional features is to provide better information to configuration script to help in complex routing decisions and adding custom headers based on rich information.
registrar - add user xavp on successful registered call
this commit adds the contact xavp when we call registered() it acts like lookup without rewriting uri or appending branches it acts like lookup_to_dest without appending branches
benefits, used in conjuction with usrloc param xavp_contact prior to this commit, we would have to use sqlops to make a select directly into location_attrs, but not all sb engines support raw query or we would need to call lookup causing the unnecessary and unwanted set of the ruri.
modparam("usrloc", "xavp_contact", "ulattrs") .. if(registered("location", "$fu") ) { $xavp(ulattrs=>my extended information about the contact) }
before if( registered("location", "$fu") ) { ## lookup_to_dset("location", "$fu") ## not available lookup("location", "$fu") $xavp(ulattrs=>my extended information about the contact)
will this add the xavp only for first valid contact found in location table? Or for all contacts (e.g., when a user is registered with many phones)?
A : it will add the xavp for the first contact found since registered function exits on first match.
registrar - add optional avp params for usrloc comparison reg_received_avp - match with received field reg_contact_avp - match with contact field
this commit adds 2 optional params to be used on the registered function
prior to this commit, the only restriction available when calling registered was by using a call-id. the 2 params added allow the match to be more restrictive . by received column . by contact column
I see that the match on call-id was added by Henning back in 2008, haven't used it.
My concern here is about adding too many avps parameters which can endup in loops across the list of avps to see if they are defined or not.
I am thinking of having a different implementation that is better in terms of performances and flexibility, like:
- extend the registered parameters to take one more as flags - here will be a bitmask of what matching rules to be applied (e.g., 1 - callid matching, 2 - received matching, 4 - contact matching)
- add the values for matching as part of xavp_cfg avp (e.g., say xavp_cfg is set to 'reg', then will be $xavp(reg=>match_callid) = "..."; $xavp(reg=>match_received) = "..." ...)
Practically the search for the values to be match will be done only if the appropriate flag is set.
The avp for matching call id should be removed.
In the future, adding another matching rule will be adding a new flag and an inner attribute/value for xavp_cfg.
What do you think?
A : i like this approach. trying that.
registrar - add xavp to reg_fetch_contacts modparams("usrloc", "xavp_contact", "ulattrs");
this commit adds the usrloc xavp_contact to the returned structure. reg_fetch_contacts("location", "$fu", "caller"); xlog("L_INFO", "$fu xavp = $ulc(caller=>received)"); xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");
I think this can be done also conditionally -- I would add a new parameter to reg_fetch_contacts where we can specify this behaviour as a flag.
A : instead of a parameter, we could add a parameter "return_xavp_on_match" (or better naming) that would control the addition of the xavp in registered and reg_fetch_contacts. in reg_fetch_contacts the xavp is returned for each contact (not like in registered). i added it since we are already doing it in the lookup and lookup_to_dset.
Thanks for these contributions and let's see if others have other ideas or commends on my proposal to get to a solution that is fair from performance/feature ratio point of view.
Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
waiting on implementation comments, if accepted, will document before merge
________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Olle E. Johansson [oej@edvina.net] Sent: Thursday, February 19, 2015 5:18 AM To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
I haven't seen any updates to the doc files - or did I miss them?
/O
On 19 Feb 2015, at 14:08, Luis Azedo <luis@2600hz.commailto:luis@2600hz.com> wrote:
Hi,
made this commit to the pull request. i think it answers all questions, comments appreciated.
registrar - match changes
add param match_flags bit mask 1 callid 2 received 3 contact
add param match_return_flags - bit mask 1 add contact xavp in registered adds or sets into the transaction in reg_fetch_contacts adds to plc structure
changes to registered check the match_flags bit mask value and tries to find correspondent field in xavp_cfg matches with the fields found
also looks for match_flags, match_return_flags in xavp_cfg to override the params
preserves existing behaviour removes reg_callid_avp
________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.orgmailto:sr-dev-bounces@lists.sip-router.org] on behalf of Luis Azedo [luis@2600hz.commailto:luis@2600hz.com] Sent: Wednesday, February 18, 2015 4:44 AM To: miconda@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hi Daniel,
thank you for the contribution.
see inline
________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.orgmailto:sr-dev-bounces@lists.sip-router.org] on behalf of Daniel-Constantin Mierla [miconda@gmail.commailto:miconda@gmail.com] Sent: Wednesday, February 18, 2015 3:51 AM To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Hello,
some comments inline.
On 17/02/15 23:25, Luis Azedo wrote: Hi,
please consider the addition of these features to master branch.
you can view the full PR in https://github.com/kamailio/kamailio/pull/91
the purpose of these additional features is to provide better information to configuration script to help in complex routing decisions and adding custom headers based on rich information.
registrar - add user xavp on successful registered call
this commit adds the contact xavp when we call registered() it acts like lookup without rewriting uri or appending branches it acts like lookup_to_dest without appending branches
benefits, used in conjuction with usrloc param xavp_contact prior to this commit, we would have to use sqlops to make a select directly into location_attrs, but not all sb engines support raw query or we would need to call lookup causing the unnecessary and unwanted set of the ruri.
modparam("usrloc", "xavp_contact", "ulattrs") .. if(registered("location", "$fu") ) { $xavp(ulattrs=>my extended information about the contact) }
before if( registered("location", "$fu") ) { ## lookup_to_dset("location", "$fu") ## not available lookup("location", "$fu") $xavp(ulattrs=>my extended information about the contact)
will this add the xavp only for first valid contact found in location table? Or for all contacts (e.g., when a user is registered with many phones)?
A : it will add the xavp for the first contact found since registered function exits on first match.
registrar - add optional avp params for usrloc comparison
reg_received_avp - match with received field reg_contact_avp - match with contact field
this commit adds 2 optional params to be used on the registered function
prior to this commit, the only restriction available when calling registered was by using a call-id. the 2 params added allow the match to be more restrictive . by received column . by contact column
I see that the match on call-id was added by Henning back in 2008, haven't used it.
My concern here is about adding too many avps parameters which can endup in loops across the list of avps to see if they are defined or not.
I am thinking of having a different implementation that is better in terms of performances and flexibility, like: - extend the registered parameters to take one more as flags - here will be a bitmask of what matching rules to be applied (e.g., 1 - callid matching, 2 - received matching, 4 - contact matching) - add the values for matching as part of xavp_cfg avp (e.g., say xavp_cfg is set to 'reg', then will be $xavp(reg=>match_callid) = "..."; $xavp(reg=>match_received) = "..." ...)
Practically the search for the values to be match will be done only if the appropriate flag is set.
The avp for matching call id should be removed.
In the future, adding another matching rule will be adding a new flag and an inner attribute/value for xavp_cfg.
What do you think?
A : i like this approach. trying that.
registrar - add xavp to reg_fetch_contacts
modparams("usrloc", "xavp_contact", "ulattrs");
this commit adds the usrloc xavp_contact to the returned structure.
reg_fetch_contacts("location", "$fu", "caller"); xlog("L_INFO", "$fu xavp = $ulc(caller=>received)"); xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");
I think this can be done also conditionally -- I would add a new parameter to reg_fetch_contacts where we can specify this behaviour as a flag.
A : instead of a parameter, we could add a parameter "return_xavp_on_match" (or better naming) that would control the addition of the xavp in registered and reg_fetch_contacts. in reg_fetch_contacts the xavp is returned for each contact (not like in registered). i added it since we are already doing it in the lookup and lookup_to_dset.
Thanks for these contributions and let's see if others have other ideas or commends on my proposal to get to a solution that is fair from performance/feature ratio point of view.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.comhttp://www.kamailioworld.com/
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.orgmailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Luis Azedo writes:
add param match_return_flags - bit mask 1 add contact xavp in registered adds or sets into the transaction in reg_fetch_contacts adds to plc structure
does this mean that a new xavp is created even if any of the new features are not used? can you tell exactly how performance (speed, memory usage) of registrar changes when these new features are not used?
-- juha
no, nothing is created if not configured. current behavior is preserved ________________________________________ From: sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Juha Heinanen [jh@tutpro.com] Sent: Thursday, February 19, 2015 12:23 PM To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] registrar - additional features
Luis Azedo writes:
add param match_return_flags - bit mask 1 add contact xavp in registered adds or sets into the transaction in reg_fetch_contacts adds to plc structure
does this mean that a new xavp is created even if any of the new features are not used? can you tell exactly how performance (speed, memory usage) of registrar changes when these new features are not used?
-- juha
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Juha Heinanen -
Luis Azedo -
Olle E. Johansson