[reSIProcate] [reSIProcate-commit] resiprocate 9206 bcampen: Two changes that were somewhat tangled together, since they both used the same
Aron Rosenberg
arosenberg at logitech.com
Mon Jun 27 16:03:56 CDT 2011
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> 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>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> wrote:
>>
>>> Projectresiprocate New Revision9206<http://svn.resiprocate.org/viewsvn/resiprocate?view=rev&rev=9206>
>>> 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:
>>>
>>> - 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
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-commit
>>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> 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/20110627/02ca9e6c/attachment.htm>
More information about the resiprocate-devel
mailing list