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

[Scott Godin]

Exactly what I was thinking.  : )

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

> Hi again,
>
> Just a correction, it might be better to add new APIs that return
> actual AppDialog(Set)Handles than to return the Dialog/DialogSet ones.
>
> Thanks,
> Francis
>
> 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/506af7a0/attachment.htm>