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

[Scott Godin]

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/3e31584f/attachment.htm>