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

RE: [reSIProcate] Multiple non-invite client transactions


We made the decision to only allow one outstanding UAC NIT transaction a time.  Timer K shouldn't be how NITs move to completed, it should be receiving a 200 response from the other side.  Are you using InviteSession::acceptNIT appropriately in the UAS/is the UAS sending 200s to the NITs? 

 

Also, you'll know when you cans end another NIT because :

 

      virtual void onInfoSuccess(InviteSessionHandle, const SipMessage& msg)=0;

 

or

 

      virtual void onInfoFailure(InviteSessionHandle, const SipMessage& msg)=0;

 

will be called at the UAC.

 

--Derek

 

CONFIDENTIALITY NOTICE

This email and any files transmitted with it contains proprietary information and, unless expressly stated otherwise, all contents and attachments are confidential. This email is intended for the addressee(s) only and access by anyone else is unauthorized. If you are not an addressee, any disclosure, distribution, printing or copying of the contents of this email or its attachments, or any action taken in reliance on it, is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately and then delete this email and any copies of it. Thank you for your co-operation.


From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keohane, Stephen
Sent: Tuesday, September 06, 2005 2:27 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Multiple non-invite client transactions

 

Hello,

 

My usecase has multiple info request/response transactions during a session. What I am finding is that the Timer K which moves the NICT from the Completed to Terminated states has not fired.

 

Questions:

 

Is it possible to set Timer K to some other value other than T4? If so, how?

 

This seems to be allowed in RFC 3261 pg 258

RFC 2543 was silent on whether a UA could initiate a new

transaction to a peer while another was in progress. That is now

specified here. It is allowed for non-INVITE requests, disallowed

for INVITE.”

Is this an issue or has it been fixed in the latest release?

 

Finally, here is the exception raised:

UsageUseException::Cannot start a non-invite transaction until the previous one has completed

 

 

Thanks for all your help, I really appreciate it, and I’m really sorry if this is covered in the archives or wiki – I couldn’t find it.

 

Stephen Keohane