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

[Keohane, Stephen]

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 at 10.1.17.70: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 at 10.1.17.70: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 at 10.1.17.70: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050915/83d8c9cf/attachment.htm>