Re: [reSIProcate] Add OutboundDecorator to AppDialogSet and header Reason
...inline...
On Thu, Jul 21, 2011 at 12:28 PM, Dario Bozzali
<Dario.Bozzali@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel