[reSIProcate] adding non-sdp contents to outbound invites using DumFeature

Derek MacDonald derek.macdonald at gmail.com
Thu Aug 27 15:23:49 CDT 2009


We could solve the casting issue with templates: InviteSessionHandler would
have template methods for onOffer and onAnswer methods.

On Thu, Aug 27, 2009 at 6:10 AM, Scott Godin <sgodin at sipspectrum.com> wrote:

> Hi Justin,
>
> Comments inline...
>
> On Thu, Aug 27, 2009 at 7:25 AM, Justin Matthews<jmatthewsr at gmail.com>
> wrote:
> > Thanks.  Another issue with manipulating the contents of the message is
> that
> > authentication headers compute hashes based on the contents in some
> > instances.  The auth headers are added in DUM before the features and
> before
> > the decorators.  Using a messagedecorator seems like it would be
> difficult
> > to recomputed the auth header since the message is decorated at the stack
> > level.
>
> Excellent point about the auth headers.  Keep in mind that the Sip
> message body is only included in the auth hashes if auth-int digest is
> used - in my experience this is not widely used in most deployments at
> this point - but none the less, it is a real issue.
>
> > My current hack is to:
> >
> > * make findDialogSet public in DialogUsageManager
> > * add a getClientAuthManager to DUM
> > * add a getAppDialogSet to DialogSet
> > * use all of the above in my feature to get the dialogset and my specific
> > contents, add the contents to the outbound invite and finally re-add auth
> > headers using the ClientAuthManager.
> >:
> > Maybe adding non-sdp should be added to makeInviteSession?  If that's not
> a
> > good idea then doing something like passing the userprofile into the
> > feature's process( ) function, or similar, would be helpful.  Thoughts?
>
> Adding a function to retrieve the AppDialogSet from DUM given any
> SipMessage would be a good thing to add - but there would still be the
> auth issue.
>
> I've been wanting to generalize the InviteSession handling of
> SdpContents to a generic Contents handling instead.  This would allow
> invite session to handle offer/answer of any body type.  I'm doing
> this in a local fork of DUM in order to handle TR-87, CSTA/XML over
> SIP (non-SDP offer/answer), and it's pretty straight forward.  However
> it does have the drawback that DUM users wanting to deal with SDP
> would now have to cast the bare Contents returned in the handles to an
> SDPContents.  I received feedback from the group a  while back, that
> this extra casting requirement was undesirable, so I haven't bothered
> to commit the change.  However, I see about 1-2 requests for this
> capability a year, so it might be worth revisiting the decision to
> make this change.  Any other opinions out there on this topic?
>
> Scott
>
> > Thanks,
> >
> > -justin
> >
> > -----Original Message-----
> > From: slgodin at gmail.com [mailto:slgodin at gmail.com] On Behalf Of Scott
> Godin
> > Sent: Wednesday, August 26, 2009 9:27 PM
> > To: Justin Matthews
> > Cc: resiprocate-devel
> > Subject: Re: [reSIProcate] adding non-sdp contents to outbound invites
> using
> > DumFeature
> >
> > You could use a unique user profile per call.  You would set a unique
> > outbound decorator per call that would encapsulate the specific body
> > you want to the add to the messages.  This avoids the mapping
> > complications.
> >
> > Scott
> >
> > On Wed, Aug 26, 2009 at 2:46 PM, Justin Matthews<jmatthewsr at gmail.com>
> > wrote:
> >> Hi,
> >>
> >>
> >>
> >> I am trying to add contents in addition to the normal SDP of an outbound
> >> invite.  Using a DUM feature I want to store the contents pointer of
> this
> >> new content in the appdialogset so that the contents can be looked up
> and
> >> applied to the message.  The problem is trying to get the appdialogset
> > from
> >> the sipmessage sent to the feature without having an actual Dialog. Is
> > there
> >> a better way to do this?  I’ve looked at messagedecorator and possibly
> >> storing a map of dialogsetid’s to contents in my feature object, but the
> >> messagedecorator has the rollback mechanism which seems like wasted
> cycles
> >> and increased complexity and the map requires removing the entries once
> > the
> >> outbound call is finished.
> >>
> >>
> >>
> >> Any ideas?
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> -justin
> >>
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel at resiprocate.org
> >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >>
> >
> >
> _______________________________________________
> 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/20090827/0462891e/attachment.htm>


More information about the resiprocate-devel mailing list