[reSIProcate] Session Timer and Profiles

[Scott Godin]

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 at daitangroup.com> 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 at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20180828/16c1318d/attachment.htm>