Hello,
I want to add a new function to the registrar module that will allow me to remove a contact from the location table when I receive a 430 from an edge proxy.
I believe I can use the get_ucontact_by_instance() function from usrloc to remove the exact contact I want (based on contact address, sip.instance, and reg-id). However, at the point at which I have received a 430 from the edge proxy (in the failure_route[] on the registrar) I am not sure how I can determine the sip.instance and reg-id. As far as I can tell neither of these values is added to the request when the registrar:lookup() exported function is called.
I don't want to just remove contacts based on address, or even address and sip.instance, because when outbound is used I will have multiple contacts with the same address and sip.instance values, with only the reg-id different.
Does anyone have any suggestions as to how I can obtain this information in a failure_route[]?
Regards,
Peter
Hello,
On 2/28/13 6:25 PM, Peter Dunkley wrote:
Hello,
I want to add a new function to the registrar module that will allow me to remove a contact from the location table when I receive a 430 from an edge proxy.
I believe I can use the get_ucontact_by_instance() function from usrloc to remove the exact contact I want (based on contact address, sip.instance, and reg-id). However, at the point at which I have received a 430 from the edge proxy (in the failure_route[] on the registrar) I am not sure how I can determine the sip.instance and reg-id. As far as I can tell neither of these values is added to the request when the registrar:lookup() exported function is called.
I don't want to just remove contacts based on address, or even address and sip.instance, because when outbound is used I will have multiple contacts with the same address and sip.instance values, with only the reg-id different.
Does anyone have any suggestions as to how I can obtain this information in a failure_route[]?
I am not sure that data in request can be really useful in this case for a general solution. Have in mind parallel forking, when only one branch gets in failure_route, so if one branch gets 430 and and another one 3xx, the one for 3xx is handled.
Maybe handling in onreply_route would be better. The field ruid might need propagation to dst set (and branch) -- that's unique identifier for location records, making very easy to find and remove desired contact.
Cheers, Daniel
On 28/02/13 20:20, Daniel-Constantin Mierla wrote:
I am not sure that data in request can be really useful in this case for a general solution. Have in mind parallel forking, when only one branch gets in failure_route, so if one branch gets 430 and and another one 3xx, the one for 3xx is handled.
Maybe handling in onreply_route would be better. The field ruid might need propagation to dst set (and branch) -- that's unique identifier for location records, making very easy to find and remove desired contact.
Adding an exported function that can remove something based on ruid seems like a good solution. Can you point me to any examples of other things propagated to dst set and branch so I can work out how to make this available?
Thanks,
Peter