< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

[reSIProcate] Matching INFO requests and responses


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.

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 ;)?)

Thanks a lot,
Francis