Well, I started the discussion :)
We can keep both methods, we just need to update the docs that add_contact_alias() doesn't work with presence: NATed subscriptions handled using add_contact_alias() will not work properly.
This is just to avoid same question repeated on the mailing list. I hit the same issue with set_contact_alias() before it was fixed and then I saw the same issue raised by someone else.
Regards, Ovidiu Sas
On Tue, Oct 14, 2014 at 11:53 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 14/10/14 17:44, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
If there is a strong desire to keep add_contact_alias(), it should be kept after all, but properly documented that has the limitations on making new contact visible and should not be used in a sip server instance used for presence, dialog, ...
i have made enhancements to a large number of functions and never created new ones unless there has been backwards incompatible change in parameters or performance penalty.
Actually there were quite big implications in other modules (like in dialog done initially and then in tm module done recently to get it all work like a replacement for fix_natted_contact()) -- so it was not just about a new (or replacement) function in nathelper module.
if there has not been either in case of set_contact_alias, it should not have not created in the first place and therefore i'm against deprecating add_contact_alias.
It's fine to keep add_contact_alias() from my point of view, if you feel it performs better for your needs (I didn't start this discussion after all), but docs have to list the limitations.
Or, even better in my opinion at this time, just point both to same C function. Overall, as this is discussion about deprecating something, it will happen more recently with the future next major release, 4.3.
i didn't get answer to performance issue. is there penalty when changes are applied to the message by set_contact_alias function? if yes, then add_contact_alias code should not be changed.
I did say something about performances from my point of view in the previous email.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev