Re: [reSIProcate] Session Timer and Profiles

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

With the current configuration design, supported methods, options, encodings, languages, etc. are all considered to be global for the DUM instance.  There is no current mechanism to control these per call / UserProfile / Profile.  Many of these settings are used for message validation before a profile is assigned.

If you want to implement what you require, I think the best approach is to add a new SessionTimerMode, perhaps something like, AcceptButDontOffer.

Note on removing options from Supported header:  You can use a message decorator to remove a supported option tag if you want (see Profile::setOutboundDecorator).  http://www.resiprocate.org/Modifying/Decorating_messages_sent

Scott

On Mon, Aug 27, 2018 at 2:49 PM Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> wrote:

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

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel