[sr-dev] RFC: deprecating add_contact_alias()

Daniel-Constantin Mierla miconda at gmail.com
Tue Oct 14 17:35:09 CEST 2014


On 14/10/14 17:13, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> In other words, add_contact_alias() can be pointed directly to
>> set_contact_alias() and no functionality is lost. Ovidiu's suggestion is
>> to deprecate it and remove it in future version.
> is there any performance difference when change is made immediately to
> sip message?
I don't think it can be any real difference, not measured, though.

>
> if not, i still don't understand why add_contact_alias was not simply
> modified instead of creating a new function.  why don't you rename
> set_contact_alias to add_contact_alias and deprecate set_contact_alias,
> since i bet that add_contact_alias is as older function used in more
> configs than set_contact_alias?
set_contact_alias() replaced the fix_natted_contact() in default config, 
from this perspective I think that set_contact_alias() is used in more 
configs than add_contact_alias(), but at the end this is not the point, 
because you cannot really count all configs and anyhow usage count 
should not be reason to remove something better. The function was added 
in the same idea of having alternatives of fix_natted_contact() and 
add_contact_alias() tackling the same problem from a different point. On 
other words, as add_contact_alias() would prove to be better for 
handling nat traversal, we should rename it to fix_natted_contact() 
because that is older.

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, ...

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.

Daniel


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-dev mailing list