Re: [reSIProcate] Idea for a new API similar to DialogUsage::onReadyToSend
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel