Re: [reSIProcate] Idea for a new API similar to DialogUsage::onReadyToSend
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@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
>>
>>
>