Re: [reSIProcate] Using SipMessage::addOutboundDecorator from within a DUM application

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Be careful about threading - make sure you are not modifying the profile in one thread, when dum might be using it another.

 

You could create a profile just for that one Invite session - however it will be called for all messaging within the InviteSession.  The decorator itself can be smart enough to only act on the initial INVITE (ie. no To tag).

 

Scott

On Fri, Sep 30, 2011 at 11:58 AM, Francis Joanis <francis.joanis@xxxxxxxxx> wrote:

Hi,

Cool, I haven't tested it, but I guess I could also:

- Add decorator to profile
- call DUM::send
- Remove decorator from profile

if I don't want it to be called on all messages.

Thanks :)

On Fri, Sep 30, 2011 at 11:54 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
> You can add the outbound decorator to the profile you are using when sending
> the invite.  DUM will add this decorator from the profile to the invite
> message before it is sent down to the stack.
>
> Scott
>
> On Fri, Sep 30, 2011 at 11:31 AM, Francis Joanis <francis.joanis@xxxxxxxxx>
> wrote:
>>
>> Hi,
>>
>> I need to cache a copy of an initial outgoing (UAC) INVITE (as sent on
>> the wire, so including all the Vias, ...) from a DUM application.
>>
>> I know that I can probably do it using an outgoing DUM feature, but
>> I'd rather use something that doesn't get called all the time (i.e.
>> for all messages). I also looked at InviteSession::onReadyToSend, but
>> since in my case the message is the initial UAC INVITE the session
>> itself doesn't exist when it gets sent so onReadyToSend doesn't get
>> called.
>>
>> What I wanted to originally do was to use a custom MessageDecorator
>> and add it to the SipMessage created when calling
>> DUM::makeInviteSession. This should have worked fine but I realized it
>> didn't since DUM::send ends up calling
>> SipMessage::clearOutboundDecorators()... which clears up my decorator.
>>
>> Besides fixing what is said in DUM::send (see below) or using an
>> outgoing DUM feature, would there be any other way of doing it?
>>
>>   // .bwc. This is to avoid leaving extra copies of the decorator in msg,
>>   // when the caller of this function holds onto the reference (and this
>>   // happens quite often in DUM). I would prefer to refactor such that we
>>   // are operating on a copy in this function, but this would require a
>> lot
>>   // of work on the DumFeatureChain stuff (or, require an extra copy on
>> top
>>   // of the one we're doing when we send the message to the stack, which
>>   // would chew up a lot of extra cycles).
>>   msg->clearOutboundDecorators();
>>
>> Thanks :),
>> Francis
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel@xxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>