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

Scott Godin sgodin at computer-talk.com
Tue Jun 28 13:54:15 CDT 2011 

Looks good to me.  :)

From: resiprocate-devel-bounces at resiprocate.org [mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of Aron Rosenberg
Sent: June-28-11 2:50 PM
To: resiprocate-devel
Subject: Re: [reSIProcate] [reSIProcate-commit] resiprocate 9206 bcampen: Two changes that were somewhat tangled together, since they both used the same

That function works great, was exactly what I was looking - Should we add an equivalent getRequest() to ClientOutOfDialogReq? Here is a proposed patch for that

Index: resip/dum/ClientOutOfDialogReq.cxx
===================================================================
--- resip/dum/ClientOutOfDialogReq.cxx      (revision 9087)
+++ resip/dum/ClientOutOfDialogReq.cxx   (working copy)
@@ -79,6 +79,12 @@
     }
 }

+const SipMessage&
+ClientOutOfDialogReq::getRequest() const
+{
+   return mRequest;
+}
+
 void
 ClientOutOfDialogReq::dispatch(const DumTimeout& timer)
 {
Index: resip/dum/ClientOutOfDialogReq.hxx
===================================================================
--- resip/dum/ClientOutOfDialogReq.hxx      (revision 9087)
+++ resip/dum/ClientOutOfDialogReq.hxx   (working copy)
@@ -16,6 +16,7 @@
       ClientOutOfDialogReqHandle getHandle();

       bool matches(const SipMessage& msg) const;
+      const SipMessage& getRequest() const;

       virtual void end();
       virtual void dispatch(const SipMessage& msg);
@@ -29,7 +30,7 @@
    private:
       friend class DialogSet;
       CSeqCategory mCSeq;
-            SipMessage mRequest;
+      SipMessage mRequest;

       // disabled
       ClientOutOfDialogReq(const ClientOutOfDialogReq&);


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



On Tue, Jun 28, 2011 at 7:25 AM, Scott Godin <sgodin at sipspectrum.com<mailto:sgodin at sipspectrum.com>> wrote:
For InviteSession there is a relatively new API, InviteSession::getLastSentNITRequest - it is able to return the last refer, info, or message sent.

Scott

On Mon, Jun 27, 2011 at 5:03 PM, Aron Rosenberg <arosenberg at logitech.com<mailto:arosenberg at logitech.com>> wrote:
I mean an in-dialog REFER sent as part of an InviteSession (NITqueue related). If the upstream proxy rejects it with a 4xx, I am trying to access the original ReferTo header (not included in the 4xx reply's) to see which Refer Resource got rejected.

InviteSession related refer failures show up either in

void onReferRejected(InviteSessionHandle, const SipMessage& msg)
or
void onTerminated(ClientSubscriptionHandle csh, const SipMessage* msg)

For ClientOutOfDialogReq, that class stores mRequest (which I did a header hack to access), would be nice to make a clean auto_ptr accessor for it though and I will eventually submit a patch for this....

I was hoping that there was something like auto_ptr<SipMessage> DialogUsageManager::findMatchingRequest(const SipMessage* response)


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



On Mon, Jun 27, 2011 at 1:22 PM, Scott Godin <sgodin at sipspectrum.com<mailto:sgodin at sipspectrum.com>> wrote:
Hi Aron,

I suspect you are referring to DUM's behaviour.  The changes Byron committed below are all to the core stack only.  When you say NIT REFER's - do you mean REFER's that are outside of an INVITE dialog (ie. Out-of-Dialog REFERs)?

Scott
On Sun, Jun 26, 2011 at 11:27 PM, Aron Rosenberg <arosenberg at logitech.com<mailto:arosenberg at logitech.com>> wrote:
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 at resiprocate.org<mailto:svn at resiprocate.org>> wrote:
Project

resiprocate

New Revision

9206<http://svn.resiprocate.org/viewsvn/resiprocate?view=rev&rev=9206>

Committer

bcampen (Byron Campen)

Date

2011-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:

 *   branches/b-TKLC-perf_work/resip/stack/InternalTransport.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/InternalTransport.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/InternalTransport.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/InternalTransport.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/SendData.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/SendData.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/SipMessage.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/SipMessage.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/SipMessage.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/SipMessage.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/StatisticsManager.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/StatisticsManager.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/StatisticsManager.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/StatisticsManager.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/TransactionState.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/TransactionState.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/TransactionState.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/TransactionState.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/Transport.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/Transport.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/Transport.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/Transport.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/TransportSelector.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/TransportSelector.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/TransportSelector.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/TransportSelector.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/UdpTransport.hxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/UdpTransport.hxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/test/testConnectionBase.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/test/testConnectionBase.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/test/testTcp.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/test/testTcp.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/resip/stack/test/testUdp.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/resip/stack/test/testUdp.cxx?r1=9205&r2=9206&diff_format=l>
 *   branches/b-TKLC-perf_work/tfm/TestSipEndPoint.cxx <http://svn.resiprocate.org/viewsvn/resiprocate/branches/b-TKLC-perf_work/tfm/TestSipEndPoint.cxx?r1=9205&r2=9206&diff_format=l>

_______________________________________________
resiprocate-commit mailing list
resiprocate-commit at resiprocate.org<mailto:resiprocate-commit at resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-commit


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org<mailto:resiprocate-devel at resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel



_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org<mailto: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/20110628/d7055319/attachment.htm>

More information about the resiprocate-devel mailing list