< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

[reSIProcate] Session Timer and Profiles

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


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:



   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.