[reSIProcate] Matching INFO requests and responses

[Scott Godin]

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 at gmail.com>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 at sipspectrum.com>wrote:
>
>> ...inline...
>>
>> On Tue, Dec 7, 2010 at 8:40 PM, Francis Joanis <francis.joanis at gmail.com>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 at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20101208/15d0ca7b/attachment.htm>