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

[reSIProcate] Duplicate transaction id's in sequential NICT (INF0 Requests)


Hello,

 

I'm stuck on a problem using DUM to send sequential INFO response/requests after I have established a call.

 

I'm seeing a transaction Id reused in requests which causes the response not to be sent up to the application layer.

 

Essentially, I have multiple threads that request a singleton object (SipH) to create and send Info messages to a UAS. When I receive a response from the INFO, I process it from another thread which has the dum->process(fdset);

 

The method which has the dum->process() is mutexed with the methods that create requests.

 

Here is the code snippet which creates the requests:

 

 

try

{

  std::auto_ptr<resip::Contents> contents(new resip::PlainContents(message.c_str()));

 

  resip::SipMessage& infoMessage = pep->inviteSession()->makeInfo(contents);

 

  TRACE("SipH::sendInfo() -- ", infoMessage.brief().c_str());

 

  pep->inviteSession()->send(infoMessage);

 

}

catch(resip::BaseException& be) {}

 

 

Each call object (pep) keeps its own inviteSession. In my scenario I am only running one call. The requests are a couple of seconds apart - the UAS responds almost immediately.

My log format is seconds:thread:Class:method() – message and I am using SIpMessage::brief() here.

 

Here is the pertinent info from my log:

 

 

1126822932:2528:SipH::sendInfo() --  SipReq:  INFO admin@xxxxxxxxxx:5060 tid=eb01e926a62eb30b cseq=INFO contact=administrator / 2 from(tu)

 

1126822932:3876:SipInviteSessionHandler::onInfoSuccess() --  SipResp: 200 tid=3c15db120c39877e cseq=INFO / 2 from(wire)

 

1126822935:2856:SipH::sendInfo() --  SipReq:  INFO admin@xxxxxxxxxx:5060 tid=234829008467be18 cseq=INFO contact=administrator / 3 from(tu)

 

1126822935:3876:SipInviteSessionHandler::onInfoSuccess() --  SipResp: 200 tid=6c3de14aae72d62c cseq=INFO / 3 from(wire)

 

1126822937:3684:SipH::sendInfo() --  SipReq:  INFO admin@xxxxxxxxxx:5060 tid=234829008467be18 cseq=INFO contact=administrator / 4 from(tu)

 

The reSIProcate logs look fine - they essentially tell the same story. The duplicate tid shows up first from Dialog::makeRequest and it is not clear to me how it obtains a transaction id.

 

I've created a test program based on basicCall and it processes requests/responses without incident. The onAnswer sends a infoMessage and the onInfoSuccess sends infoMessages. It might be a rather brutal test but it works. Here is the OnAnswer and OnInfoSuccess:

 

virtual void onAnswer(InviteSessionHandle is, const SipMessage& msg, const SdpContents*sdp)

{

  cout << name << ": InviteSession-onAnswer(SDP)" << endl;

 

  std::string myMsg("Message One");

  std::auto_ptr<resip::Contents> contents(new resip::PlainContents(myMsg.c_str()));

  resip::SipMessage& infoMessage = is->makeInfo(contents);

 

  is->send(infoMessage);

}

 

virtual void onInfoSuccess(InviteSessionHandle is, const SipMessage& msg)

{

  cout << name << ": InviteSession-onInfoSuccess - " << msg.brief() << endl;

 

  std::string myMsg("Message Two");

  std::auto_ptr<resip::Contents> contents(new resip::PlainContents(myMsg.c_str()));

  resip::SipMessage& infoMessage = is->makeInfo(contents);

  is->send(infoMessage);

}

 

 

Am I doing something stupid? It wouldn't be the first time. Any help or advice would be greatly appreciated.

 

Thanks,

 

Stephen Keohane