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

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@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
>
>