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