Re: [reSIProcate] Matching INFO requests and responses
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
>