Re: [reSIProcate] adding non-sdp contents to outbound invites using DumFeature
On Thu, Aug 27, 2009 at 10:35 AM, Justin Matthews<jmatthewsr@xxxxxxxxx> wrote:
> 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.
DUM stores the offer and answer message bodies as SdpContents -
perhaps by you adding a different body type something is getting
messed up in the offer/answer logic in InviteSession. I'm not sure
how to explain why the initial invite message would get corrupted
though.
Scott
> -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
>>>
>>
>>
>
>