Hi all,
In my application I want to be able to negotiate session timer if the remote side asks for it (incoming calls) but I don’t want to offer it for outgoing calls. To do that, I enabled session timers in the master profile but disabled it in the user profile I
pass to the makeInviteSession method. It turns out that session timer gets enabled. I found out the reason in InviteSession.xx:
// If session timers are locally supported then handle response
if(mDum.getMasterProfile()->getSupportedOptionTags().find(Token(Symbols::Timer)))
It checks the master profile. I think this is incorrect since the timeout value and refresher preference are retrieved from the user profile, i.e: mDialog.mDialogSet.getUserProfile()->getDefaultSessionTime() and mDialog.mDialogSet.getUserProfile()->getDefaultSessionTimerMode()
Since there is no getSupportedOptionTags in the user profile, I added a new condition to fix my problem:
// If session timers are locally supported then handle response
if(mDum.getMasterProfile()->getSupportedOptionTags().find(Token(Symbols::Timer)) &&
mDialog.mDialogSet.getUserProfile()->getDefaultSessionTime() > 0)
A similar problem happens if I don’t want to add “Supported: timer” in the outgoing invite because of the following code in DialogUsageManager.cxx:
if(userProfile->isAdvertisedCapability(Headers::Supported))
{
msg.header(h_Supporteds) = getMasterProfile()->getSupportedOptionTags();
}
It checks Headers::Supported in the userProfile but gets the supported tags from the master profile. So, in the same scenario I explained before, if I call addSupportedOptionTag(Token(Symbols::Timer)) only for the master profile but not for the user profile
for outgoing calls, Supported:Timer is still added.
Shouldn’t getSupportedOptionTags and related methods be moved to UserProfile or am I wrong in my analysis? Thanks in advance.
Diego