[reSIProcate] Add OutboundDecorator to AppDialogSet and header Reason

[Scott Godin]

...inline...

On Thu, Jul 21, 2011 at 12:28 PM, Dario Bozzali
<Dario.Bozzali at ifmgroup.it>wrote:

> Hello,
> I need to add an outbound decorator on per call basis and I would prefer
> if it could be possible to avoid the use of unique profile for each call
> (like suggested in
> <http://list.resiprocate.org/archive/resiprocate-devel/msg07342.html>),
> in fact I use another outbound decorator set in MasterProfile that is
> called for each outgoing message, not only invite sessions.
> I thought to add methods to set outbound decorator in DialogSet through
> AppDialogSet and then retrieve that in DialogUsageManager::send(). This
> outbound decorator would be added between UserProfile and ClientAuth
> decorators.
> I attached a patch file to this mail to show my idea. I would appreciate
> any comments/suggestions.
>
> [Scott]  The patch looks sane to me.  My only concern with this is that we
already have 3 different ways to decorate messages (ie. Outbound Decorators
on UserProfile, onReadyToSend callback, outgoing feature chain).  It might
make more sense to modify the UserProfile so that you can add more than one
outbound decorator (it can maintain a set or list or Decorators).  That way
you can keep you OutboundDecorator in MasterProfile and you can create a
UserProfile for each call with another decorator.  Keep in mind that
Profiles can be created with other Profiles as templates (see the
constructor) so that all settings fallthrough to a base Profile.  Using this
concept you could create a unique UserProfile for each call, based on some
template and only change the Outbound decorator set, by adding a new one.


> Moreover, I have a question related to header Reason.
> In InviteSession::sendBye() header Reason is forced to use description
> parameter, but in my opinion this is not compliant with RFC 3326
> (section 2), in fact an example found in RFC is:
>   Reason: SIP ;cause=200 ;text="Call completed elsewhere"
>
> In my opinion InviteSession::sendBye() should contain something like:
>   if (mEndReason != NotSpecified)
>      Token reason(getEndReasonString(mEndReason));
>      bye->header(h_Reasons).push_back(reason);
>   }
>

[Scott]  Not sure I understand what you are saying here.
Today resip Reason headers look something like: Reason: SIP;text="ACK not
received"
You are proposing: Reason: Ack not received
RFC recommends: Reason: SIP ;cause=200 ;text="Call completed elsewhere"
The first element in the grammar is protocol.  It allows a Token - however
the reason text is clearly not a protocol so I don't think your suggestion
makes sense.  I don't see any RFC violations to what resip is currently
using.  I could understand that some implementations may expect a cause
code, but it doesn't appear to be a violation of the RFC to omit this.  Can
you explain more?

Moreover it seems to me that the only way to add Reason header to CANCEL
> request is an outbound decorator, because Helper::makeCancel() is
> invoked in DialogSet::end() which then invokes
> DialogUsageManager::send().
> What are your opinions about that?
>

[Scott]  Yes I believe that is more or less true (you could also use an
Outgoing feature).  We could extend the InviteSession::sendBye and
AppDialogSet::end API's to accept an optional Reason token that is added to
the resulting CANCEL or BYE messages to make this easier.


>
> Thank you,
> Dario
>
>
> _______________________________________________
> 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/20111002/5173e096/attachment.htm>