| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
Good idea - I think that could work nicely! On Thu, Aug 27, 2009 at 4:23 PM, Derek MacDonald<derek.macdonald@xxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxx> wrote: >> >> 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 >> >> >> > >> > >> _______________________________________________ >> resiprocate-devel mailing list >> resiprocate-devel@xxxxxxxxxxxxxxx >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel > >