Re: [reSIProcate] Idea for a new API similar to DialogUsage::onReadyToSend
Allright, I commited rev 9292 and I tested my use case with
incoming/outgoing DumCommands. Works like a charm, thanks a lot!
Francis
On Wed, Oct 12, 2011 at 9:50 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
> Exactly what I was thinking. : )
>
> On Wed, Oct 12, 2011 at 9:37 AM, Francis Joanis <francis.joanis@xxxxxxxxx>
> 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@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
>> >>
>> >>
>> >
>
>