[reSIProcate] Matching INFO requests and responses

[Scott Godin]

...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/ef3512e8/attachment.htm>