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