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

Re: [reSIProcate] [reSIProcate-commit] resiprocate 9206 bcampen: Two changes that were somewhat tangled together, since they both used the same


Given the patch I committed yesterday for ClientOutOfDialogReq and InviteSession::getLastNITRequest, the only hole is now for in-dialog REFER's with sub where the failures show up in ClientSubscription. Would the patch that you are mentioning allow that ClientSubscription to be created with the original REFER request?

Aron Rosenberg
Sr. Director, Engineering,
LifeSize, a division of Logitech




On Wed, Jun 29, 2011 at 6:45 AM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
While Scott has already covered that this patch doesn't help you, there is a patch on the list of things to merge that might be useful. I've modified (our version of) the stack such that the original request is attached to the first final response sent to the TU (in a member auto_ptr, since the stack doesn't need it anymore). This helps in exactly the situation you're facing; you have a NIT transaction, and you need to access a header that was in the request that is not copied into the response. It also has the nice side effect of allowing the original request to be deleted in the thread where it was created, which can save the heap allocator some work.

Best regards,
Byron Campen

Byron,

Does this change make it any easier to consistently be able to access the NIT "request" SipMessage when processing a NIT "response"? Right now, when dealing with NIT REFER's, if the REFER gets 4xx'ed, there is no easy way that I can figure out to access the original Request so that we can extract the original ReferTo header.

-Aron

Aron Rosenberg
Sr. Director, Engineering,
LifeSize, a division of Logitech




On Sat, Jun 25, 2011 at 1:14 PM, <svn@xxxxxxxxxxxxxxx> wrote:
Projectresiprocate
New Revision9206
Committerbcampen (Byron Campen)
Date2011-06-25 15:14:49 -0500 (Sat, 25 Jun 2011)

Log

 Two changes that were somewhat tangled together, since they both used the same
 refactoring of the Transport SendData code.
 
 1) State shedding modifications to TransactionState
 
    In a number of cases, we were preserving state (in the form of SipMessages
    and DnsResults) in cases where we did not really need them any more. For
    example, once we have transmitted a response, there is no need
    to preserve the full SipMessage for this response (the raw retransmit buffer
    is sufficient). Also, INVITE requests do not need to be maintained once
    a final response comes in (since there is no possibility that we'll need to
    send a simulated 408 or 503 to the TU, nor will we need to construct a CANCEL
    request using the INVITE, nor will we need to retransmit). Similarly, once we
    have received a final response for a NIT transaction, we no longer need to
    maintain the original request or the retransmit buffer. Lastly, if we are
    using a reliable transport, we do not need to maintain retransmit buffers
    (although we may need to maintain full original requests for simulated
    responses and such).
 
    This change has basically no impact on reliable NIT performance, but a huge
    impact on non-reliable and INVITE performance. Prior to this change, either
    NIT UDP or INVITE TCP testStack would exhaust main memory on my laptop (with
    4GB of main memory), bringing progress to a complete halt on runs longer than
    15 seconds or so. I did not bother trying INVITE UDP, but that works now too.
 
 2) Reduction in buffer reallocations while encoding a SipMessage
 
    TransportSelector now keeps a moving average of the outgoing message size,
    which is used to preallocate the buffers into which SipMessages are encoded.
 
    This ends up making a small difference in testStack when linked against google
    malloc, but a larger difference when linked against OS X's (horrible) standard
    malloc.
 
 
 

Modified:


_______________________________________________
resiprocate-commit mailing list
resiprocate-commit@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-commit

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel