[sr-dev] RFC: deprecating add_contact_alias()

[Daniel-Constantin Mierla]

On 14/10/14 16:42, Juha Heinanen wrote:
> Ovidiu Sas writes:
>
>> Both add_contact_alias() and set_contact_alias() are adding the
>> following new param ";alias=ip~port~transport" to the Contact header.
>> There are some subtle differences between the two: set_contact_alias()
>> makes the contact URI is immediately visible to other modules.
>> Recently, Daniel made a fix for set_contact_alias() to work with
>> presence modules (just like fix_nated_contact() does).
>>
>> Since both add_contact_alias() and set_contact_alias() are doing
>> similar things, but add_contact_alias() has some limitations, I would
>> propose to deprecate add_contact_alias() in favour of
>> set_contact_alias().
> normally if a function has limitations, it is enhanced.  why is it not
> possible to enhance add_contact_alias()?
>
set_contact_alias() is doing what those limitations are in 
add_contact_alias(). From 'external' SIP singaling point of view, same 
change is seen in the SIP packets. The difference is how the change is 
done internally.

- add_contact_alias() is adding/removing pieces of string in existing 
contact, the old value is seen by any other module needed to store the 
contact (e.g., dialog, presence) and they won't work if are used in a 
Kamailio positioned as the first hop after nat router
- set_contact_alias() is building the new contact and replaces the old 
one at once, with some special internal flag that makes it visibile 
immediately (same flag is used by fixed_nated_contact())

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.

I don't have any strong opinion on any option: it can be kept and 
pointed to set_contact_alias() or removed in the future.

Cheers,
Daniel

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