< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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


Thanks Scott.  I would vote for adding this to DUM.  It is something that
keeps resip/DUM current as a SIP stack.

Related question:  Any idea why adding my non-sdp to the inviteMsg returned
from makeInviteSession() would cause a problem?  This was my first solution,
but I started seeing intermittent outbound invites that had malformed SDP.
This was after being challenged, the subsequent INVITE modified by the
ClientAuthManager had what looked like portions of the SDP memory
overwritten, although the debugger never caught any memory overwrites.  I
couldn't see where the problem was, but assumed it was from modifying the
invite message (essentially the getLastRequest() message) return from
makeInviteSession().  My current hack appears to be working without creating
this issue.

-justin

-----Original Message-----
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Thursday, August 27, 2009 9:10 AM
To: Justin Matthews
Cc: resiprocate-devel
Subject: Re: [reSIProcate] adding non-sdp contents to outbound invites using
DumFeature

Hi Justin,

Comments inline...

On Thu, Aug 27, 2009 at 7:25 AM, Justin Matthews<jmatthewsr@xxxxxxxxx>
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@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] 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@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
>