[reSIProcate] Idea for a new API similar to DialogUsage::onReadyToSend

[Scott Godin]

Doing that would be making some potentially dangerous API's available to the
end user.  For example:  sending SIP messages via the Dialog class behind
the usages back is likely to mess up any state in the usages.  Perhaps we
should instead add a new API's to DialogUsageManager - findAppDialogSet
and/or findAppDialog.

Scott

On Wed, Oct 12, 2011 at 9:28 AM, Francis Joanis <francis.joanis at gmail.com>wrote:

> Hi,
>
> I agree with you as well in that we should not add new APIs that would
> add to the confusion of the many existing ones (it might not be that
> bad now, but adding new ones wouldn't help).
>
> I would rather have DUM manage its own mapping of (App)DialogSets to
> SIP messages (dialog IDs) than to have my own map in my app. After
> all, that's the whole point of using the AppDialogSet class, so that
> you can get access to your instances from the different usages.
>
> What would you think of making DUM::findDialog and/or
> DUM::findDialogSet public? That way we would be able to fetch the
> proper dialog sets from any SIP message.
>
> Thanks :)
>
> Francis
>
> On Wed, Oct 12, 2011 at 9:04 AM, Scott Godin <sgodin at sipspectrum.com>
> wrote:
> > I'm thinking that using DUM ingoing and outgoing feature chains is going
> to
> > be the best approach here.  For outgoing messages if you just rely on
> what
> > you send from the API level, you will miss certain messages (ie.
> > SessionTimer re-Invites, requests with Auth info added after a 407,
> etc.).
> >  If you need to for some reason, you should be able to take the message
> from
> > the feature chain and figure out which DialogSet it belongs to, by
> > maintaining the mapping from DialogSetId to your AppDialogSet objects.
>  You
> > can construct a DialogSetId object from any SIP message that can be used
> as
> > a map key.
> > I'm really hoping to avoid going down the path of adding new interfaces
> for
> > decorating / inspecting messages if appropriate ones already exist, since
> > there are so many different mechanisms already.
> > Scott
> >
> > On Tue, Oct 11, 2011 at 4:25 PM, Francis Joanis <
> francis.joanis at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> My application needs to perform some event logging through a
> >> SIP-oriented call-centric API (note that it is SIP message oriented
> >> and not SIP dialog oriented).
> >>
> >> For example, that API provides pre-compiled definitions such as
> >> InviteReceived, InviteSent, OkReceived, OkSent, ... The goal of that
> >> API is to "monitor" what is happening to INVITE dialogs at the "SIP
> >> message" level (as opposed to the "SIP Dialog" level - i.e. like what
> >> is given by resip::DialogEventStateManager et al.).
> >>
> >> For outgoing messages, InviteSessionHandler already has the
> >> onReadyToSend method. From this callback I can call a method that will
> >> directly look at the SipMessage (without modifying it...) and produce
> >> the proper event that my event logger needs. However, there is nothing
> >> that currently exists for the other way around: for incoming messages.
> >>
> >> I do know about DUM's incoming feature chain, but it only relates to
> >> SIP messages and not SIP messages and their DialogUsage. For example,
> >> the onReadyToSend API not only gives me the message, but it also gives
> >> me the InviteSession (the DialogUsage), which I can then relate to my
> >> AppDialogSets.
> >>
> >> Another option would be to call my event generation code within all
> >> InviteSessionHandler::on* callbacks, but I'd rather find a more
> >> generic way.
> >>
> >> So, I'd like to propose a new API to be added to DialogUsage and its
> >> children, something like InviteSession::onIncoming(const SipMessage&)
> >> with its matching InviteSessionHandler::onIncoming method. The new
> >> InviteSession::onIncoming method would then most likely be called from
> >> InviteSession::dispatch.
> >>
> >> Please let me know if there would be a better way to do this or if it
> >> just doesn't make sense ;)
> >>
> >> Thanks,
> >> Francis
> >> _______________________________________________
> >> 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/20111012/c928bb74/attachment.htm>