[reSIProcate] Matching INFO requests and responses
Francis Joanis
francis.joanis at gmail.com
Tue Dec 7 19:40:30 CST 2010
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20101207/37547d9e/attachment.htm>
More information about the resiprocate-devel
mailing list