atom feed6 messages in net.java.dev.jain-sip.usersRe: RFC 2543 old style transactions
FromSent OnAttachments
Frederic TardifAug 16, 2012 5:15 pm 
M. RanganathanAug 16, 2012 5:48 pm 
Frederic TardifAug 16, 2012 6:38 pm 
Jean DeruelleAug 17, 2012 1:28 am 
Frederic TardifAug 17, 2012 10:18 am 
M. RanganathanAug 17, 2012 10:43 am 
Subject:Re: RFC 2543 old style transactions
From:M. Ranganathan (mra@gmail.com)
Date:Aug 16, 2012 5:48:57 pm
List:net.java.dev.jain-sip.users

Hello Frederic,

I thought that check is triggered by looking at the magic cookie that precedes the branch ID.

Does that not suffice? If that does NOT suffice (please explain why) then there's a stack already in SIPTransactionStack which can be exposed.

Ranga

On Thu, Aug 16, 2012 at 8:15 PM, Frederic Tardif <fred@gmail.com> wrote:

Bonjour,

in SipTransactionStack#findTransaction, if the serverTx is not found within the serverTransactionTable (Map), an extra check is done according to "old style transaction" RFC 2543. This extra check requires a complete loop through all existing serverTx with a quite fancy matching rule (SipServerTransaction#isMessagePartOfTransaction()). When analyzing class/object time allocation under load, this method uses more than 3% of the processing allocation (when using AUTOMATIC_DIALOG_SUPPORT). Each initiating request will miss the serverTx in the normal serverTransactionMap and will try to loop through all serverTx in order to possibly match an "old style RFC 2543 transaction type". In production environment that deals with more than hundred cps with allocation counted in minutes, the loop can be fairly costly.

To avoid this extra cost when possible, I suggest a new Stack Configuration RFC_2543_TRANSACTION_SUPPORT set by default to true. This would aim to alleviate extra computation when the context guarantee non "old style RFC 2543" endpoints.

any objections?

merci Frederic