Hello, I'd like to permit our subscribers to have several aliases for outgoing calls (basically, several number in the PSTN). I think they could set this in the header From of the INVITE to us and we would identify them, authenticate them and finally relay that same alias (and not the subscriber name) to the GW (currently we permit them to have a single alias for outgoing using a field in the subscriber table). I can see the module alias_db can be used to manage aliases, but I understand it can only be used for incoming calls as it provides just a single function alias_db_lookup that operates on the Request-URI. Any ideas?
regards, takeshi
Hello Takeshi,
I'd like to permit our subscribers to have several aliases for outgoing calls (basically, several number in the PSTN). I think they could set this in the header From of the INVITE to us and we would identify them, authenticate them and finally relay that same alias (and not the subscriber name) to the GW (currently we permit them to have a single alias for outgoing using a field in the subscriber table). I can see the module alias_db can be used to manage aliases, but I understand it can only be used for incoming calls as it provides just a single function alias_db_lookup that operates on the Request- URI. Any ideas?
You can use both Remote-Party-ID and PAI headers for sending the caller id to the gateway:
append_rpid_hf() for rpid or append_hf() for PAI.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
On Fri, Jul 18, 2008 at 2:33 PM, Jesus Rodriguez jesusr@voztele.com wrote:
You can use both Remote-Party-ID and PAI headers for sending the caller id to the gateway:
append_rpid_hf() for rpid or append_hf() for PAI.
Jesus is right.
Please, bear in mind that Remote-Party-ID is not standard and has been replaced with PAI-- anyway RPID is implemented in most Cisco stuff.
My two cents,
Victor, Jesus, thanks for the replies. But the use of Remote-Party-ID/PAI (or non-use, depending on the terminating equipment), is a subsequent step. First I have to identify the subscriber based on the alias: the subscriber will have several of them and will send any one of them to us in the INVITE. The alias will be set in the header From, so what I need is a way to perform its lookup at table dbaliases. Then, authenticate the subscriber and finally relay the INVITE (using Remote-Party-ID/PAI or not).
regards, takeshi
On 7/19/08, Victor Pascual Ávila victor.pascual.avila@gmail.com wrote:
On Fri, Jul 18, 2008 at 2:33 PM, Jesus Rodriguez jesusr@voztele.com wrote:
You can use both Remote-Party-ID and PAI headers for sending the caller id to the gateway:
append_rpid_hf() for rpid or append_hf() for PAI.
Jesus is right.
Please, bear in mind that Remote-Party-ID is not standard and has been replaced with PAI-- anyway RPID is implemented in most Cisco stuff.
My two cents,
Victor Pascual Ávila
El Viernes, 18 de Julio de 2008 18:02, mayamatakeshi escribió:
Victor, Jesus, thanks for the replies. But the use of Remote-Party-ID/PAI (or non-use, depending on the terminating equipment), is a subsequent step. First I have to identify the subscriber based on the alias: the subscriber will have several of them and will send any one of them to us in the INVITE. The alias will be set in the header From, so what I need is a way to perform its lookup at table dbaliases. Then, authenticate the subscriber and finally relay the INVITE (using Remote-Party-ID/PAI or not).
Hi Maya, I think your are doing it on the wrong order, better follow Jesus and Victor advice.
On our system we let the user send us PPI headers and if you find one, we check if that PPI is allowed for that user and then translate it into a PAI header for our GW's, that the "correct" way of doing this.
On 7/19/08, Raúl Alexis Betancor Santana rabs@dimension-virtual.com wrote:
Hi Maya, I think your are doing it on the wrong order, better follow Jesus and Victor advice.
On our system we let the user send us PPI headers and if you find one, we check if that PPI is allowed for that user and then translate it into a PAI header for our GW's, that the "correct" way of doing this.
Hello Raúl,
thank you. I read rfc3325 and I think I got it. But the requirements here are to provide alias support even for entities that doesn't support PPI/PAI (or RPID). So we were looking for a way to do it using the dbaliases table, based on the identity in the header From.
But for the cases where the client/gw does support PPI/PAI, let me see if I got it correctly:
Currently, we perform authentication using module auth_db. To use PPI we should move to auth_radius and use
if (!radius_proxy_authorize("$pd", "$pU")) { # Realm and URI user are taken proxy_challenge("$pd", "1"); # from P-Preferred-Identity }; # header field
If all goes well, we can use append_hf to send the PPI as PAI or append_rpid_hf (rpid was fetched into avp during authentication), depending on gw capabilities. Is this correct?
regards, takeshi
-
Jesus Rodriguez -
mayamatakeshi -
Raúl Alexis Betancor Santana -
Victor Pascual Ávila