Re: [reSIProcate] Matching INFO requests and responses

[Francis Joanis <francis.joanis@xxxxxxxxx>]

Hi,

I like what you are proposing since any user-specific information would go in the user-derived Contents object: it acts a bit like an AppDialog/Set in that sense.

We could even implement this by only caching the Contents of the last sent NIT request, since they're all sent serially (so no need to do the extra management on mNITQueue). This would mainly require adding a new member variable (probably an auto_ptr<Contents>) to InviteSession and changing the various on* callbacks in InviteSessionHandler.

In the case of the REFER (which is also using mNITQueue), it would most likely have a NULL Contents, so it could get ignored on the callbacks (i.e. no need to modify the onRefer* callbacks).

I started playing around with the code but I'd like to know if such a change would be a good one or not from the perspective of the more experienced developers. Changing callback APIs seems like a somewhat major change (i.e. it will break current apps) and I wouldn't want to do it unless there is really a good use case.

Regards,

Francis

On Wed, Dec 8, 2010 at 1:32 PM, Aron Rosenberg <arosenberg@xxxxxxxxxxxx> wrote:

For a slightly different issue (matching 415's to outbound MESSAGE
requests) I was looking at modifying InviteSession to remove the
SipMessage* from the mNITQueue upon end of transaction rather than
beginning of transaction. We could then pass up the Contents* like is
done with ClientPagerMessage.

onMessageSuccess(resip::InviteSessionHandle ish, const
resip::SipMessage&status) would become
onMessageSuccess(resip::InviteSessionHandle ish, const
resip::SipMessage&status, std::auto_ptr<Contents> contents)
onMessageFailure(resip::InviteSessionHandle ish, const
resip::SipMessage &status) would become
onMessageFailure(resip::InviteSessionHandle ish, const
resip::SipMessage &status, std::auto_ptr<Contents> contents)

This would also work in the INFO cases with the same changes to add
std::auto_ptr<Contents> contents to the callbacks.

I also attempted to try the other way, dig into the
TransactionController / TU and create a "SipMessage*
findLastRequestForResponse(SipMessage*)" that used the tid, but this
would require adding a number of public functions to SipStack,
TransactionMap and some other classes.

-Aron

Aron Rosenberg
Logitech Inc. (SightSpeed Group)



On Wed, Dec 8, 2010 at 10:08 AM, Francis Joanis

<francis.joanis@xxxxxxxxx> wrote:
> So I guess it leaves me with the original workaround of leveraging the fact
> that all NITs are sequential. Also I think I could use an outgoing
> DumFeature to inspect outgoing messages, but that would be called for all
> outgoing messages, which will impact performance.
> Thanks,
> Francis
>
> On Wed, Dec 8, 2010 at 11:28 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
>>
>> The branch parameter is "reset" in DialogUsageManager send (ln 824) - so
>> it won't help to store the branch parameter in the message created (same
>> applies for onReadyToSend).
>> Scott
>>
>> On Wed, Dec 8, 2010 at 11:08 AM, Francis Joanis <francis.joanis@xxxxxxxxx>
>> wrote:
>>>
>>> Hi Scott,
>>> Thanks for your reply.
>>> What about if we changed InviteSession::info/refer/message to return a
>>> _copy_ of the constructed SipMessage rather than returning void?
>>> I ran a quick test and it looks like the transaction id is set when the
>>> message is constructed. That way, I can immediately cache the SIP
>>> transaction id to pair it with my "key". This removes the need for my extra
>>> "key list" and does not require message inspection in onReadyToSend.
>>> (I've also attached a patch to do this.)
>>> Thanks,
>>> Francis
>>>
>>> On Wed, Dec 8, 2010 at 9:12 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx>
>>> wrote:
>>>>
>>>> ...inline...
>>>>
>>>> On Tue, Dec 7, 2010 at 8:40 PM, Francis Joanis
>>>> <francis.joanis@xxxxxxxxx> wrote:
>>>>>
>>>>> Hi guys,
>>>>> I have a question about sending multiple NIT messages logically "at the
>>>>> same time" (with DUM). I do know that the current code doesn't allow for
>>>>> real parallel NIT requests (i.e. the NIT queue in InviteSession) - but
>>>>> that's not my issue.
>>>>> The issue I have is regarding how to match incoming INFO responses to
>>>>> their request. Imagine I need to send INFO messages regarding
>>>>> application-specific transactions (like DB transactions or whatever
>>>>> application specific thing like a button click). I'll call those non-SIP
>>>>> transaction ids "keys".
>>>>> If I can't have the keys passed into the INFO body and then have them
>>>>> resupplied back into the INFO response, there is no easy way of matching
>>>>> which response is for which request (especially if my application would
>>>>> allow multiple requests to be sent (queued in NIT queue) at the same time).
>>>>> The "workaround" would be to leverage the fact that NITs in an INVITE
>>>>> dialog are all serialized: I could keep a separate list of "keys". If I were
>>>>> to add my key to the list right before sending the INFO message, I would
>>>>> then know that the next INFO response will relate to that key (oldest
>>>>> element of the key list). But this can get messy since I would need to make
>>>>> sure that the "key list" is properly managed.
>>>>
>>>> [Scott]  This solution works without having to modify DUM, and its
>>>> likely very similar to how it would be implemented in DUM if we added some
>>>> kind of key/id to the info() call and response callback.  Alternatively, you
>>>> could track the transaction id's as the INFO messages flow out of the invite
>>>> session by watching the onReadyToSend callback, but I don't think that
>>>> offers any advantage over assuming the requests are serialized.
>>>>
>>>>>
>>>>> If I look at the similar scenario but with INVITE messages, one can
>>>>> easily leverage the AppDialogSet/... to do this: set the "key" on the
>>>>> AppDialogSet and then it will be easily accessible once INVITE responses
>>>>> arrive (extracted from the INVITE session).
>>>>> I was thinking of extracting the id of the SIP transaction created for
>>>>> the INFO to use it for a lookup between the SIP transaction id and my "key".
>>>>> That way, when handling onInfo* callbacks I would be able to access the SIP
>>>>> transaction id from the response message and map it with my "key".
>>>>> However, this might not be feasible if the SIP transaction id is
>>>>> unknown to the DUM at this time (prior to sending it).
>>>>> What do you make out of this?
>>>>> I suspect this will get worst if reSIProcate ever allows multiple NITs
>>>>> in parallel at the same time (in an INVITE dialog), since then there would
>>>>> really be no easy way of matching them up to application specific data (or
>>>>> am I asking for an AppTransaction class ;)?)
>>>>
>>>> [Scott] Not sure we would ever allow this - I remember this being
>>>> discouraged by the IETF.
>>>>
>>>>>
>>>>> Thanks a lot,
>>>>> Francis
>>>>> _______________________________________________
>>>>> resiprocate-devel mailing list
>>>>> resiprocate-devel@xxxxxxxxxxxxxxx
>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>
>>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>